[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

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.
Every call fails after roughly 20 seconds with:

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

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 Bug Report: Codex Desktop (Windows) Browser Use — Persistent Statsig Initialization Failure Within a Session #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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows: browser request-header policy failure persists after restarts; native fallback cannot verify URL #45910
Windows Work @Chrome fails to load browser request policy while @Browser works #45990
Bug Report: Codex Desktop (Windows) Browser Use — Persistent Statsig Initialization Failure Within a Session #45366
Chrome connection fails: Unable to load browser request-header policy #45678
macOS Chrome Computer Use fails to load browser request-header policy #44988

Powered by Codex Action

Local reproduction: large Statsig initialization response, proxy path, and two 10-second timeouts

I reproduced a closely related failure on Windows with Codex Desktop 26.915.4065.0 and CUA/browser runtime 26.915.31945. The symptoms are very close to the large Statsig initialize payload described here, but I think several layers should be separated.

My original local bridge workaround hard-coded an older Desktop/CUA directory. After Desktop updated, it no longer matched the active configuration, so cua_repl did not inherit the existing proxy variables. The initial error was:

nodeRepl.fetch request failed

I changed the workaround to discover the active CUA configuration and trusted service by capability rather than by version, and to inherit the existing HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY values. The error then changed to:

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

That transition was useful evidence: the proxy path was now working, but Statsig initialization still did not complete within the bundled browser service's deadline. A request to https://ab.chatgpt.com/v1/initialize through the same proxy returned HTTP 200 with a body of about 4.9 MB; on this network path the complete response took roughly 7–15 seconds. The current service has two separate 10-second limits: one around Statsig initialization and one for the network request. The log contained:

[Statsig] ... POST ... /v1/initialize ... Timeout of 10000ms expired.

For local diagnosis, I raised both limits to 30 seconds only after matching the expected browser-service capability shape, and kept a backup of the original source. After restarting:

cua.getState() returned no browser errors;
createBrowserTab("https://example.com") succeeded;
getAXState() returned the visible Example Domain content.

This verifies the CUA trusted browser service path; it is not, by itself, proof that every Edge/Chrome-extension-specific request-header path is covered.

My current assessment is that this is the same problem family as the large Statsig initialization/fetch failure reported here, but I cannot prove that this machine hit exactly the nodeRepl.fetch response-size limit described in this issue. There is also a concrete 10-second timeout problem. If the failed initialization state is then cached at module scope, the persistent failure behavior described in #45366 can be layered on top.

Possible upstream fixes:

Avoid independent, hard-coded 10-second deadlines at multiple layers; use a consistent and observable timeout policy.
Invalidate a failed Statsig client and retry with backoff instead of permanently reusing a failed module-level singleton.
Distinguish response-too-large, proxy/connectivity failure, request timeout, and cached initialization failure instead of mapping them all to “retry the browser command.”
If the request-header policy is unavailable, consider failing soft with that capability disabled, without granting it implicitly, so ordinary browser operations can continue.
Prefer a delta/cached or more compact policy/config response during cold start if possible.

The local workaround is only diagnostic: ensure the actual CUA process inherits the proxy variables, then make a capability-checked, reversible adjustment to the two Statsig 10-second windows in the current trusted browser service. It does not bypass policy evaluation; Statsig still has to initialize successfully and reach Ready. It is not an official fix and should be revalidated after upgrades; a hard-coded version path is not reliable.

Another Windows data point, in case it helps narrow this down.

Environment: Windows 11 (build 26200), Codex Desktop MSIX 26.917.9434 → updated to 26.924.1866 during the incident; bundled browser/chrome plugin 26.917.71314 → 26.924.20706; cua_node runtime Node v24.21.0; ChatGPT Chrome extension 1.26.901.11451 (Chrome, extension backend).

Symptom: same as above: Unable to load browser request-header policy. Retry the browser command. before any tab access, on cua.listTabs, cua.getTab, cua.getState, and cua.createBrowserTab.

What the local session logs show (browser calls classified by pattern, so rates are approximate):

Daily failure rate: 0 on Sep 15–18 → roughly 15–35% on Sep 19–23 → roughly 80% on Sep 24–25.
On Sep 26 (local time), every browser call failed for about 3 hours (05:05–07:57). That covered the original long-running task, a forked task, and a brand-new task started after updating to 26.924. Then the long-running task recovered on its own at 08:06 and has worked since.
Failed calls take ~14–29 s of wall time; successful calls ~1–6 s.

Things ruled out on this machine:

Account/identity: the error is the policy-load message, not Codex auth token is unavailable, and the same runtime flips fail → ok → fail within minutes.
Network: from the same machine, one credential-free HTTPS request to ab.chatgpt.com completes in ~0.27 s (DNS 34 ms, TCP 9 ms, TLS 71 ms, first byte 153 ms). DNS returns IPv4 only, and the bundled Node has autoSelectFamily=true, so there is no IPv6 stall.
App update: 26.917 → 26.924 did not change the relevant code (same gate check, same timeoutMs: 1e4 for Statsig initialize/updateUser, same default 10 s network timeout).

This fits the payload-size / authenticated_fetch explanation in this issue: the endpoint itself is fast, but the large initialize response through the privileged fetch path intermittently exceeds the 10 s windows. A longer or configurable timeout, failing soft when the policy can't be loaded, or a smaller/cached policy payload for cold starts would each help. Happy to test a build.

Follow-up / correction to my comment above:

The ~3-hour failure window I described overlaps a Codex service outage: it was acknowledged publicly at 22:58 UTC on Sep 25, and third-party monitoring shows roughly 22:44 UTC → 00:10 UTC. Our long-running task recovered at 00:06 UTC, right at the end of that window. So at least the last part of that stretch was probably the outage, not only the timeout.
Our continuous failures started earlier (21:05 UTC), and the intermittent failures on Sep 19–25 predate the outage, so the outage doesn't seem to explain everything.
My latency number (~0.27 s to ab.chatgpt.com) came from a credential-free request that got a 403 from the edge. It shows the host is reachable, not that the initialize path behind it was fast. Please don't read it as ruling out the server side.

Additional Windows/Chrome reproduction on 2026-09-28:

Windows 11 build 26340; ChatGPT/Codex desktop MSIX 26.924.2738.0; bundled browser runtime 26.924.22138; ChatGPT Chrome extension 1.26.901.11451 in the Default Chrome profile.
cua.getState() returns apps: [], browsers: [], and Browsers: Error: Unable to load browser request-header policy. Retry the browser command. An explicit cua.getTab(..., {browser: 'chrome'}) fails with the same error before the tab can be read. Repeated calls and a CUA JavaScript runtime reset did not change the result.
The current native-host registration points to existing browser client, browser service, and extension-host files. The Chrome extension is installed. codex doctor --summary reports provider endpoint reachability and WebSocket connectivity; I am not claiming that all doctor checks pass.
The in-app browser can open and read public HTTPS pages in the same desktop session. The failure is specific to external Chrome control.

This persists on 26.924 and blocks browser tab discovery. Please expose the underlying policy-initialization error and fix the external-browser path. No policy bypass or security-setting changes were attempted.

Windows / Edge: Brotli transport workaround verified with a patched-stock-patched comparison

Adding a Windows/Edge validation of the approach in #44988 (comment). This is a local workaround, not an official fix or proof that every instance of this error has the same cause.

Environment

Windows; Codex desktop version 26.928.31416, build 12553; MSIX package version 26.928.3736.0.
Microsoft Edge, extension backend; extension version 1.26.901.11451_0, installed and enabled.
Bundled native-host diagnostic returned correct: true.
The actual CUA trusted service resolved to @oai/browser-desktop/service in the bundled cua_node runtime, not the older browser-plugin cache copy.

Failure
External Edge control failed before page access with:

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

The in-app browser worked, but was not treated as evidence that Edge was repaired. Increasing the initialization timeout to 30 seconds did not help. Increasing initialization to 45 seconds and the network timeout to 30 seconds also did not help; both changes were reverted.

Narrow workaround
Only the Statsig networkOverrideFunc for https://ab.chatgpt.com/v1/initialize was wrapped:

Request Accept-Encoding: br, still calling the original bound transport fetch and preserving the original identity, method, body, signal and other request options.
Leave HTTP errors and unknown content encodings unchanged.
Check whether the returned bytes already contain valid JSON. Otherwise decode Brotli, including the case where encoding metadata is absent, then validate strict UTF-8 and JSON.
Bound decompression to 16 MiB and remove stale content-encoding/content-length headers after decoding. Transport, decompression and parsing errors still propagate.
Retain the original 10-second limits, successful-initialization/Ready requirements and recognized policy-gate checks. No policy was fabricated, forced off or made fail-open.

Controlled validation, with the network configuration unchanged

Service / operation	Observed result
Patched service, fresh CUA kernel, open example.com in external Edge	Success; title and page body returned in 6.10 s
Click Learn more	Navigated to the IANA Example Domains page; body read successfully
Back	Returned to example.com successfully
Restore stock service, verify original SHA-256, reset CUA kernel, repeat opening	Same policy-loading error after 20.54 s
Reapply the narrow patch, reset CUA kernel, repeat opening	Success again; title and page body returned in 9.84 s

Times above are complete tool-call wall times, not isolated HTTP request timings. An Edge page screenshot was also obtained successfully. Eleven local tests passed, covering compressed responses with/without encoding metadata, already-decoded JSON, unrelated URLs, HTTP/transport failures, malformed data, non-JSON output, decompression size limits and preservation of original request options.

This comparison supports the initialization response transport/decoding path as an actionable failure point on this installation. It does not establish an exact internal response-size limit, exclude every network/server contribution, or independently prove which layer mishandles encoding metadata.

No proxy/VPN settings, firewall rules, browser profile, cookies or login state were changed during this comparison. The runtime edit was backed up and remains reversible; an app update may replace it. Do not overwrite a newer runtime with an old bundle.

Upstream request: please support compressed initialization responses end-to-end through the existing authenticated transport, preserve fail-closed policy checks, and expose the underlying transfer/decode/timeout error instead of only the generic retry message.

No credentials, account identifiers, private browsing data, local usernames/paths, IP addresses or raw session logs are included.

Additional offline findings for the request-header policy failure on Windows. The currently inspected installation is Codex Desktop 26.930.21537 (build 12776); this does not establish which build was running when the original incident began.

I extracted the installed browser-service readiness functions, relevant Statsig SDK methods, and privileged-fetch bridge into a deterministic harness. Storage, network, and IPC were replaced with local fixtures. No live requests or installed-file modifications were made.

A resolved Statsig result with success: false is still marked initialized. Repeated initialization/policy reads reuse the failed promise, even after the simulated transport becomes healthy. A late successful response does not change that settled result.
The normal same-user update path can recover by replacing readiness with a new updateUserAsync promise. The service has a metadata return path before that normal user-update hook. This supports a failure-persistence mechanism, not a claim that every command is permanently stuck.
Overlapping initialization and user update succeeds when the latest update succeeds. The race alone did not reproduce the failure.
After privileged fetch dispatch, aborting its signal leaves the promise pending; a late synthetic IPC response is accepted.

An isolated guard prototype preserves the existing 10-second timeout, shares one ordinary SDK recovery update among concurrent policy readers, preserves failure causes, and keeps recognized gate values and unrecognized-gate rejection unchanged. Rejected initialization remains fail-closed; only resolved unsuccessful results are recovered. All 16 original-behavior/prototype checks passed.

These tests establish persistence and diagnostic-loss mechanisms. They do not establish the original live transport failure or a response-size limit on this machine. Capturing SDK update details, response byte counts, and correlated privileged IPC outcomes would distinguish those causes. The prototype has not been integrated into the installed runtime.

Windows Chrome / Edge: update-safe handling of the Brotli workaround (official build first)

Following up on the Brotli transport workaround above, with an update regression and a way to avoid automatically applying an obsolete patch after an official fix.

What happened on this installation

After upgrading to Windows MSIX package 26.930.3748.0, Chrome and Edge again reported Unable to load browser request-header policy. The update replaced the CUA runtime directory and restored the unmodified browser-service.mjs. Its SHA-256 was identical to the previously backed-up original:

64b3e6758957d209c58755c9d198237021124f14060b14edb4f9b74288851667

After independently backing up the new runtime's original file, the same narrow Brotli wrapper was reapplied. Two test rounds, each starting with a fresh CUA kernel, passed in both external browsers: four opens/page reads total, plus click/back checks in the first round and screenshots in the second. These were Chrome/Edge extension tests, not a substitution with the in-app browser.

The wrapper only handles POST requests to https://ab.chatgpt.com/v1/initialize through the existing authenticated fetch. It requests Brotli, accepts already-decoded JSON, otherwise performs bounded Brotli decoding with strict UTF-8/JSON validation. Authentication, request identity/options, timeouts, recognized policy checks and rejection on initialization failure remain intact. It does not fabricate policy data or disable the policy check.

Why checking only the browser-service hash is insufficient

An official fix could land in the desktop app or native/privileged transport while leaving browser-service.mjs unchanged. An update watcher that blindly reapplies a matching old patch could then keep an unnecessary workaround indefinitely.

I implemented a local PowerShell launcher with a stricter, original-first rule:

Compute a complete build fingerprint: desktop package identity and relevant desktop files, backend executable paths/hashes, CUA runtime identity/manifest/Node binaries/browser client, and the browser-service source hash. Normalize only the exact verified original/patched pair to the same base-service identity. Any other source hash remains distinct.
Every changed fingerprint starts without patch approval, even if the service file alone is unchanged. First use the official original and actually test Chrome/Edge. If they work, leave the original in place.
If a changed build retains the exact known patched file, restore its verified original before the stock trial. Unknown source is never overwritten; unknown source still containing the local patch marker stops for inspection.
Enabling the workaround requires a recorded launch request for the original build and the user reproducing/pasting the exact policy-loading error for that same fingerprint. This is explicit failure reporting, not an automatic browser-health test. Source compatibility is checked separately; an unknown source cannot be approved by merely acknowledging the error.
Only an already-confirmed failing build can automatically recover its approved patch if those exact original bytes reappear. The launcher's restore/disable action restores the original and revokes that build's approval.

The core decision flow is:

new build + known original       -> launch original; require real browser test
new build + exact known patch    -> restore verified original; test original
known failing build + original  -> back up; apply its verified patch
known failing build + patch     -> leave unchanged
unknown source                  -> never apply the old patch
unknown source + patch marker   -> stop for review
ambiguous runtime/identity      -> stop rather than guess
runtime not materialized yet   -> launch without repair; check again later

Implementation safeguards

Keep separate original backups per runtime, outside the updater-managed runtime directory, and verify hashes before use.
Refuse modifications while the desktop app or relevant tool processes are running; do not terminate user work.
Recheck the complete fingerprint and target hash immediately before a same-directory atomic replacement. Apply the approval gate in the low-level repair command too, so it cannot be bypassed through a legacy entry point.
On Windows PowerShell, use ordinal sorting for canonical fingerprint lines: Sort-Object produced different ordering between PowerShell 5.1 and 7 despite identical inputs. Use explicit UTF-8 for JSON, and UTF-8 BOM for scripts containing non-ASCII text when supporting 5.1. For the .NET File.Replace overload used here, [NullString]::Value avoids the empty-path binding problem encountered with $null.
Use an explicit check-and-launch shortcut, with a separate restore/disable action. No background watcher, update blocking, or change to normal browser profiles/network settings. The ordinary shortcut and updater's automatic launch do not run this guard.

Validation and limits

18 offline transport tests and 25 isolated launcher/guard tests passed. The guard tests included changed desktop/backend bytes with unchanged service source, approval invalidation, stock restoration, unknown-source rejection, exact-error approval, backups, atomic apply/restore, running-process refusal, and UTF-8 state round-tripping. Cross-PowerShell fingerprint consistency and the real running-process refusal were also checked.

The isolated guard tests did not launch the real desktop app, and a complete desktop restart after installing this launcher has not yet been tested. The browser passes above validate the reapplied transport workaround, not the launcher's full restart path or long-term reliability. An earlier stock rollback also temporarily worked on this installation, so this does not prove a unique root cause or exclude intermittent server/network contributions. A hash cannot detect a server-side fix; the restore/disable action remains useful even without a local build change.

This remains a reversible local workaround. The preferred outcome is an upstream transport fix, retaining rejection when policy initialization fails and providing the underlying transfer/decode/timeout cause. Once a new official build works unmodified, it should stay unmodified.

Follow-up: request-header policy failure recurs on Windows MSIX 26.930.3930.0

The same policy-loading failure recurred on 2026-10-04 during a Chrome-extension-backed browser workflow. The initial cua.getState() call and one ordinary reacquisition both failed with Unable to load browser request-header policy. Retry the browser command. The workflow stopped before owner-page verification or any new page action.

Read-only environment verification:

Installed Windows MSIX: 26.930.3930.0.
Inspected @oai/browser-desktop package: 0.1.1.
Browser service SHA-256: 64b3e6758957d209c58755c9d198237021124f14060b14edb4f9b74288851667, byte-identical to the service examined in my earlier comment #5955162116.
Chrome extension: 1.26.901.11451; background script SHA-256: 83b7b7708ab82ecc9aa2ccad20a2167941a706b38a9467dee0bb124d13f0033e.

The inspected code still collapses unsuccessful readiness into the generic policy error. A failed initialization can be retained on paths that skip the normal same-user update. The ordinary same-user update can recover, so this is a conditional failure-retention mechanism rather than proof that all browser calls permanently fail. Our earlier deterministic extraction tests establish that mechanism; this follow-up verifies the identical inspected service and a new real failure.

The initial fetch status, response byte count, SDK error, elapsed time and privileged IPC completion are absent from the saved call observation. Consequently, we cannot establish whether this recurrence was triggered by an oversized response, network failure, IPC failure or another initialization error. The payload-size findings in this issue have not been verified on this installation.

A bounded desktop-log review found network-change/disconnection/DNS errors at 06:40–06:49 UTC. The later failed workflow ran around 07:26–07:30 UTC; the retained excerpts contain no matching network errors in that later window and no request correlation tying the earlier burst to policy initialization.

Could the policy-loading error preserve the underlying readiness failure class and report sanitized status/bytes/duration/IPC outcome? That would distinguish the initial trigger from retained failure state. Installed runtime files were unchanged during this investigation; no private endpoint requests were made.

Windows Chrome policy initialization failure, Codex 26.1007.21434 build 13901

Authenticated Chrome discovery succeeds. nameSession and user.openTabs fail after about 20 seconds with: Unable to load browser request-header policy. Retry the browser command.

Reproduces after Chrome restart, Codex restart, extension reinstall, and a fresh chat. Browser native-host and extension diagnostics previously passed. No Chrome profile, cookie, or login changes were made.

A synthetic, credential-free initialization request to https://ab.chatgpt.com/v1/initialize using the public browser-service SDK client key returned HTTP 200, 5,520,907 bytes in 5.47 seconds. This was a separate diagnostic request, not the failing runtime request. It suggests the large-response failure reported in #46129, but does not prove a size-limit exception here.

The active @oai/browser-desktop/service creates its Statsig client with networkOverrideFunc calling the runtime fetch. That runtime is built from the privileged nodeRepl bridge. The bundled node_repl binary contains the response-is-too-large error string. The service uses 10-second initialization/readiness deadlines. The visible error omits the underlying fetch status, response size, and failure reason.

Current desktop log also records post-login Statsig bootstrap timeouts and a networking error on an initialization POST. These are renderer logs and should not be mistaken for the exact browser-service response.

Please expose the underlying authenticated_fetch failure and provide a supported repair for initialization with large payloads. Policy enforcement should remain intact. We have not patched policy results, bypassed checks, or disabled protections.

Navigation Menu

Repository navigation

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

Summary

Environment

Steps to reproduce

Evidence that the user-side chain is healthy

Evidence pointing at the privileged fetch / payload size

Expected behavior

Impact

Local mitigation in place (not a fix)

Related reports

Windows / Edge: Brotli transport workaround verified with a patched-stock-patched comparison

Windows Chrome / Edge: update-safe handling of the Brotli workaround (official build first)

Follow-up: request-header policy failure recurs on Windows MSIX 26.930.3930.0

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Steps to reproduce

Evidence that the user-side chain is healthy

Evidence pointing at the privileged fetch / payload size

Expected behavior

Impact

Local mitigation in place (not a fix)

Related reports

Activity

github-actions commented on Sep 17, 2026

knightli commented on Sep 21, 2026

b0807249 commented on Sep 26, 2026

b0807249 commented on Sep 26, 2026

kirrrto commented on Sep 28, 2026

kang-yuhang commented on Oct 1, 2026

Windows / Edge: Brotli transport workaround verified with a patched-stock-patched comparison

masashinew-byte commented on Oct 2, 2026

minyewu commented on Oct 3, 2026

Windows Chrome / Edge: update-safe handling of the Brotli workaround (official build first)

masashinew-byte commented on Oct 4, 2026

Follow-up: request-header policy failure recurs on Windows MSIX 26.930.3930.0

kingsleyonoh commented on Oct 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions