[Windows] "Unable to load browser request-header policy": ~4.8 MB Statsig initialize payload appears to exceed the nodeRepl.fetch response limit

Summary

On Windows, every browser command through the Edge extension fails before any tab access with:

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

The extension, native-messaging host, and browser registration are all healthy, and codex doctor (run outside the sandbox) reports everything green. Directly fetching the same policy endpoint from the same machine returns HTTP 200 with a 4.2–4.8 MB body, which points at the privileged authenticated_fetch response limit on this path rather than at the user's network or at the extension.

This report adds the payload-size evidence that the related reports do not contain.

Environment

• Codex Desktop 26.908.9136 (Windows 11 build 26200, MSIX; "Powered by Codex & OWL")
• Bundled plugins: browser@openai-bundled 26.908.70816, chrome@openai-bundled 26.908.70816
• ChatGPT browser extension: odlomjlbamekndcpllcnffbgeohgkmjh v1.26.901.11451 (Microsoft Edge, enabled, Default profile)
• Failing gate: codex_browser_use_agent_request_header, checked in browser-service.mjs (_k()); enforced from the extension browser client's sendSessionRequest()

Steps to reproduce

1. Start a browser task that uses the installed Edge extension (an @Edge mention in the desktop app), or call cua.getState() / cua.listTabs() through cua_repl.
2. Every call fails after roughly 20 seconds with:

{"apps":[],"browsers":[],"errors":["Browsers: Error: Unable to load browser request-header policy. Retry the browser command."]}

3. Retrying, restarting the app, reinstalling the extension, re-materializing the plugin cache, and re-registering the native host all reproduce the failure. @Browser (the in-app browser) is unaffected.

Evidence that the user-side chain is healthy

• scripts/check-native-host-manifest.js --browser edge --json → correct: true (registry key, manifest file, allowed_origins all valid)
• extension-host.exe is launched by Edge through native messaging and listens on loopback
• The browser is registered with the browser service (extensionInstanceId is returned by cua.listBrowsers())
• codex doctor (outside the sandbox) → provider reachability OK, MCP OK, sandbox OK

Evidence pointing at the privileged fetch / payload size

Replaying the SDK's own initialize request from the bundled Node runtime on the same machine:

POST https://ab.chatgpt.com/v1/initialize?k=<browser-service client key>&st=js-mono&sv=3.33.1&t=…&sid=…
body: {"user":{"userID":"…"},"statsigMetadata":{"sdkType":"js-mono","sdkVersion":"3.33.1"},"sinceTime":0}

→ HTTP 200, 4,774,624 bytes
   dynamic_configs: 1128 entries → 4,532,289 bytes  (~95%)
   layer_configs:     162 entries →   133,352 bytes
   feature_gates:     398 entries →   107,727 bytes
   (the hashed name for `codex_browser_use_agent_request_header` is present; `is_delta:false`)

• The response is 4.15–4.8 MB across repeated calls (it tracks the server-side config set; the request body contains no tab, page, or browsing data — a synthetic userID was used for the measurement).
• Because the Statsig client starts cold (sinceTime: 0, no cached values), the SDK always asks for the full payload and the server never returns a delta.
• Small responses through the same privileged path succeed (e.g. https://chatgpt.com/backend-api/aura/identity), so authentication and the IPC bridge itself work; the difference between the working and the failing call is the response size.
• node_repl.exe contains the error string nodeRepl.fetch response is too large, and authenticated_fetch.rs exposes nodeRepl.fetch request failed / nodeRepl.fetch response read failed — consistent with a response-size limit on this path.
• Because browser-service.mjs caches the initialization state in the module-level Vr singleton, a single failed initialization makes _k() throw the fail-closed error for every later call in that process (this matches the behaviour described in #45366).

Expected behavior

Either the privileged fetch should be able to deliver the Statsig payload (or request a delta / use a compact endpoint), or a policy-initialization failure should degrade to "request-header capability disabled" instead of failing the whole extension browser client closed. The current message tells the user to retry, but a retry inside the same process cannot succeed.

Impact

Extension-based browser automation (Edge/Chrome) is completely unusable on the affected machine — no tab listing, no page reads — even though the extension and native-messaging host are healthy and @Browser still works.

Local mitigation in place (not a fix)

On the reporting machine the policy check was made fail-soft locally (an unavailable policy is treated as "request-header capability disabled"), which restores tab/page operations without granting any additional capability — the request-header feature stays off. This is only a local workaround; reporting here so the underlying fetch limit can be fixed properly.

Related reports

#44112, #44140, #44169, #44761, #44988, #45366, #45678, #45910, #45990

Start by tracing the policy initialization in browser-service.mjs, especially _k() and the module-level Vr state, then inspect authenticated_fetch.rs and the nodeRepl.fetch response-size handling. Reproduce the cold Statsig initialize request with its multi-megabyte response and verify the chosen fix. Done means the browser policy loads successfully or initialization fails soft without blocking extension browser operations.