Windows Computer Use times out dismissing PDFelement restore-files modal while state reads succeed

Summary

On Windows, Codex Computer Use can enumerate a running PDFelement window and read its accessibility state, but cannot dismiss its "reopen previously closed files" modal. Activation, click and keyboard requests time out. This blocks unattended document review even though the PDF has already been generated and saved successfully.

This is an observed native-input failure, not a claim that PDF saving failed or that the precise root cause has been identified.

Environment

• Codex Windows app package version: 26.901.6511.0
• Windows NT version/build: 10.0.26200.0
• Wondershare PDFelement (Japanese): 11.1.1.3173
• Bundled Computer Use skill/docs: 26.901.51231
• Installed @oai/sky: 0.6.26
• Documented Window2 API via Node REPL; native-pipe route
• Observed September 8, 2026, approximately 23:30–23:57 JST

Reproduction state and steps

1. Open a local PDF in PDFelement with its restore-files prompt present. In this incident the prompt read: 最後に閉じたすべてのファイルをもう一度開きますか？ ("Reopen all files closed last time?"). Buttons: いいえ(N) ("No") and もう一度開く ("Reopen").
2. Initialize the documented @oai/sky client in Node REPL and call sky.list_windows().
3. Select the returned PDFelement window and call sky.get_window_state({window, include_screenshot: true, include_text: true}).
4. Observe that the main window is disabled and the modal appears in its accessibility tree, but is not independently returned by list_windows().
5. Try a fresh state-derived action to select No, then inspect the state again.

The startup conditions causing PDFelement to show this prompt on a fresh installation have not been independently reproduced. Multiple attempts were made against the same persistent modal, not a measured sample of independent launches.

Observed state

Sanitized excerpt:

0 Window (disabled) <document>.pdf - Wondershare PDFelement
  Secondary Actions: Raise; ID: MainForm
  1 Window PDFelement; Secondary Actions: Raise; ID: MessageForm
    ...
    6 Button btnCancel; ID: btnCancel
    7 Button btnOK; ID: btnOK

The available API exposed only the owner/main window as a returned Window.

Actual results

Exact errors include:

computer-use request timed out: activate_window
computer-use request timed out: perform_secondary_action
computer-use request timed out: press_key

After the keyboard timeout, a fresh accessibility observation confirmed that the same modal remained and the main window was still disabled. Thus no successful dismissal is claimed.

Some screenshot captures showed an occluding Codex window while the accessibility tree still described PDFelement. Those captures were not used for blind coordinate input.

Expected behavior

The native automation should be able to target a standard owned modal and activate its No button, or return a specific target/modal error that supports recovery. A generic request timeout on all input routes leaves the agent unable to complete even this simple operation.

Please investigate whether owned-modal enumeration, automatic owner-window activation, or native request completion is involved.

Diagnostic limits

The public Window2 API documentation says that input methods automatically activate their target window. The disabled owner plus non-enumerated modal is a possible explanation, not a proven native root cause. The inspected client wrapper uses a 10-second default deadline for these requests; the specific native function waiting internally remains unknown.

No vendor binary changes, private helper protocol, application-setting changes, forced termination, or security-setting changes were used. No document content, private paths, account details, screenshots, or full session logs are included.

Related, but not confirmed to share a cause: #25314 describes Windows Computer Use discovery/launch timeouts while list_windows works; this report concerns input to an already open PDF modal.

Reproduce the issue with the documented @oai/sky client in a Node REPL, using list_windows, get_window_state, and the input methods against the PDFelement modal. Compare the disabled owner window, non-enumerated modal, and 10-second request timeouts across activation, click, secondary-action, and keypress paths. Done means the No button can be activated or the API returns a specific recoverable target/modal error.