Repository navigation
Windows Codex App: Chrome automation receives HTML instead of JSON; durable WebSocket reconnects return 403 #50412
Description
What version of the Codex App are you using?
26.930.2377.0 (installed Windows package version; About dialog not independently captured).
Bundled Chrome plugin: 26.930.21537.
Official ChatGPT Chrome extension: 1.26.901.11451, ID hehggadaopoacecdllhhajmbjkdcmajg.
What subscription do you have?
Pro.
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64.
What issue are you seeing?
Chrome automation fails before returning tabs or opening a page:
Unexpected token '<', "\n <"... is not valid JSON
Concurrently, desktop logs show repeated AppServerConnection WebSocket failures approximately every 20 seconds:
2026-10-02T19:00:45.404Z websocket_error: Unexpected server response: 403
2026-10-02T19:01:05.615Z websocket_error: Unexpected server response: 403
2026-10-02T19:01:25.808Z websocket_error: Unexpected server response: 403
The connections are identified as hostId=durable, transport=websocket; closure code1006 follows.
Read-only inspection of the installed desktop code links durableThreadHostConfig to wss://codex-cloud-backend.chatgpt.com/.
What steps can reproduce the bug?
- Use the Windows desktop app with the official ChatGPT Chrome extension enabled.
- Request the Chrome tab inventory or ask Codex to open https://example.com/ in Chrome.
- Observe the HTML-as-JSON parsing error.
- Inspect desktop logs for the accompanying durable WebSocket reconnect failures.
The environment has a Windows system proxy at127.0.0.1:10809, listening process xray. TCP snapshots show Codex/ChatGPT processes connecting to this proxy. The individual durable socket was not uniquely identified.
What is the expected behavior?
Chrome inventory/navigation should succeed, or return an actionable transport/authentication error rather than attempting to parse an HTML response as JSON.
Additional information
Unauthenticated HEAD probes to https://codex-cloud-backend.chatgpt.com/ on2026-10-02:
- Direct,19:25:07UTC: HTTP403; Content-Type:text/html;charset=UTF-8; Server:cloudflare; CF-RAY:a446175b5d449780-ARN. No cf-mitigated header was present in the selected response headers.
- Through the existing proxy,19:25:07UTC: CONNECT200, then HTTP403; same Content-Type; Server:cloudflare; cf-mitigated:challenge; CF-RAY:a446175dba5bbc19-VNO.
Both curl processes exited0 with TLS verification enabled. curl8.21.0/Schannel does not advertise HTTP/2 support in this installation.
The owner opened the same HTTPS address manually in Chrome with proxy settings unchanged and reported:
{"error":{"code":-32002,"message":"identity-edge rejected app-server-backend request authentication"}}
This is an owner-reported response, not a captured browser network trace.
Separate IAB logs show route capture/startup_ready, then successful and failed getInfo calls sharing one turnId, including "No ChatGPT browser route is available". These IAB events are not proven to cause the Chrome error.
Native-host registration/path are valid; latest resolves to Chrome plugin26.930.21537. extension-host.exe --help exits0 with no output; this does not verify its messaging handshake.
Limits: actual durable handshake response headers/body and Ray ID were not captured. The browser, HEAD and WebSocket requests differ in method/authentication. No User-Agent comparison, TLS fingerprint measurement, proxy-disabled desktop restart or authenticated WebSocket probe was performed. Cloudflare client classification, authentication and proxy/upstream effects remain hypotheses. The durable403 and ChromeJSON failure are temporally correlated, not causally linked.
Please help identify which request returns HTML to Chrome automation and whether the durable403 originates from edge mitigation or identity/authentication rejection, and provide a supported way to capture sanitized handshake status/headers without exposing tokens or cookies.
Related context, not a confirmed duplicate:
#21735
No credentials, cookies, private conversation content or full logs are included.
Activity
github-actions commentedon Oct 2, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
nersesmamulyam-pixel commentedon Oct 2, 2026
Regarding the suggested duplicate #49548: that report describes a CUA launcher proxy-environment regression after updates, with successful browser-control verification on an earlier repaired runtime and a restart/live retest still pending for its September 30 build.
This report adds concurrent AppServerConnection/hostId=durable WebSocket 403 failures and separate unauthenticated HEAD response headers. Importantly, cf-mitigated: challenge was observed only in the HEAD probe through the proxy; actual durable WebSocket response headers were not captured. TCP snapshots also do not establish the proxy configuration or route of the specific CUA process/request that returned HTML.
We therefore cannot yet confirm either a shared cause or a different mechanism. The CUA proxy-environment regression remains a relevant possibility; the relationship between the durable failures and the Chrome JSON parsing error is unproven. Please compare the affected request/process before treating this as a confirmed duplicate.
tomhda commentedon Oct 5, 2026
Same durable 403 loop here, starting right after the server closed the connection.
Earlier the same day the durable connection dropped 7 times (code 1006) and reconnected within 1–2 seconds each time. The last drop did not recover:
There were two bursts of renderer-requested reconnects (
cause=reconnect_requested: 34 within about 7 seconds at 15:42Z, 10 at 15:51Z). I believe these came from pressing Reconnect and retrying sends. They happened after the first 403, so they did not cause it.What I checked:
https://codex-cloud-backend.chatgpt.com/from the same machine at 16:01Z returnedHTTP 403,Server: cloudflare,Cf-Mitigated: challenge, and an HTML challenge page. I could not capture the response body the desktop app received. It is the same host and status, so the app appears to be receiving a Cloudflare challenge that it cannot answer.What the app does with it: it logs
Unexpected server response: 403, shows that string in the sidebar tooltip, and retries the same connection every 20 seconds. It does not say that the connection was blocked by a challenge. It does not offer a way to pass the challenge or to re-authenticate, and it never stops retrying.While the durable host is disconnected, cloud chats are greyed out in the sidebar and cannot be opened. Opening the chat through the link shown by Dot worked for a while, then stopped working too. Reloading the window does not help.
Expected:
viniciusfoscaches commentedon Oct 5, 2026
Additional Windows observation on October 5, 2026, scoped to the durable WebSocket 403 loop reported here. Chrome automation was not tested in this investigation.
Verified post-update environment
Diagnostic results
Read-only checks completed at approximately 17:06 UTC:
hostId=local.The successful local stdio handshake and failed durable connection are separate observations. We have not established the full request path causing the native local-tool calls to fail, nor whether the 403 comes from authentication, an edge challenge, or another service decision. No actual handshake response headers/body were captured, so this report does not identify Cloudflare or a proxy as the cause.
An earlier connection-refused/socket error was traced to a historical optional-daemon entry dated September 16; it is not evidence that the current stdio app-server is unavailable.
This follows an earlier existing-local-thread routing report. A causal connection between this 403 loop and that placement-region-15 rejection has not been established. The update likewise does not establish that the update caused this failure.
Please provide a supported recovery or narrowly scoped diagnostic that distinguishes a refused durable handshake from local app-server startup failure. An actionable explanation in the UI would also help avoid unnecessary restarts or resets.
No authentication/security settings, credentials, or session stores were changed during these post-update checks. No additional restart was attempted as a repair. Private identifiers, local paths, project contents, credentials, and raw logs are omitted.
jzwtarot98 commentedon Oct 5, 2026
Additional Windows report of durable WebSocket HTTP 403
Summary
On Codex desktop for Windows, my cloud tasks that use the
durable/Long-livedhost have been unavailable since approximately 2026-10-05 15:47 UTC. The desktop log repeatedly recordsUnexpected server response: 403while opening its WebSocket connection. Local sessions still work.An independent WebSocket-upgrade probe to
wss://codex-cloud-backend.chatgpt.com/through the same proxy route receivedHTTP/1.1 403 ForbiddenwithCf-Mitigated: challenge. This directly establishes the Cloudflare challenge on the probe. The desktop log records the 403 status but does not include response headers, so I cannot confirm from the log alone that its response was the same challenge.Timeline from the desktop log excerpts
next=connectedfordurable.1006. This is a closure event, not a new successful connection.app_server_connection.websocket_errorfordurablewithUnexpected server response: 403.websocket_errorlines reporting 403 and no furthernext=connectedtransition. The much larger count of 4,647 lines mentioning 403 includes repeated state notifications and should not be interpreted as 4,647 separate connection attempts.The exact time or cause of any server-side change is unknown. The 15:41–15:47 UTC interval is the interval between the last established connection closing and the first observed 403, not proof of when a mitigation rule changed.
Network observations
codex-cloud-backend.chatgpt.com/, without an account token, returned403withCf-Mitigated: challengeand a Cloudflare HTML challenge page.403andCf-Mitigated: challenge. These records do not establish that every route was tested with a WebSocket upgrade or verify 18 distinct public egress IP addresses; the separate WebSocket-upgrade probe above confirms that handshake case for one tested route.chatgpt.com/backend-api/codex/responsesreturned405without a challenge, andws.chatgpt.com/returned404without a challenge.chatgpt.com/itself also returned a challenge, so the observation is path-dependent and does not rule out egress reputation as a contributing factor.Routing comparison added on 2026-10-05 17:19–17:23 UTC
I also compared two ways to route the desktop traffic through my local proxy: the usual WinDivert-based proxifier and, during a short test interval, TUN routing with that proxifier stopped. The proxy log attributed connections to
codex-cloud-backend.chatgpt.com:443toProxyBridge_CLI.exebefore the switch and toChatGPT.exein the TUN test interval. At corresponding times, the desktop continued loggingdurableWebSocket 403 errors. Both modes used the same selected upstream route.This makes a failure confined to the proxifier handoff less likely. It does not rule out the shared proxy/egress path, other client behavior, or server-side causes. The proxy log shows process attribution and destination, while the desktop log supplies the 403; it does not capture the HTTP response headers for the desktop request.
Environment and impact
10.0.26300OpenAI.Codexversion26.930.4958.0durable, display nameLong-lived, WebSocket endpointwss://codex-cloud-backend.chatgpt.com/(endpoint identified in the supplied desktop-bundle excerpt)Unexpected server response: 403; opening a cloud task fails to restore its conversation. Local sessions remain usable.Request
Could you check whether a Cloudflare mitigation or risk policy affecting
codex-cloud-backend.chatgpt.comchanged around 2026-10-05 15:41–15:47 UTC, and whether it can challenge the shipped desktop client's WebSocket handshake? If this behavior is intended, please advise on a supported way for the desktop client to complete the handshake or provide another supported transport. Please also let me know whether there is a client-side recovery step I can take.A sanitized evidence appendix with selected timestamps, response headers, and log excerpts is included below. Account, installation, server, and environment identifiers are omitted from this public report.
Sanitized evidence appendix
Evidence appendix for durable WebSocket 403
This appendix contains selected, sanitized observations from a user-supplied diagnostic package. The statements about the desktop are based on its extracted logs; the network headers are from a separate probe through the user's proxy route. No current independent live reproduction was performed while preparing this appendix.
Desktop log excerpts
The package contains 171 lines selected by a broad connected-state filter. They are not 171 separate successful connections. Of these, 22 lines show an
AppServerConnectiontransition tonext=connected; the latest is:The later 15:41:12 event is the closure of an already-established connection:
The first recorded 403 is:
The extracted logs through 2026-10-05 17:23:46 UTC contain 296
app_server_connection.websocket_errorlines reporting 403. They also contain 4,647 total lines with the exact 403 message because connection errors are propagated into several state-change and UI notifications. The excerpt has no laternext=connectedtransition. These are counts within the supplied excerpt, not a full re-scan of the user's retained desktop logs.Independent probe response
An unauthenticated WebSocket upgrade to
wss://codex-cloud-backend.chatgpt.com/returned:The probe records a Cloudflare HTML challenge page. A GET request, a WebSocket-upgrade request with an intentionally invalid bearer token, and a browser-like User-Agent also received 403 with
Cf-Mitigated: challenge. The invalid-token comparison is not evidence about a valid desktop token or the backend authentication order.Route selections and controls
The six recorded regional selections (US, JP, HK, SG, TW, Edge) each returned
403andCf-Mitigated: challenge. Twelve further sequential node selections each returned the same. The route-sweep logs do not record the HTTP request line or public egress IPs; they cannot establish WebSocket-upgrade failure on all 18 routes or prove 18 distinct egress IPs. The separatews-noauthrecord above demonstrates the WebSocket-upgrade case for one tested route.Plain GET control requests from the compared route returned:
chatgpt.com/backend-api/codex/responses405 Method Not Allowed; no challenge headerws.chatgpt.com/404 Not Found; no challenge headerchatgpt.com/403;Cf-Mitigated: challengecodex-cloud-backend.chatgpt.com/403;Cf-Mitigated: challengeThe responses show path-dependent behavior. They do not establish that all other requests from these routes bypass mitigation.
Proxifier and TUN comparison
The updated package adds a proxy-and-desktop-log watch from 2026-10-05 17:19–17:23 UTC. The user reports stopping the WinDivert-based proxifier and enabling TUN routing for a short interval. Before the switch, a proxy entry at 17:19:46 UTC attributed a connection to
codex-cloud-backend.chatgpt.com:443toProxyBridge_CLI.exe. During the reported TUN test interval, an entry at 17:20:05 UTC attributed a connection to the same destination toChatGPT.exe. Both entries used the same selected upstream route. The desktop log independently recordeddurableWebSocket errors withUnexpected server response: 403at 17:19:44.856, 17:20:05.243, and repeatedly afterward through 17:22:12.796 UTC, without a connected transition.The watch file truncates the app log lines before the 403 message; the full message at those timestamps was checked in the updated
applog-durable-403-excerpt.log. The proxy log's process attribution and destination correlate with the app failures but do not provide desktop HTTP response headers or a packet-level link to each error. The watch also records proxifier-attributed traffic again after 17:22 UTC, so the proxifier-off claim applies only to the reported test interval, not the whole watch period. All private and loopback addresses and ephemeral ports have been omitted.Source scope and privacy
Source entries within the supplied package:
01-dots-cloud-403-report.md,applog-excerptsconnection excerpts and summary, andevidencefiles for raw HTTP probes, six regional selections, twelve node selections, host comparison, and the TUN/proxifier watch. The separate airport idle-connection report and its logs concern a different failure mode and are excluded. The tool scripts and original full desktop logs are excluded.The source report includes account, installation, server, environment, and machine-name identifiers. The selected public excerpts omit these identifiers, local file paths, proxy or egress IPs, and credentials. The package was checked for obvious credential-bearing headers in the selected logs; none were found. That is not a guarantee about files outside the supplied package.
jzwtarot98 commentedon Oct 5, 2026
Update to my report above: at approximately 2026-10-05 17:50 UTC, the desktop cloud-task connection recovered after I switched to a different proxy provider, rather than another node within the previous provider.
The earlier route tests therefore should not be taken as ruling out provider/egress-path effects. The exact mechanism remains unknown; this observation does not identify whether the difference is egress reputation, routing, client classification, or another factor. Recovery is currently based on my desktop observation, not a newly captured handshake trace.