Windows Appshots: load_appshot_capture_source times out after successful start (multi-monitor)

What version of the Codex App are you using (From “About Codex” dialog)?

Desktop release 26.908.40834, verified from the current app log (About dialog not inspected).
Installed MSIX package version: OpenAI.Codex_26.908.4834.0_x64.

What subscription do you have?

Not included in this report.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

• Multi-monitor setup: Chrome on a secondary monitor, ChatGPT/Codex on the primary monitor.
• Google Chrome: 152.0.7977.84.
• GPU reported by Windows: Intel(R) Arc(TM) 130T GPU (16GB); driver 32.0.101.8826.
• Active per-monitor scaling and coordinates have not been verified.

What issue are you seeing?

Pressing both Alt keys correctly dispatches an Appshot request and identifies Google Chrome. The capture-start request returns successfully (hasResponse=true), but the Windows capture bridge then times out while loading the source image:

computer-use request timed out: load_appshot_capture_source

The UI shows 无法附加智能快照 (“Unable to attach appshot”). The request ends with failureReason=native_completion_failed, hadScreenshot=false, and hadAxText=false.

This is intermittent in the observed session: a Chrome Appshot succeeded, followed by two failures within about 20 seconds. The monitor location of the successful attempt was not independently recorded, so it is not evidence of a successful primary/secondary-monitor comparison.

Sanitized log excerpts from 2026-09-14 (timestamps UTC; request identifiers, local user paths, and unrelated fields omitted):

05:19:54.402Z Appshot capture settled elapsedMs=1570 hadAxText=true hadScreenshot=true source=hotkey status=success

05:20:00.517Z Appshot shortcut found target name="Google Chrome" frontmostWindowElapsedMs=2
05:20:00.676Z Appshot capture start request finished elapsedMs=144 hasResponse=true source=hotkey
05:20:02.663Z [windows-capture-native-bridge] Windows Appshot completion failed errorMessage="computer-use request timed out: load_appshot_capture_source"
05:20:02.669Z Appshot capture settled elapsedMs=2143 failureReason=native_completion_failed hadAxText=false hadScreenshot=false permissionGrantState=undefined source=hotkey status=failed

05:20:11.983Z Appshot shortcut found target name="Google Chrome" frontmostWindowElapsedMs=8
05:20:12.131Z Appshot capture start request finished elapsedMs=135 hasResponse=true source=hotkey
05:20:14.138Z [windows-capture-native-bridge] Windows Appshot completion failed errorMessage="computer-use request timed out: load_appshot_capture_source"
05:20:14.142Z Appshot capture settled elapsedMs=2154 failureReason=native_completion_failed hadAxText=false hadScreenshot=false permissionGrantState=undefined source=hotkey status=failed

What steps can reproduce the bug?

Observed workflow; deterministic reproduction and the causal role of multiple monitors are not yet established:

1. Run the above Windows desktop release in a multi-monitor setup.
2. Keep ChatGPT/Codex on the primary monitor and Chrome on a secondary monitor.
3. Bring Chrome to the foreground and press both Alt keys.
4. Observe that the hotkey dispatch and capture-start acknowledgment succeed.
5. On the failing attempts, about 2 seconds later, “Unable to attach appshot” appears and no screenshot or window text is attached.

Two consecutive failing requests were recorded at 05:20:00 UTC and 05:20:11 UTC. A controlled same-window primary-versus-secondary-monitor test has not been completed. Restart recovery has not been verified.

What is the expected behavior?

The frontmost Chrome window should be captured and attached when it is on a secondary monitor and the ChatGPT/Codex composer is on the primary monitor. If capture cannot complete, the app should expose an actionable reason or supported recovery step.

Additional information

Read-only inspection of the installed app bundle shows a 2000 ms timeout for loading the Appshot source image and a separate 5000 ms completion timeout. The observed failures match the source-image timeout. This identifies the failing stage, not the underlying cause.

Possibly related: #45234, which reports Windows Appshot failures in the same desktop release. That report has hasResponse=false / start_response_missing. This report differs: capture start returns hasResponse=true, then load_appshot_capture_source times out with native_completion_failed.

No exact match for this timeout signature was found in the issue search. Please advise whether this should be tracked with #45234 and whether additional supported display/capture diagnostics would help. The report includes only sanitized diagnostic excerpts, not full logs or captured page content.

Start at the Windows capture bridge and the load_appshot_capture_source completion path named in the logs; reproduce the timeout with Chrome on a secondary monitor and compare it with a primary-monitor capture. Trace the 2000 ms source-image timeout and the separate completion timeout. Done means secondary-monitor captures complete reliably or expose an actionable recovery reason, with regression coverage if the relevant tests are found.