Codex Can Read a Windows App but Cannot Capture It: Diagnose the Failure Stage

If Codex can list a Windows app and read its text but cannot take a screenshot or obtain pointer coordinates, record those as separate results. Text access does not establish that capture works, and a capture failure does not establish that the app was never authorized.

This is a diagnostic guide based on public OpenAI repository reports and official documentation. It is not a tested repair for Windows. Our local permission checks on October 18, 2026 stopped before native text, screenshots or clicks; we did not reproduce a Windows capture failure or test an Intel Mac. The useful output here is a failure-stage record that distinguishes access policy from initialization, capture and interaction.

Ofox publishes this guide. Switching model providers or purchasing API access is not an established fix for a local Computer Use capture problem.

Identify the first failed operation

A desktop task has several observable stages. Run only the next authorized stage and retain its first error.

For the text test, put a phrase such as CU-CHECK-20261018 in a new unsaved test document. Avoid private chats, credentials and production admin screens. Record the actual application and version; a result from a different app is only a comparison, not proof that the original app is fixed.

If access is denied, stop there. “Screenshot not tested” is the correct result, not “screenshot failed.” Do not use a different tool or another chat to bypass a denial. A separately authorized file task can still be useful, but belongs in a different result row.

What the Windows reports actually show

Issue #54235 describes Windows 10 LTSC build 19044, where app discovery or text access worked but capture and pointer geometry did not. The report also describes a virtual-display isolation attempt that did not restore the failing path. That is evidence against recommending that attempted change as a guaranteed fix for this case, not proof of a universal Windows cause.

Issue #54139 provides another report in the capture-failure area. Keep an exact error such as a FrameArrived timeout if it appears in your own logs, including which operation produced it. Do not copy the error into your record merely because it appears in someone else’s issue.

The causal chain remains unresolved by these reports alone. A screenshot timeout can coexist with working text access because the observations exercise different paths. It does not follow that the display driver is defective, the model is incapable, or every Windows installation is affected.

For comparison, issue #54225 and #54157 describe initialization failures around MXC and 0x80070003. If the system fails before returning a browser or app inventory, use that earlier failure as the starting point. Troubleshooting screen capture assumes you actually reached capture.

Run a minimal test without changing the environment first

Use the official Computer Use setup guidance to establish the supported setup. It says Windows targets must remain visible on the active desktop. Confirm the target is the intended window and the session is usable; do not start by reinstalling applications or changing drivers.

Give Codex a bounded task:

Use only the named test application and its new synthetic document.
Do not access other windows or change system/security settings.
Record the application, operating system and available version data.

1. List the available target windows.
2. If authorized, read the visible test phrase from the selected window.
3. Request one current screenshot of that same window.
4. Only if the required observation and geometry are available, use
   one harmless control and read the resulting state.

At the first failure, preserve the exact operation and error.
Mark later stages not tested. Never click using an old screenshot
or guessed coordinates. Do not change permissions or drivers.

A harmless control might expand a menu or switch between two test tabs. Choose it from the current interface, not a guessed coordinate. If text-based controls work but coordinate actions fail, record the distinction instead of reporting that all interaction is broken.

A screenshot must be current. A successful image from an earlier app, earlier window size or earlier session cannot justify a new click. If capture fails, stop coordinate-based actions rather than treating an old picture as a fallback.

Keep permission failures out of the capture bucket

Our local attempt returned an application approval refusal before the app opened. A separate browser navigation also failed its origin approval. The inventory had succeeded, but neither later result established a screenshot fault. We did not attempt to work around either refusal.

This is a real permission-boundary observation, not a Windows reproduction. It demonstrates why a diagnostic table needs “not tested” as well as “pass” and “fail.” Treating every unavailable action as a capture defect would send the investigation toward the wrong component.

On macOS, system Screen Recording and Accessibility permissions are separate from approval to use an individual app, as the official documentation explains. A system toggle being enabled therefore does not prove that a particular app request was approved. For that broader problem, use the existing Computer Use permission guide, rather than applying Windows display advice.

Compare environments without claiming a fix

A browser/native comparison can narrow the failure: browser text and screenshots may work while a native app cannot be captured. But a browser permission refusal gives no such positive control. Record the actual browser, profile, task type and observation, not just “browser works.”

Issue #51927 discusses differences involving task creation paths. A different task path can be a useful authorized comparison, but it is not a universal recovery method and must not be used to escape a rejection. Issue #42514 concerns Intel Mac native-service behavior; its platform and architecture make it a separate branch from Windows capture.

An upstream source-code fix is also not the same as a verified desktop release. Before saying an update repaired the issue, identify the installed desktop version, the relevant release evidence and the result of the same minimal task afterward. A standalone CLI version number does not identify every component bundled with the desktop app.

Send a useful, redacted diagnostic record

Use this template after the bounded test:

Observed at / time zone:
OS edition, build and CPU architecture:
Desktop app version / installation channel:
Computer Use plugin version, if shown:
Task type and target app/version:
First failed stage and exact operation:
Exact error (remove credentials and private paths):
Discovery result:
App approval result:
Text phrase result:
Screenshot result:
Interaction method and result:
Any earlier successful comparison, with its environment:
One change made, if any, and the same-task retest result:
Later stages not tested:

Avoid uploading complete configuration files, private screenshots or tokens to a public issue. Share the smallest relevant excerpt and platform details. If an upstream issue asks for additional diagnostics, assess the data before sharing it.

Recovery is established when the previously failing operation succeeds in the intended environment and the next required action is verified. A closed issue, enabled permission toggle, successful restart or readable app text does not independently establish that result. Until then, report the exact working subset and the remaining failure. If the user only needs a document deliverable, an explicitly authorized file validation workflow can complete that separate task without claiming that desktop capture was repaired.