Windows Computer Use: WinForms modal input loses focus to disabled owner; set_value fails with CacheRequest 0x80070057

What version of the Codex App are you using?

Installed Windows AppX package: 26.901.4073.0 (read from package metadata, not the About dialog).
Bundled Computer Use skill/package directory version: 26.901.31953.
Using the documented @oai/sky window2 APIs through the persistent Node REPL.

What subscription do you have?

Not included in this sanitized report.

What platform is your computer?

Windows, OS version 10.0.26200.0.
Target application: an existing 32-bit WinForms desktop application, with a main window and an owned modal data-entry dialog.

What issue are you seeing?

Computer Use can identify and focus an editable control in the modal dialog, but keyboard/text input targeting the available window object moves focus back to the disabled main window. No text reaches the dialog.

The alternative set_value path fails before writing with this exact error:

read UIA value read-only state: 所需属性不在 CacheRequest 中 (0x80070057)

Translation of the localized portion: “The requested property is not in the CacheRequest.”

What steps can reproduce the bug?

This is the sequence observed in the existing WinForms application; a standalone minimal application has not yet been created.

1. Start with a fresh Node REPL session, import the documented Computer Use client, and select the application's main window from the returned app/window inventory.
2. Open an owned modal data-entry dialog containing an empty editable text box. The owner becomes disabled, as expected for the modal dialog.
3. Call list_apps and list_windows. Only the main window is returned as a targetable Window object; the modal dialog is not separately exposed.
4. Request get_window_state with both screenshots and accessibility text. The dialog and its edit control are visible in the main window's accessibility tree and transient screenshot.
5. Invoke the modal dialog's advertised Raise secondary action through perform_secondary_action. Refresh state in the documented observe/action loop. The focused element is now the modal edit control, and its caret is visible.
6. Send a single ordinary letter using press_key with key a, targeting the returned main-window object. Refresh state.
7. The focused element is now the disabled main window, and the modal text box remains empty. type_text also fails to enter text into the modal.
8. Refresh the accessibility tree and try set_value on the observed modal edit-control index. It returns the CacheRequest error above. The field remains empty.

What is the expected behavior?

Input should reach the focused editable control in the selected application's active modal dialog, without re-focusing its disabled owner. Alternatively, the modal should be exposed as a supported targetable Window.

Direct set_value on an observed editable control should succeed or report a meaningful control limitation, rather than failing while reading a UIA cached property.

Additional information

Recovery attempts: Resetting the Node REPL, re-importing the client, refreshing the app/window inventory, re-binding the returned window, and using the modal's Raise action did not resolve either failure.

Same-process control test: After closing the still-empty modal, type_text into the main window's search box successfully entered Chinese characters, ASCII letters, and digits. The test text was then cleared. This narrows the input failure to the modal path rather than general text input into this application.

Related report: #36603 describes Windows owned-dialog targeting problems in Chrome. In that report, raising the dialog before keyboard input is a working workaround. In this WinForms case, that workaround was explicitly tested and fails: the next key action moves focus back to the disabled owner. The additional set_value CacheRequest error blocks the other documented entry path. A targeted issue search did not find an existing report with this exact read UIA value read-only state error in its body.

The underlying implementation has not been inspected or patched, so owner activation and UIA caching are investigation leads, not confirmed internal root causes. No application source, account identifiers, local paths, business data, screenshots, or conversation transcripts are attached. No business record was saved during these diagnostics.

Start by reproducing the modal-dialog sequence through the documented @oai/sky window2 APIs in a persistent Node REPL, including Raise, press_key, type_text, and set_value. Trace the Windows UI automation handling for owned modal dialogs and cached value properties. Done means input reaches the active modal control or the modal is targetable, and set_value reports no CacheRequest error.