[Windows][26.908.40834] Computer Use exposes missing cua app APIs and browser request-header policy fails #45328

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   computer-use

   browser

   on Sep 14, 2026
2. github-actions commented on Sep 14, 2026

   

   github-actionsbot

   on Sep 14, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Windows Computer Use cannot discover native apps even after js_repl workaround #45148
   • Computer Use selects the browser-only runtime instead of the native Windows connector #45226
   • Windows: Edge tab discovery fails with "Unable to load browser request-header policy" #44169
   • Windows update regression: Chrome and Edge control fail with request-header policy error; in-app browser works #44140
   • Windows Computer Use exposes only browser surface; sky service is not configured #44186

   Powered by Codex Action
3. somethingsky commented on Sep 14, 2026

   

   somethingsky

   on Sep 14, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Follow-up: forcing the native @oai/sky path successfully restores Windows app control

   I ran an A/B test on the same affected Windows setup and Codex Desktop 26.908.40834.

   When I explicitly instructed Codex not to use cua_repl or the missing cua.getApp() / cua.listApps() functions, and instead required the bundled Computer Use native path through trusted node_repl + @oai/sky, native Windows control worked successfully.

   The instruction used was essentially:

   Please strictly use the computer-use skill's native Windows control path.
   
   Do not use cua_repl and do not call:
   cua.getApp()
   cua.listApps()
   
   Use trusted node_repl to initialize @oai/sky, then use:
   sky.list_apps()
   sky.list_windows()
   
   to enumerate real Windows windows.
   
   Do not use PowerShell, Start-Process, or shell as fallback.
   
   Then find Windows Notepad and type:
   hello world
   

   Result

   This worked.

   Codex reported that it enumerated the real Windows window through @oai/sky, found Notepad, typed hello world, and verified the text was visible. The document was left unsaved.

   Why this is significant

   This strongly suggests the native Windows Computer Use backend itself is functional on this machine.

   The failure appears to be in tool routing / bootstrap / API-surface selection:

   • Failing path: computer-use task routes into cua_repl and attempts cua.getApp() / cua.listApps() → both are missing at runtime.
   • Working path: computer-use task uses trusted node_repl → initializes @oai/sky → sky.list_apps() / sky.list_windows() → native Windows control succeeds.

   So this is likely not a Windows permissions problem or a broken native control bridge on the affected machine.

   A product-side fix may need to ensure that native Windows app tasks automatically initialize/select the supported @oai/sky path instead of routing into a cua_repl API surface that advertises or attempts functions that do not exist.

   It would also be useful if the runtime exposed one consistent documented API surface, or if the router detected unavailable cua.* app functions and automatically fell back to the supported native implementation rather than concluding native Computer Use is unavailable.

   The separate browser error:

   Unable to load browser request-header policy. Retry the browser command.
   

   still appears to be a distinct browser bootstrap/policy issue. This successful @oai/sky test shows that native Windows control can succeed independently of that browser-policy failure.
4. qiuiu727 commented on Sep 17, 2026

   

   qiuiu727

   on Sep 17, 2026

   More actions

   Update: current Windows 26.911.7940.0 still has no native apps in cua_repl

   Tested on Windows x64 after restarting Codex Desktop.

   • Codex Desktop package: 26.911.7940.0
   • computer-use@openai-bundled was reinstalled/refreshed locally.
   • The independent @oai/sky runtime passes strict verification and list_windows returns real windows.
   • The Computer Use session still returns apps=[]; only the in-app browser is exposed.
   • This persists after restarting Codex and after refreshing the local plugin/runtime cache.

   This indicates the Windows native backend is healthy, but the model-facing Computer Use session is not exposing native application discovery/control. Please check the session tool provisioning or cua_repl routing for the Windows Desktop build.
