Repository navigation
Windows update regression: Chrome and Edge control fail with request-header policy error; in-app browser works #44140
Description
Codex App version
26.903.8094.0 (Windows x64); bundled browser component 26.903.61454.
Subscription
Not included in this report.
Platform
Windows x64.
What issue am I seeing?
Browser control worked normally before I updated Codex. After the update, controlling Chrome and Edge fails with:
Unable to load browser request-header policy. Retry the browser command.
This blocks my external-browser workflows. My Chrome ChatGPT extension is version 1.26.901.11451, enabled, and shows no visible error. I did not record the previous working Codex version.
Important scope clarification: In a subsequent test, Codex's built-in browser successfully opened https://example.com/, read its content, clicked “Learn more,” and read the resulting IANA page. The failure I reproduced is in Chrome and Edge control; I am not claiming that every browser backend is broken. The successful in-app test was later, rather than a simultaneous comparison with the external-browser failures.
Steps to reproduce
- Update Codex from a working installation.
- Launch Chrome with the ChatGPT extension enabled.
- Ask Codex to inspect browser state.
cua.getState()repeatedly fails after approximately 20–21 seconds with the error above. - Launch the Edge profile containing the ChatGPT extension and ask Codex to open a test page. An explicit call also fails:
await cua.createBrowserTab('edge', 'https://example.com', {
sessionName: 'Edge connection test'
});- For comparison, a subsequent built-in-browser test succeeds:
await cua.createBrowserTab('iab', 'https://example.com', {visible: true});Opening, reading, and clicking through a link were all verified in that built-in-browser test.
Expected behavior
I expect Chrome and Edge control to keep working after updating Codex, as they did before the update.
Troubleshooting and diagnostic evidence
I troubleshot this with Codex:
- Fully restarting Codex did not fix the external-browser failure.
- Resetting the CUA JavaScript session did not fix it.
- Desktop logs report the extension installed and the bundled Chrome plugin current.
- The bundled
browser-service.mjsthrows this exact error when Statsig initialization is unsuccessful or the client is not Ready, before obtaining thecodex_browser_use_agent_request_headergate. - Desktop logs also record
Timed out while fetching post-login Statsig bootstrap. This is related evidence, not proof that both initialization failures have the same underlying cause. - An independent valid Statsig initialization POST from the bundled Node runtime on my machine returned HTTP 200 with a complete response in approximately 3.2 seconds, using a synthetic diagnostic identity. This does not prove that the browser tool's own request path works.
- FlClash TUN was active; the Windows system proxy was disabled. No proxy, extension, or security-policy settings were changed during diagnosis.
I can confirm the before/after update behavior, but I do not know which internal change caused it. Please investigate the external-browser request-header-policy initialization path and provide an actionable underlying error.
Related report
Related: #44112. I previously added my evidence there: #44112 (comment). I am opening this standalone report to document my update regression, the exact versions, Edge reproduction, and the later successful built-in-browser comparison together.
No credentials, cookies, private page content, or raw account logs are included.
Activity
github-actions commentedon Sep 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jiangyuShiro commentedon Sep 10, 2026
Follow-up — September 10: recurrence on 26.903.9818.0 and repeatable network-dependent behavior
I have new reproduction evidence from testing with Codex on the same Windows computer.
Versions and timeline
Network-switch comparison on the same updated installation
I then switched between the campus network and the phone hotspot and asked Codex to perform the same operation:
For both the final campus run and the final hotspot run, Codex explicitly reset its CUA JavaScript session before creating the test tab, rather than continuing through the previously successful tab/session. No app update or settings edit was performed by Codex during these comparisons. Effective DNS, proxy routing, and egress were not independently captured, so I cannot yet isolate which part of the changed network path matters.
Correction to my earlier interpretation / investigation request
I initially interpreted today's successful operation after updating as a fix. The new evidence does not establish that the update caused recovery: my working afternoon session used mobile data, and the failure now reproduces on the same updated version depending on the connection.
This strongly supports a network-path-dependent failure in the browser-control initialization flow on my machine. It does not establish that the campus network deliberately blocks anything, that the user network is necessarily at fault, or that there is a universal OpenAI outage. A client-side compatibility/timeout/recovery defect or service behavior varying by request path remains possible; no root cause has been confirmed.
The local browser-service code still requires successful Statsig initialization before reading
codex_browser_use_agent_request_header. Please investigate that request path and expose the underlying request error/status and timeout details, so users can distinguish transport failures from configuration/service failures. Related reports #44112 and #44169 contain the same error, but their underlying causes have not been independently established.Today's network comparison tested Chrome only. My earlier Edge failure and successful in-app-browser comparison remain historical observations, not fresh cross-network tests.
e-ltcode commentedon Sep 10, 2026
Additional reproduction on Windows, observed on 2026-09-10 and submitted with the user's authorization.
Versions: OpenAI.Codex desktop package 26.903.9818.0; bundled Chrome plugin 26.903.71938; ChatGPT Chrome extension 1.26.901.11451_0.
await cua.getState()andawait cua.listTabs({browser:"chrome"})repeatedly fail after approximately 20 seconds with:One attempt also returned
Timed out waiting for Statsig values.No Chrome tab inventory is returned.Checks and recovery attempts:
Read-only inspection locates the exact error in Statsig initialization/readiness checking in the bundled browser service. This identifies the failure location, not the cause. A direct unauthenticated request to the configuration service from bundled Node returned HTTP 403; this is only basic reachability evidence and does not validate the tool's configuration request path. No alternate-network comparison was performed on this installation, so the network-dependent behavior in the preceding comment is not independently confirmed here.
Please expose the underlying configuration request error/status and investigate why Chrome initialization remains unavailable despite valid local integration checks. No credentials, private page content, account identifiers, or raw logs are included.
Cursedoonnee commentedon Sep 14, 2026
Still reproducible on a newer Windows build:
External Browser Use still fails with:
Unable to load browser request-header policyOne difference from this report:
the in-app browser does NOT work for me either. It fails with:
Browser is not available: iabSo on my newer build, both the external-browser path and the IAB path are unavailable.
li1553770945 commentedon Sep 14, 2026
Additional macOS reproduction — September 14, 2026
I can reproduce the same failure on macOS after updating Codex Desktop today. External Chrome control worked before the update and stopped working immediately afterward.
Environment
Observed behavior
Three attempts to open
https://example.comthrough Chrome failed, including a fresh attempt after resetting the CUA JavaScript runtime:Unable to load browser request-header policy. Retry the browser command.A read-only browser inventory call reported that Google Chrome was running, but returned:
{ "browsers": [], "errors": [ "Browsers: Error: Unable to load browser request-header policy. Retry the browser command." ] }The same attempt also reported:
The failure occurred before a Chrome tab was created or the target page was loaded.
For comparison, the in-app browser successfully opened Google Search, navigated to this GitHub issue, and read the page on the same machine and network.
No browser, proxy, or security settings were changed during diagnosis. I cannot determine whether the update itself caused the failure, but the before/after behavior and the matching error suggest this may not be Windows-specific.
Please investigate the external-browser request-header-policy initialization path on macOS and expose the underlying request status or error so users can distinguish client, configuration-service, and network-path failures.
liuyaochen commentedon Sep 21, 2026
Sharing a verified macOS 26.915.31945 workaround for the same error: #44988 (comment)
In our case, the Statsig initialize response was too slow uncompressed. Explicit Brotli transfer reduced it to about 670 KB; the browser transport returned those compressed bytes without a Content-Encoding header, so the wrapper also needed to handle that missing metadata. After the narrow compression/decoding fix, a fresh CUA kernel opened example.com in Chrome and read Example Domain on the same network, with the original policy checks and SDK timeouts retained.
The linked comment includes code, how to identify the actually loaded service, verification and rollback guidance. This is an unofficial local app-bundle workaround, may be overwritten by updates, and has not been validated on Windows/Edge or for every cause of this generic error. No policy bypass is involved.
zweek9999-prog commentedon Oct 8, 2026
Additional reproduction from a Windows 10 Pro x64 host (build 19045) on 2026-10-08, posted at the affected user's request.
The desktop app was updated from MSIX 26.930.7945.0 to 26.1002.6548.0 on October 7. That update also triggered a separate elevated-sandbox failure reported in #51590. After a full rollback, the running desktop executable is again from 26.930.7945.0, and ordinary sandboxed commands and native Computer Use recovered. The external-browser failure below still persists on the rolled-back version; it should not be conflated with the sandbox ACL/sharing-violation error.
await cua.getState()identifies two Chrome extension-backed profiles, but returns no tabs for either and reportsUnable to load browser request-header policy. Retry the browser command.for each before any page interaction (approximately 24 seconds).cua.createBrowserTab('iab', 'https://example.com', {visible:false})succeeded and read the public page (title: “Example Domain”). The in-app browser is therefore available.cua.createBrowserTab('edge', 'https://www.wikipedia.org/', ...)returnedBrowser is not available: edge; no Edge page was opened. This is a separate observation, not a claim that Edge produced the request-header-policy error.Please investigate the external-browser request-header-policy initialization path, surface the underlying failure instead of only “Retry,” and provide a supported recovery. We have not isolated the code-level cause or identified a security exploit. No credentials, cookies, browsing history, extension IDs, private URLs, user paths, or raw logs are included.