Repository navigation
[Windows] Chrome/CUA proxy regression still reproduces after updates (26.924.6891.0) #49548
Description
What version of the Codex App are you using?
Windows package OpenAI.Codex 26.924.6891.0 (desktop application displayed as ChatGPT).
What subscription do you have?
ChatGPT subscription; exact tier omitted. The impact described below concerns agent usage limits and repeated troubleshooting time.
What platform is your computer?
Windows 11 x64, build 26200. Local HTTP(S) proxy supplied by Hiddify.
What issue are you seeing?
Chrome control has broken again after an application update in my proxy-required Windows setup. This is a fresh reproduction on September 30, 2026.
I am aware of the related reports, especially #42454. My earlier Windows report, #46386, was closed after identifying the overlap. I am opening this follow-up with the current build and new reproduction evidence because the problem continues to recur on my machine; I have been troubleshooting it since at least September 12.
The update installed a new versioned CUA runtime without the local proxy workaround that had restored browser control in the previous runtime. The generated MCP configuration still neither sets nor forwards the proxy variables needed by that workaround.
The official browser tool fails even on:
await cua.getState();Observed result:
apps: []
browsers: []
Browsers: Error: Unexpected token '<', "<html> ... is not valid JSON
Evidence from the September 30 reproduction
| Component | Previous checked version | Current version |
|---|---|---|
| Windows application package | 26.924.2738.0 | 26.924.6891.0 |
| bundled unified-computer-use plugin | 26.924.22138 | 26.924.51851 |
| CUA runtime directory ID | b63ee7ee40c23b77 | 98614bf36dff477b |
- The current bundled Node version is
v24.21.0. - Before repair, the new
cua-repl.mjswas the original unpatched launcher, SHA-256992174a5e637645aeb444adfdb1bae688e997bb84d7db07532f68e358e60f278. - The active generated
cua_replconfiguration'senv_varscontained onlyCODEX_WINDOWS_REGISTERED_CORE. Itsenvcontained no proxy entries. - An HTTPS request through the existing local proxy succeeded and returned the expected exit IP. The proxy itself was available during diagnosis.
- Chrome control had passed a real page-open, page-read and link-navigation test on September 27 with the previous repaired runtime.
What steps can reproduce the bug?
- Use the desktop application on Windows where its service requests require a local HTTP(S) proxy.
- Establish working Chrome control with explicit proxy settings supplied to the bundled CUA launcher.
- Update the desktop application so it installs a new versioned CUA runtime.
- Start the application and call the official browser tool, for example
await cua.getState();. - Observe the HTML/JSON initialization error, and inspect the new generated launcher/configuration: the previous proxy workaround is absent.
Temporary workaround and verification limits
For earlier occurrences, supplying NODE_USE_ENV_PROXY=1, HTTP_PROXY, HTTPS_PROXY, their lowercase equivalents, and localhost exclusions before the original CUA launch, followed by a full application restart, restored browser control.
For this occurrence, the same narrowly scoped repair has been reapplied with an original-file backup. Syntax, proxy-before-launch behavior and preservation of unrelated/trust environment settings passed local checks. A second check recognizes the repair as already present. The September 30 live browser retest is still pending a user-managed application restart; I am not claiming it has already passed on this build.
No browser profile, identity check, trust filter, generated MCP manifest or VPN setting was changed. The precise authenticated HTTP response behind the JSON error was not captured, so that part of the underlying failure remains an inference rather than a network trace.
What is the expected behavior?
Proxy-dependent browser control should continue to work across updates without manually editing versioned internal files. A supported, persistent proxy setting or environment override layer could be merged into each newly generated CUA configuration. It would also help to reinitialize affected browser sessions when connectivity returns and show an actionable connection error instead of a raw JSON parse failure. These changes should preserve the existing identity and security checks.
User impact
It has been a little frustrating to keep revisiting this after updates. Each troubleshooting session uses part of my ChatGPT usage allowance and, more importantly to me, takes personal time away from the work I opened the application to do. I would appreciate a durable fix, or an update on where this issue is being tracked and whether a supported solution is planned. I understand that related reports already exist; my intention is to provide current evidence that the problem is still affecting everyday use.
Activity
Frie666 commentedon Oct 1, 2026
Follow-up with a different failure mode observed on October 1, 2026. This may be related, but I cannot establish that the pending update caused it.
Environment and state:
26.928.2636.0; running app reports version26.928.21956, build12404.26.928.21956.restart_required.The first Chrome command failed after approximately 41 seconds with:
The same tool result included a Statsig initialization request timeout to
https://ab.chatgpt.com/v1/initialize(10 seconds). In the installedbrowser-service.mjs, the request-header policy reader waits for Statsig initialization/readiness and throws this exact error when initialization is unsuccessful or the client is not Ready. The gate involved iscodex_browser_use_agent_request_header.This identifies the immediate failure point: startup could not obtain the remote policy configuration required for browser control. It does not establish why that network request timed out or whether the pending update contributed.
Recovery in this diagnostic session:
js_reset.https://www.iana.org/help/example-domains, read its content, follow the Reserved Domains link, and read the destination page.No application restart, Windows reboot, update installation, proxy change, or launcher edit was required for that recovery. The main app process remained unchanged. A transient network recovery could also have contributed; this is not proof that session reset alone fixed the underlying cause.
In addition to preserving supported proxy configuration across updates, could browser initialization recover automatically from this kind of temporary policy-fetch failure, using bounded retries and a fresh initialization attempt? Please retain the policy checks and fail closed when policy is unavailable, but distinguish this condition from a missing Chrome connection and offer a clear retry/reset action that does not require restarting the whole app.
These recurring interruptions continue to consume troubleshooting time and ChatGPT usage limits. I understand related reports already exist; I am adding the observations here because a reliable recovery path would make a significant difference in daily use.
Frie666 commentedon Oct 1, 2026
An additional check in the affected conversation exposed a separate error:
failed to write kernel assets, followed by Windows reporting that the specified path could not be found. That conversation still failed after its owncua_repl.js_reset, while the diagnostic conversation on the same running app could operate Chrome successfully.Therefore, the successful policy-timeout recovery described above was specific to the diagnostic conversation; it did not restore the affected conversation. There appear to be at least two distinct failure points, and neither should simply be presented to the user as Chrome being disconnected.
Next step is the pending app update and a full restart. I have not yet verified recovery after that step. It would help if the app could validate and recreate missing per-session kernel asset paths through its supported initialization flow, and provide a targeted recovery action rather than requiring users to restart unrelated work.
Post-reboot update: Windows restarted on October 1, and the installed package changed from
26.928.2636.0to26.928.3736.0. A new versioned CUA runtime was installed with the original, unmodified launcher (SHA-256992174a5e637645aeb444adfdb1bae688e997bb84d7db07532f68e358e60f278). The previous scoped proxy workaround was absent from that new runtime, while the configured proxy itself remained reachable.The affected conversation's reported failure changed from missing kernel assets to
Unexpected token '<', "<html>..." is not valid JSON. Restoring the same narrowly scoped launcher proxy setup succeeded with a backup of the original. However, the already-running CUA server processes predate that repair, and a JavaScript-session reset still reproduces the HTML/JSON error. Browser recovery after loading the repaired launcher in a new server process is not yet verified. No security-policy checks were disabled.This separates the observations: before restarting, there was a policy-initialization timeout and a conversation-specific missing-path error; after the package update, the previously reported loss of the launcher proxy workaround recurred in the newly installed runtime.
Later recovery result: after another user-initiated reboot, new CUA processes had loaded the proxy workaround, but repeated policy initialization attempts still timed out. Unauthenticated network probes through the same proxy showed variable latency, including one TLS handshake taking about 16 seconds; other requests completed in 1-3 seconds. These probes are only reachability evidence, not authenticated policy-fetch tests.
For a local, version-specific experiment, I increased Statsig's
networkConfig.networkTimeoutMsand the browser service's initialization/readiness deadline from 10 to 30 seconds. Identity checks, successful-initialization checks, Ready status, recognized-gate checks and fail-closed behavior were retained unchanged. After resetting only the CUA session, a real Chrome tab opened successfully and page reading/link navigation passed. The previously affected conversation also reached its intended site's login page and could continue. No further app/Windows restart was needed for this change.This suggests the fixed short startup deadline is worth investigating alongside proxy inheritance and per-session asset recovery. It is not a controlled proof of the underlying network cause, and network variability may also have contributed. A supported bounded retry/reinitialization path and actionable diagnostics would be preferable to modifying bundled files.