5. lilnewbie2000 commented on Sep 18, 2026

   

   lilnewbie2000

   on Sep 18, 2026

   More actions

   Windows Computer Use: Edge/native bridge disappears after CUA reset while built-in browser still works

   I am seeing an unstable Computer Use runtime on Windows.

   The important part is that the available Computer Use capabilities change between sessions/resets without any corresponding change to the machine.

   Initial state

   At first, Edge Computer Use worked.

   I was able to:

   • connect to Edge;
   • open a safe page such as "example.com";
   • reload the page;
   • retrieve/confirm the browser state.

   However, native Windows Computer Use was unavailable at the same time.

   The runtime did not expose native Windows APIs such as:

   • "listApps"
   • "listWindows"

   and native Windows applications could not be enumerated or controlled.

   So at this point the state was effectively:

   • Edge/browser bridge: working
   • Native Windows app bridge: unavailable

   After resetting/restarting the CUA session

   I repeated the test using a clean Computer Use session.

   After that, the connection became worse:

   browsers: []
   apps: []

   The native APIs such as "listApps" and "listWindows" were still unavailable.

   Edge was no longer exposed to Computer Use at all, even though it had worked immediately before the reset.

   Built-in Codex browser

   The built-in Codex browser still appears to work.

   This makes it look less like a general connectivity problem and more like an initialization/runtime/bridge issue affecting external browser and native Windows Computer Use surfaces.

   Observed sequence

   Session A:
   Edge/browser control = WORKING
   Native Windows apps = NOT AVAILABLE
   listApps/listWindows = NOT AVAILABLE

   CUA reset / clean session

   Session B:
   browsers: []
   apps: []
   listApps/listWindows = NOT AVAILABLE

   Built-in Codex browser = still working

   Why this seems important

   This does not appear to be tied to a specific Edge tab or website.

   The same machine went from having a functional Edge Computer Use connection to exposing no external browser at all after resetting the CUA session.

   It also suggests that browser control and native Windows control are separate surfaces/bridges: one can initialize while the other does not, and after a reset neither external surface may initialize.

   Repeated attempts inside CUA do not restore the missing interfaces.

   Expected behavior

   After starting a fresh Computer Use session:

   • installed/supported browsers should be detected consistently;
   • native Windows applications should be exposed when Windows Computer Use is enabled;
   • available Computer Use APIs should not disappear between otherwise equivalent sessions.

   Actual behavior

   The runtime exposes different capabilities between sessions, including:

   browsers: []
   apps: []

   and native Windows APIs such as "listApps" / "listWindows" may be absent entirely.

   A CUA reset can turn a previously working Edge connection into no detected browsers.

   Environment

   • OS: Windows
   • Codex Desktop
   • Computer Use enabled
   • Edge installed
   • Built-in Codex browser appears functional
   • Edge Computer Use worked before the CUA reset
   • Native Windows Computer Use did not work before or after the reset

   I can provide the exact Codex Desktop version, Windows version/build, logs, and Feedback ID if needed.
6. Nijika21 commented on Sep 29, 2026

   

   Nijika21

   on Sep 29, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows reproduction, submitted with the user's explicit consent.

   • Platform: Windows
   • ChatGPT desktop / Codex: 26.924.22138 (build 11645)
   • The app reports that it is up to date.

   A read-only Computer Use request repeatedly fails, including after resetting the CUA session, with:

   Unable to load browser request-header policy. Retry the browser command.
   

   The loaded runtime exposes these top-level methods:

   ["rewriteDocumentation","getState","browsers","getBrowser","createBrowserTab","getTab","listBrowsers","listTabs","initialize"]

   Native Windows APIs advertised by the Computer Use interface are absent, including getApp, listApps, listWindows, and computer.target.

   This indicates the combined request-header-policy initialization and missing-native-API problem reported in this issue remains reproducible on Windows production build 26.924.22138.

   No account identifiers, filesystem paths, credentials, cookies, tokens, or screen contents are included.
7. Nijika21 commented on Sep 29, 2026

   

   Nijika21

   on Sep 29, 2026 – with ChatGPT Codex Connector

   Last edited by Nijika21

   More actions

   Update: Chrome works now; the earlier failures were intermittent

   Following up on my earlier report from Windows, desktop version 26.924.22138 (build 11645).

   I need to correct something from the troubleshooting: the Chrome GPT extension was installed from the beginning. Nothing was missing, and the installation status in my first Settings screenshot was correct. Chrome control is working for me now. Please disregard the earlier suspicion that the extension was missing or that the installed indicator was wrong. I also don't have evidence of stale registration.

   Here's what the tool outputs from my session show:

   • Browser-state requests returned Unable to load browser request-header policy. Retry the browser command. Later, browser discovery returned both Chrome as an extension provider and the in-app browser, but another request failed again afterward. The error was intermittent.
   • Codex successfully entered text into Notepad and read it back twice through the bundled @oai/sky path. So my earlier report shouldn't be read as a complete failure of native Windows control.
   • I asked Codex to try Notepad again on 29 September 2026. It entered Tes Computer Use ketiga berhasil. through @oai/sky, and both the screenshot and accessibility readback confirmed the exact text. Codex didn't change the Chrome toggle or extension settings for this test. Native input works now, although that doesn't explain the earlier browser error.
   • The early tool documentation advertised native cua methods. A later Object.keys(cua) check didn't list them. I overstated this in my earlier comment: that check alone doesn't prove the methods were absent or unusable. I'd still appreciate clarification on the difference between the advertised methods and the enumeration result. The current browser-only interface also doesn't tell us what the earlier session documented.
   • I toggled Chrome control during troubleshooting, but the runtime/session conditions weren't held constant. I can't say the toggle fixed anything.
   • The earlier failures and successes were recorded under gpt-5.6-sol. Later turns used gpt-6-astra. That doesn't support blaming the failure or recovery on a model change.

   Could you investigate the intermittent browser initialization error separately from the documentation/API discrepancy? I don't have evidence that this was caused by account restrictions, a new policy, or corrupted files.

   Chrome working now is my own confirmation; Codex's fresh automated test for this follow-up was limited to Notepad. I haven't reproduced the earlier browser failure under controlled conditions, and I don't know why it recovered or whether the recovery is permanent.