Windows Codex App Computer Use: Android Emulator activation intermittently fails and type_text does not reach focused fields

Additional bounded local testing found a partial supported workaround and two more failure modes in the same official runtime.

Activation workaround

The installed Sky 0.4.20 docs state that input methods auto-activate their target window. Skipping explicit activate_window and using a fresh screenshot-bound sky.click directly on the Android WebView input:

• avoided the GetCursorPos ... 0x80070005 error;
• brought the Emulator foreground;
• visibly focused the exact empty input.

No ADB, shell UI automation, patched runtime, or fallback was used.

Duplicate chord input

With the Windows clipboard independently read back as exactly 381 (length 3, UTF-8 SHA-256 392a52e4f77c40bf3321dc2feac356fac2a906a80c961748170af4ce2bce1e6a), exactly one:

await sky.press_key({ window, key: "Control_L+v" })

returned successfully. After dismissing the Android floating input toolbar with one non-interactive screenshot-bound click, the field visibly contained 381381, not 381.

Evidence hashes:

• focused empty field screenshot: c95cb6b0457039bcc917023ce618208e7e70fdeeacb2e7ac633ce12e071c190c
• after the single Ctrl+V screenshot: 47b1db97c42cb2c79027114e126cdf3dc311b8e639dd9f9ff65533b5873ff6cf
• unobscured final 381381 screenshot: 319b5349118d8d393e615e1c8a0a2ca503dd0e68828bff1838785c93666ee827

Subsequent black capture

A later fresh official Sky turn intended only to normalize the duplicate value returned a completely black 390x895 Emulator screenshot. One read-only get_window rebind followed by a fresh state was also black, so no corrective UI action was attempted.

This suggests three separable Windows/Emulator issues:

1. explicit activate_window intermittently fails in GetCursorPos;
2. direct input auto-activation can bypass that failure;
3. one documented Control_L+v chord may be delivered twice, and fresh Emulator capture can later become black.

The direct-click route is a useful activation workaround, but it is not yet a reliable text-input workaround.

Additional exact reproduction from the same official Windows runtime (@oai/sky 0.4.20) and Android Emulator target:

• Windows clipboard was independently verified as exactly 381 (length 3).
• One official sky.press_key({ key: "Control_L+v" }) produced the unobscured field value 381381.
• After restoring a normal Emulator viewport and removing the floating input overlay, exactly one Control_L+z cleared the whole 381381 value instead of leaving 381. This shows the duplicate was delivered as one input transaction.
• Emulator zoom can obscure the leading character and initially made the result look like 81; a fresh screenshot-bound click on the visible toolbar zoom control restored the viewport. The accessibility element index for ToolControls.zoom_button was duplicated, so element-target click failed while screenshot-coordinate click succeeded.

Correction to the initial workaround note: the later exact 381 screenshot after pasting six leading ASCII spaces plus 381 was assisted because the owner manually dismissed the floating panel. It is therefore not autonomous Computer Use evidence and is not claimed as a proven runtime workaround. A new bounded probe with 15 leading spaces and Sky-only panel dismissal is required. We are not patching the bundled runtime and are not counting ADB/shell or human UI actions as Computer Use PASS.

Additional official-runtime reproduction from VitaRoute attempt 16 (current APK candidate; no patched runtime, ADB UI, fallback, or human assistance):

• Codex App 26.707.6957.0, bundled computer-use 26.707.51957, @oai/sky 0.4.20.
• Fresh Android Emulator capture was readable, so the prior all-black state did not recur.
• A screenshot-bound harmless click/readback succeeded without activate_window and without GetCursorPos 0x80070005.
• Official Sky reached the app Diary view and captured current UI.
• Viewport normalization then failed: the single screenshot-bound toolbar zoom action enabled zoom/pan instead of restoring normal viewport.
• Accessibility recovery failed exactly: element 8 is not available in cached app state for qemu-system-x86_64.exe.
• The run stopped before CRUD according to the bounded skill; no additional coordinate attempts were made.

This narrows the current blocker from capture/activation to unstable Emulator toolbar coordinate mapping plus a stale/unavailable cached accessibility element for zoom recovery.

Another official-runtime reproduction from a fresh VitaRoute Android Emulator run:

