Repository navigation
Windows: browser request-header policy failure persists after restarts; native fallback cannot verify URL #45910
Description
Summary
Reporting at the user's request, based on repeated tool failures observed on 16 September 2026 in Codex desktop on Windows with Google Chrome. Browser automation had worked earlier in the same conversation (13–15 September), but now fails before browser discovery/navigation. The root cause is unknown.
Related reports: #45678, #44112, #44140, #44169. This reproduction also includes the outcome of the supported native Windows Computer Use fallback.
Steps to reproduce
- Open Chrome and Codex desktop on Windows.
- Ask the assistant to inspect browser state using
mcp__cua_repl.js:await cua.getState();
- The call repeatedly fails, typically after about 20–30 seconds.
- Direct
cua.createBrowserTab(...)calls fail with the same policy error before a page can be inspected.
Actual result
Unable to load browser request-header policy. Retry the browser command.
The inventory result is:
{"apps":[],"browsers":[],"errors":["Browsers: Error: Unable to load browser request-header policy. Retry the browser command."]}The empty lists accompany a discovery error; they do not establish that Chrome is closed. A separate attempt also returned Timed out waiting for Statsig values. This is an observed symptom, not a confirmed root cause.
Recovery attempts
- Repeated the suggested browser command retries.
- User reported restarting both Chrome and Codex; the same failure persisted afterward.
- Reset the CUA JavaScript session and retried discovery; one fresh attempt timed out after 30 seconds and reset the kernel.
- Tested the installed Windows Computer Use skill through its supported
@oai/skyruntime.sky.list_apps()successfully returned Chrome and its open window. A subsequentsky.get_window_state(...)stopped Computer Use with:
Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.
The assistant stopped as instructed. No policy checks were disabled or bypassed.
Expected behavior
Browser discovery should work for an authorized browser task, or report an actionable prerequisite/network/service failure. Repeatedly advising a retry does not recover the workflow in this session.
Environment and scope
- Windows desktop; Google Chrome.
- Exact desktop, browser and extension versions have not been verified and are intentionally not guessed.
- Installed native Computer Use skill path indicates bundle version
26.908.70816; this is not asserted to be the desktop app version. - The failure occurs before the target page is inspected. We have no evidence of a target-site restriction.
- No credentials, private messages, account identifiers, raw session logs, or user-specific filesystem paths are included.
Please investigate the browser request-header-policy initialization failure and whether the native URL-verification failure is related. No causal relationship between those two errors has been established.
Activity
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
MickeyWzt commentedon Sep 20, 2026
Additional reproduction on Windows, tested on September 20, 2026:
browser-service.mjsfiles have identical SHA-256 hashes.The supported
cua_replentry point repeatedly fails:The result contains
browsers: []and the same error. After resetting the CUA JavaScript kernel, a fresh attempt still failed after approximately 22.43 seconds. A subsequent attempt failed after 20.07 seconds. Binding an already-open Chrome tab by its explicit URL also failed before page content was read.Read-only inspection of the shipped component shows a 10-second Statsig initialization/user-update timeout. The request-header path requires a successful result, a Ready client, and a recognized gate. No policy or URL-verification checks were changed.
Desktop startup logs from September 19 also contain:
These are earlier startup events, not a capture of the September 20 failing request.
Network observations, with important limits: a local system proxy and TUN are enabled. During reproduction, several connections to
ab.chatgpt.comcontinued downloading after 20 seconds; their originating process was not identified. An anonymous initialization probe received HTTP 200 headers but downloaded only 48,875 bytes before a 15-second timeout. A temporary exact-domain route through another existing proxy timed out during connection establishment. The original configuration and manual selections were restored and verified. These observations do not establish the exact authenticated request's failure or prove that network latency is the sole cause.This report concerns policy initialization, not a new reproduction of the protected-file copy failure in #34764. Browser control remains unavailable; empty inventory is not evidence that Chrome is closed or all native desktop control is broken.
Could maintainers provide a supported way to capture the underlying trusted-fetch status, transport error, and Statsig initialization result? An actionable diagnostic and supported recovery path would help distinguish transport failure from SDK/policy initialization failure without weakening the checks.
Prepared with AI assistance from locally observed results. No account identifiers, private URLs, chat content, credentials, proxy addresses, raw logs, or screenshots are included. No installed application code or safety checks were patched during these tests.
osamaJamel commentedon Sep 26, 2026
Additional reproduction on 26 September 2026, at the user's request:
await cua.getState()failed twice, each after about 20 seconds, withUnable to load browser request-header policy. Retry the browser command.The returned browser inventory was empty because discovery failed; this does not show that Chrome was closed.cua.createBrowserTab("chrome", ..., {sessionName: ...})attempt then failed with the same error after about 20 seconds, before the destination page could open. No browser policy checks were bypassed.The cross-network reports make a single local ISP explanation less likely, but do not establish a shared root cause or a service outage. Could maintainers check whether this is a known policy/bootstrap incident and provide an actionable diagnostic or supported recovery path? No private site URL, credentials, account identifiers, or raw logs are included.