Windows Computer Use rejects Chrome modal dialog HWND and can capture Codex instead

Summary

On Windows, Computer Use can discover and capture a native transient dialog owned by a target app through UI Automation, but rejects every click in that dialog because the point belongs to a different HWND than the selected parent window. The same state request can also return screenshots of the Codex app instead of the selected Chrome window/dialog.

This blocks ordinary workflows such as Chrome's Load unpacked folder picker.

Environment

• Windows 11 Home 10.0.26200 (build 26200)
• Codex Desktop 26.727.6591.0
• Computer Use plugin 26.727.51351
• Chrome 151.0.7922.72
• Two monitors; target monitor is 120 DPI / 125% scale
• codex doctor: 17 ok, 0 warn, 0 fail
• Helper and Chrome window/dialog all report GetDpiForWindow(...) == 120

Reproduction

1. Select a Chrome window with Computer Use.
2. Navigate to chrome://extensions, enable Developer mode, and activate Load unpacked.
3. Call sky.get_window_state({ window: chromeWindow, include_text: true }).
4. Observe that the accessibility tree contains a native #32770 dialog with edit Folder: and button Select Folder.
5. Click the dialog's edit control by element_index or by coordinates from the transient screenshot.

Actual behavior

The helper refuses the input:

point (...) is over chrome.exe "", not target window chrome.exe "Extensions - Google Chrome"; activate the target or take a fresh screenshot before retrying

Additional verified behavior:

• list_windows() returns only the parent Chrome top-level window, not the dialog.
• Supplying the native dialog HWND manually returns window is not a usable app window.
• perform_secondary_action(..., action: "Raise") on the dialog can focus it, and then keyboard input works. That is the only reliable workaround.
• Some get_window_state results contain the correct UIA tree for Chrome/dialog but screenshot images of Codex Desktop, so screenshot and accessibility sources can disagree.
• Physical coordinates are scaled correctly from logical coordinates at 125%; parent Chrome, dialog, and helper overlay all use 120 DPI. This is not a DPI conversion failure.

Expected behavior

Computer Use should treat a visible owned/modal transient window as an allowed input target when it belongs to the selected app/process tree and appears in the selected window's captured transient UI.

At minimum:

1. expose owned modal dialogs as usable target windows, or
2. allow input into an owned modal HWND when the state/screenshot came from that transient window, and
3. validate that each returned screenshot belongs to the requested target/transient window instead of silently returning Codex or another window.

Safety note

The current wrong-window screenshot behavior can capture unrelated private content and can mislead subsequent model actions. Failing closed with an explicit target mismatch is preferable to returning a screenshot from another app.