• Codex App: 26.707.6957.0
• computer-use plugin: 26.707.51957
• @oai/sky: 0.4.20
• Android Emulator app/window binding succeeded.
• Fresh screenshot was readable at the normal viewport.
• A screenshot-bound harmless click/readback succeeded.
• The medication form opened on the first click.
• After screenshot-bound field focus and one Ctrl+A, the runner called official sky.type_text once with the exact marker A18MED601.
• Read-only checks at about 0.75, 1.5, 3, 5, 8, 12, and 15 seconds never showed that marker. The field instead contained unrelated Russian prose ending with: "ной реализации и потребуют сравнительных eval-задач."
• Input was not retried. No activate_window, zoom action, ADB UI/input/screenshot fallback, patched runtime, Browser substitution, or human assistance was used.

Classification: official Computer Use Android WebView input-integrity blocker. This run does not establish a product defect because the requested payload was already corrupted at the Computer Use input/readback boundary.

Additional official Computer Use evidence from the same Windows environment (sanitized, 2026-07-13):

Versions/target:

• Codex Desktop 26.707.6957.0
• computer-use plugin 26.707.51957
• @oai/sky 0.4.20
• Android Emulator 36.6.11, API 36 AVD, WHPX
• exact app/activity and installed APK identity were verified before every Computer Use call.

Reproduction after renderer remediation:

1. Changed only the AVD graphics mode from auto to the locally supported software mode; restarted the same AVD without wiping data. Config, APK and foreground activity hashes/identity matched.
2. Fresh official Sky capture was fully black. The single permitted read-only get_window rebind produced a byte-identical fully black capture.
3. Performed a separate cold/full boot with explicit official flags -gpu software -no-snapshot-load; verified the exact qemu command line, boot_completed=1, display ON/Awake, SwiftShader renderer, topResumed/mFocusedApp and unchanged APK hash/size.
4. A new official Sky turn again returned a fully black capture before and after one read-only rebind.
5. In another fresh turn, performed a bounded activation probe. Read-only Win32 geometry proved a non-client title-bar point: outer bounds (92,100)-(496,1002), client starts at y=131, chosen screen point (294,115), WM_NCHITTEST=HTCAPTION(2). The point was outside Android guest content and Emulator toolbar.
6. The one official screenshot-bound sky.click never clicked. It failed with GetCursorPos failed: Отказано в доступе. (0x80070005). No retry was made.

Across these turns: no zoom, activate_window, Android click/input, ADB UI/screenshot, Browser fallback, product save or CRUD mutation occurred; all product counts remained zero.

This narrows the issue beyond guest renderer/snapshot state: official capture stays black under explicit SwiftShader cold boot, and the safe non-client direct-click path is blocked by the same GetCursorPos access denial before input dispatch. Expected behavior is a readable capture and direct click in the same user/integrity session, or a specific actionable policy/session error rather than a generic access-denied cursor failure.

New read-only diagnostics isolate the black Android Emulator capture / GetCursorPos failure below the product and renderer layers.\n\nEnvironment:\n- Codex App for Windows 26.707.6957.0\n- bundled computer-use plugin 26.707.51957\n- @oai/sky 0.4.20\n- Android Emulator 36.6.11, software/SwiftShader renderer\n\nEvidence:\n- One ADB framebuffer was non-black (1080x2400) and showed the app plus a System UI ANR dialog.\n- SurfaceFlinger reported the display ON/Awake and composed both app and System UI layers.\n- PrintWindow(PW_RENDERFULLCONTENT) captured the full Emulator chrome and guest pixels.\n- Graphics.CopyFromScreen failed with "The handle is invalid".\n- direct screen BitBlt returned FALSE / Win32 error 6 and a black image.\n- a read-only GetCursorPos call outside Sky reproduced FALSE / Win32 error 5.\n- qemu, Emulator, Codex, ChatGPT, node_repl and helper node processes all had the same user SID, SessionId 2, Medium integrity and limited elevation. qemu was not elevated, so a UAC/integrity mismatch is excluded.\n- WTS active console session was 1 while the Codex automation task and Emulator were in session 2.\n- Previous official Sky captures were 99.95% black, while PrintWindow from the same task captured full content.\n\nConclusion (confidence 0.90): this is a Windows session/desktop screen-input access boundary manifested through the official Computer Use bridge. It is not a guest/app failure, GPU-renderer failure, UAC mismatch, or an inherently uncapturable Emulator surface. PrintWindow succeeds because it targets the HWND directly; Sky and the failing cursor/screen paths depend on access to the active input/screen desktop.\n\nSmallest verification/fix test: launch the official helper and Emulator in the actual active-console session, then run read-only GetCursorPos plus Sky capture for a normal window and the Emulator. The bridge should also detect/report a non-active or inaccessible input desktop instead of returning a black frame.