Windows Computer Use Ctrl chords fail in Flutter with zero scan codes

Summary

The supported Computer Use @oai/sky API cannot paste or select all in a focused standard Flutter Windows TextField on the tested setup. Incoming Ctrl and letter-key messages have scan code zero. Flutter maps them to the same physical key identity and loses the Ctrl modifier before handling the letter key.

This matches the class of Windows synthetic-input compatibility problem described in flutter/flutter#99198, which was still open when checked. It does not establish that Computer Use is the only component responsible, or that zero scan codes are unique to this tool.

Please investigate whether the Windows input backend can provide consistent ordinary-key scan codes and extended-key information for generated chords. The internal injection implementation and exact function used by the tool have not been inspected.

Tested environment

• Windows desktop, x64, visible focused test window.
• Computer Use bundle: 26.901.51231.
• Client: the supported @oai/sky API through Codex Node REPL.
• Flutter: 3.44.9, Windows Debug.
• Engine revision: 5a2a6a42cce67f965cf540fcecf616faca624aa1.
• The baseline and comparison receiver used the same engine DLL.
• A standalone receiver with a default Flutter TextField was used; no application-specific shortcuts or input filters were involved.

Reproduction

1. Open a standalone Flutter Windows app containing a default TextField.
2. Select its actual returned Computer Use window, click the field, and refresh to verify focus. Use that returned object as window below.
3. Call await sky.type_text({window, text: 'q'}), then refresh. The field remains empty.
4. Call await sky.press_key({window, key: 'q'}), then refresh. The field now contains q.
5. Call await sky.press_key({window, key: 'Control_L+a'}), then refresh. The text is not selected; the selection stays collapsed at the end.
6. As a control, put a known synthetic sentence on the clipboard and use the field's visible Paste menu. The full sentence appears.

Expected: type_text inserts the requested text and Ctrl+A selects the field contents.

Observed: the supported type_text call reaches this receiver as Ctrl+V. It does not deliver a q character through the printable WM_CHAR path in step 3. The documented Control_L chord spelling does not resolve the selection failure.

Receiver evidence

Baseline observations from 2026-09-07 UTC:

The native receiver saw generic Ctrl down while V was delivered. The issue is therefore not explained solely by the absence of an OS Ctrl-down event.

The baseline native observer forwards the exact received arguments to DefSubclassProc. Its Dart HardwareKeyboard observer returns false. Both observers log synchronously; timing-neutral behavior is not claimed. Duplicate native messages may be engine redispatch and are not evidence of duplicate tool calls.

Controlled comparison

Only in the separate diagnostic receiver, missing ordinary-key scan fields and related WM_CHAR scan fields were supplied using MapVirtualKeyEx. The same tool and engine then produced:

• Ctrl scan 0x1d, physical ID 0x700e0.
• V scan 0x2f, physical ID 0x70019; Ctrl remained true at V keydown.
• Successful insertion of the same 55-character Korean/English sentence.
• Successful Control_L+a, selection 0:55.
• Successful replacement of that selection by the same type_text('q') call.

This comparison establishes that distinct ordinary-key scan information resolves the tested failure. It is not a production patch or complete IME, keyboard-layout, extended-key, or accessibility compatibility test. VK_PACKET was excluded from the experimental normalization; its Unicode WM_CHAR path should be handled separately.

Upstream context and limits

• Flutter issue #99198 describes different logical keys sharing scan code zero during emulated Windows shortcuts, including Ctrl+V. The issue remained open on 2026-09-08 KST.
• The inspected Flutter stable and main copies of keyboard_key_embedder_handler.cc had the same blob SHA, 9351f6e04d791d4c70dfbe60ecc0e1037270af2a. GetPhysicalKey still uses the scan code for its fallback physical identity. This source observation does not substitute for testing a different SDK or prove that no other input-path changes exist.
• No applicable released fix was identified in this bounded source/issue review. No SDK update was installed or tested as part of that review.
• Physical-keyboard and general IME behavior were not tested. The finding concerns the observed automated input sequence.
• No Computer Use implementation, Flutter SDK, or product keyboard handler was patched.

Start with the standalone Flutter Windows TextField reproduction and compare type_text('q'), press_key('q'), and Control_L+a while logging the received messages. Read Flutter's keyboard_key_embedder_handler.cc, especially GetPhysicalKey, and trace the Computer Use Windows input path. Done means ordinary-key scan codes and extended-key information are consistent enough for text insertion, Ctrl+A selection, and replacement to work.