Repository navigation
Desktop CUA browser automation fails: authenticated_fetch exceeds Statsig policy timeout and returns after NetworkCore timeout #44761
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.903.61454
What subscription do you have?
ChatGPT Pro (5x usage)
What platform is your computer?
OS: Arch Linux Codex CLI: 0.154.0 ChatGPT Desktop / CUA bundle: Desktop browser component: 26.903.61454 Chrome extension: ID: hehggadaopoacecdllhhajmbjkdcmajg
What issue are you seeing?
Symptom
Desktop CUA browser automation can detect the Chrome extension instance successfully:
cua.listBrowsers()succeedscua.getBrowser()succeeds
However, browser tab operations fail during browser request-header policy initialization.
The failing operation:
browser.user.openTabs()
returns:
Unable to load browser request-header policy. Retry the browser command.
The Chrome extension itself remains usable from the ChatGPT sidebar.
Investigation summary
The issue does not appear to be caused by:
- Chrome extension installation
- Native Messaging manifest
- stale chrome-native-hosts entries
- approval permission settings
- Desktop proxy startup arguments
The failure happens after browser discovery, during the authenticated fetch flow used for browser request-header policy initialization.
Observed behavior
The request appears to involve two timeout layers:
Statsig NetworkCore timeout:
~10 seconds
↓
authenticated_fetch / reqwest client timeout:
~30 seconds
Observed examples:
Request A:
t=0
authenticated_fetch starts
t=10s
NetworkCore timeout
t=30s
bridge fulfilled with HTTP 200
Request B:
t=0
authenticated_fetch starts
t=10s
NetworkCore timeout
t=30s
bridge rejected
This suggests cancellation may not propagate from the JS layer to the underlying authenticated_fetch task.
Static investigation
Observed request path:
browser-service.mjs
|
runtime.fetch
|
globalThis.nodeRepl.fetch
|
authenticated_fetch message
|
JsRuntimeManager::handle_authenticated_fetch_request
|
Reqwest HTTP client
The embedded node_repl reports:
nodeRepl.fetch request failed
A 30-second timeout configuration exists during the HTTP client construction.
Questions
Could maintainers confirm:
- Is the 30-second reqwest timeout expected behavior for authenticated_fetch?
- Should Statsig NetworkCore cancellation abort the underlying authenticated_fetch request?
- Is there a debug mode to preserve the original reqwest error instead of converting it into:
nodeRepl.fetch request failed
- Has this behavior changed in newer Desktop CUA bundles?
Additional notes
No source files were modified.
All diagnostics were performed with read-only inspection.
The issue reproduces with a single:
browser.user.openTabs()
call.
What steps can reproduce the bug?
Steps to reproduce
- Start Codex Desktop with Desktop CUA browser automation enabled.
- Ensure Chrome extension bridge is available.
- Verify browser discovery:
cua.listBrowsers()
cua.getBrowser()
Both succeed.
- Execute:
browser.user.openTabs()
- Observe the failure:
Unable to load browser request-header policy. Retry the browser command.
Expected behavior
browser.user.openTabs() should return the current browser tabs successfully.
Actual behavior
The request waits for the authenticated_fetch timeout chain and eventually fails after the browser policy initialization timeout.
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Sep 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
chris93007-wq commentedon Sep 16, 2026
+1
lcawliet commentedon Sep 17, 2026
Cross-referencing a measurement that may be relevant to the timeout/cancellation analysis here.
Reproduced on Windows with the same failure (Codex Desktop 26.908.9136, browser plugin 26.908.70816, Edge extension 1.26.901.11451):
codex_browser_use_agent_request_headergate inbrowser-service.mjs(_k()), invoked from the extension browser client'ssendSessionRequest()— i.e. before any tab operation, matchingbrowser.user.openTabs()failing first.sinceTime: 0, synthetic userID, no page/tab data) returns HTTP 200 with a 4,774,624-byte body —dynamic_configs1128 entries ≈ 95%,layer_configs162,feature_gates398,is_delta:false.authenticated_fetchpath succeed (e.g.https://chatgpt.com/backend-api/aura/identity), so auth and the IPC bridge work; the only difference we can find between the working and failing call is the response size.node_repl.execontains the stringnodeRepl.fetch response is too largenext tonodeRepl.fetch request failed/nodeRepl.fetch response read failed, which looks like a response-size cap on this bridge.So the ~30 s wall time you measured may be the bridge reading/attempting a multi-megabyte body rather than a pure timeout, and the Statsig ~10 s NetworkCore timeout would fire while that transfer is still in flight. A size limit on the bridge would also explain why cancellation doesn't appear to propagate.
Full measurement, environment and acceptance criteria: #46129
ztzwj2020 commentedon Oct 8, 2026
Adding a Windows reproduction on 2026-10-08. Browser discovery succeeds and the Chrome extension sidebar works, but tab enumeration still fails before navigating to any target website.
Environment:
Observed failures:
Checks already performed:
No runtime patches, policy bypasses, credential/Cookie extraction, or security-setting changes were used. We have not established a timeout, response-size, authentication, or proxy root cause.
Is there a supported diagnostic that preserves the underlying error for this browser request, or a confirmed fixed desktop/browser-component version? Please advise which narrowly scoped, redacted diagnostics would help. An in-app feedback report has also been submitted.