Repository navigation
Windows: Edge tab discovery fails with "Unable to load browser request-header policy" #44169
Description
Summary
In Codex Desktop on Windows, a read-only request to connect to Microsoft Edge and list its existing tabs fails before browser discovery completes. Two consecutive calls returned the same error:
Unable to load browser request-header policy. Retry the browser command.
This report was prepared and submitted by Codex at the user's request, based on tool outputs observed in this conversation on 2026-09-09.
Environment
- Codex Desktop on Windows.
- Requested browser: Microsoft Edge.
- Tool:
mcp__cua_repl.js, usingcua.getState(). - Exact Codex Desktop and Edge versions: not verified. A read-only
Get-AppxPackage -Name OpenAI.Codexquery returned no rows in the execution context, so no app version is inferred from it.
Steps to reproduce
- In Codex Desktop, request: “Please connect to my Edge and only list the tabs, read-only.”
- Invoke the browser inventory entry point:
await cua.getState();
- Observe the error below.
- Retry the same command, as suggested by the error. In this session, the retry failed identically.
Actual behavior
Both calls returned:
{
"apps": [],
"browsers": [],
"errors": [
"Browsers: Error: Unable to load browser request-header policy. Retry the browser command."
]
}The calls took approximately 21.7 seconds and 20.0 seconds respectively. The error stack originated in the CUA runtime's temporary kernel.js and worker-runtime.js files. User-specific filesystem paths are omitted.
No tab titles or URLs were obtained. The empty arrays are accompanied by an inventory failure and should not be interpreted as proof that no browsers or tabs were open. No tabs were opened, closed, navigated, or modified by these calls.
Expected behavior
The authorized read-only discovery request should enumerate available browsers and existing Edge tabs. If a prerequisite policy cannot be loaded, the error should identify an actionable cause rather than repeatedly suggesting a retry that returns the same result.
Scope and related reports
- Reproduced twice consecutively within one session. Persistence across app restarts, other machines, or other browsers has not been tested.
- The underlying cause is unknown; this report does not attribute it to Edge settings, authentication, a proxy, or a particular release.
- Computer use cannot be used with Microsoft Edge (crashes) #31007 reports a different Edge/Windows policy-enforcement error concerning URL detection.
- Windows desktop diagnostic bundle: renderer error flood, unauthenticated background requests, browser routing and stream-state failures #43437 reports Windows browser routing/authentication failures with different error messages and environment details.
These are related symptoms only, not confirmed duplicates or evidence of a shared root cause.
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
LogiQQ commentedon Sep 9, 2026
Follow-up: same failure after a reported restart
On 2026-09-09, the user reported restarting and requested another read-only check. The exact restart scope (Codex, Edge, or the entire OS) was not specified, so this is not claimed as a verified full reboot.
The subsequent
mcp__cua_repl.jscall:failed again after approximately 21.7 seconds with the same result:
{ "apps": [], "browsers": [], "errors": [ "Browsers: Error: Unable to load browser request-header policy. Retry the browser command." ] }This is the third observed failure in this conversation: two before the reported restart and one afterward. No browser tabs or settings were modified during the checks.
Related reports identified by the duplicate-detection bot
I reviewed #44140 and #44112. Both contain the exact same error text. #44140 is particularly close: Windows, Edge/Chrome failure, approximately 20–21 seconds before failure, and persistence after restarting Codex.
The Statsig initialization findings and successful in-app-browser comparison in #44140 are evidence from that reporter's machine, not independently verified findings on mine. I have not tested the in-app browser on this machine and cannot confirm a shared underlying cause or a working workaround.
Please consider these reports together during triage. This comment adds the post-restart reproduction evidence without claiming a confirmed root cause or fix.
qpwlkq commentedon Sep 11, 2026
I reproduced the same failure on macOS with Chrome, and traced it one layer deeper. This appears to be a cross-platform Browser Use policy-loading failure rather than an Edge/native-host problem.
Environment
mcp__cua_repl.jsReproduction
cua.getState()andcua.createBrowserTab("chrome", ...)repeatedly failed with:Resetting the CUA REPL session did not recover it. In the same app session, one earlier retry briefly succeeded, so the failure is capable of being transient, but subsequent calls failed repeatedly.
Native diagnostics all pass:
Root-cause evidence
The shipped Browser plugin's bundled
browser-service.mjsinitializes a Statsig client againsthttps://ab.chatgpt.com/v1and reads the gatecodex_browser_use_agent_request_headerbefore extension-backed session requests.The visible error is thrown when Statsig does not reach
Ready. A preserved tool result exposes the underlying error that gets wrapped:The relevant flow is:
readRequestHeaderEnabledcallback.There is also an asymmetry in
sendSessionRequest:getInfois exempt from the request-header gate, whilegetUserTabsis not, even though both are treated as discovery calls elsewhere in the same method. This explains why browser metadata may be available while tab discovery fails.gongzhang commentedon Sep 11, 2026
Same here. #44112 (comment)
GuraGeino commentedon Sep 12, 2026
I can reproduce this exact external-browser discovery failure on Windows in a later ChatGPT/Codex desktop release:
26.908.40834.On 2026-09-13, after restarting the desktop app and reopening Microsoft Edge, a read-only browser inventory still failed before any browser, tab title, URL, or page content could be obtained.
The returned state was:
{ "apps": [], "browsers": [], "errors": [ "Browsers: Error: Unable to load browser request-header policy. Retry the browser command." ] }A retry returned the same result. The external-browser integration had previously appeared enabled in the desktop app. The failure therefore occurs before normal external-browser discovery, rather than during target-site authentication or page interaction.
The empty browser list should not be interpreted as evidence that an external browser was not running; browser discovery itself failed.
I can provide sanitized timing and runtime details if they would help investigate the request-header-policy initialization path.
GuraGeino commentedon Sep 13, 2026
Additional evidence from the same Windows/Codex Desktop environment:
After the original Edge discovery failure, I tested Codex’s built-in browser path as well. Browser inventory still fails before any browser or tab is discovered, with the same error:
Unable to load browser request-header policy. Retry the browser command.This currently affects both external Edge control and Codex’s built-in
iabbrowser path.The Edge browser-family toggle had become disabled in the local Codex configuration. Re-enabling it did not change the failure.
The error occurs before any website is opened, tab is read, or browser interaction is attempted. This points to the shared browser-policy/runtime layer rather than the target site, Edge profile, or browser extension state.
Windows recorded a ChatGPT/Codex application hang on the same morning. This is only a timing correlation, not a claimed root cause.
zhaosh-eng commentedon Sep 21, 2026
Additional Windows / Edge reproduction — 2026-09-21
Submitted by Codex at the user's explicit request.
Verified environment
OpenAI.Codex 26.915.3509.0, verified withGet-AppxPackage.10.0.26200.0.26.915.31029.Observed behavior
cua.listBrowsers()successfully returned Edge metadata, butcua.listTabs(...),cua.getTab({url: ...}, {browser: ...}), andcua.getState()repeatedly failed before page content could be inspected:cua.getState()returned empty app/browser arrays together with the above discovery error; those arrays do not establish that Edge was closed.Recovery attempts and results
Diagnostic boundaries
Read-only inspection of the shipped browser service found that the policy error is raised when remote Statsig initialization is unsuccessful or the client is not Ready. This identifies the failing code path, not the underlying network/service cause.
A plain HEAD probe to
https://ab.chatgpt.com/v1/returned HTTP 403 both through curl's default route and an explicitly configured local system proxy. This was not the actual SDK initialization request, so it does not establish that the real initialization endpoint is blocked.No policy checks, certificate checks, or access controls were disabled or bypassed. Private target URLs, document contents, roster data, credentials, account identifiers, and raw session logs are omitted.
Impact / request
An authorized cloud-document workflow remains completely blocked before browser page inspection. Please investigate the persistent policy initialization failure and expose the underlying cause or an actionable recovery path instead of repeatedly suggesting a retry.
IT-EXPRESS-Bayern commentedon Oct 7, 2026
Additional reproduction on 7 October 2026, submitted at the user's request.
Verified local versions:
The Edge browser-extension path failed with:
Observed calls:
cua.getState()returned Edge browser metadata, an empty tab list and a browser-specific policy-loading error. The empty list does not establish that no tabs were open.cua.getBrowser({ id: returnedBrowserId })returned the Edge binding and documentation.browser.user.openTabs()failed with the same error.cua.createBrowserTab("edge", userProvidedUrl, { sessionName: "..." })failed with the same error.The requested new tab/window was not confirmed as opened. Retrying in a later turn did not resolve the issue. App/browser restarts and reinstallations were not performed during this reproduction.
The native Windows Computer Use path also failed before capturing the Edge window state, with the URL-confidence safety stop reported in #51524. Whether these two failures share a cause is unknown.
Please investigate policy initialization and provide a supported recovery path. No safety controls were disabled. Account data, target-page URLs, local usernames, session identifiers and full conversation logs are omitted.