WebSocket upgrade succeeds then server closes with 1008 Policy (falls back to HTTPS)

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

• #13039

Powered by Codex Action

Maintainer note: local paths like /tmp/... in the issue body are not externally accessible. Posting sanitized evidence inline below.

Sanitized websocket policy-close trace

2026-02-27T18:27:54.791212Z  INFO codex_api::endpoint::responses_websocket: connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:55.174925Z  INFO codex_api::endpoint::responses_websocket: successfully connected to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:55.176795Z DEBUG tungstenite::protocol: Received close frame: Some(CloseFrame { code: Policy, reason: Utf8Bytes(b"") })
2026-02-27T18:27:55.182285Z  INFO codex_api::endpoint::responses_websocket: connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:55.606312Z  INFO codex_api::endpoint::responses_websocket: successfully connected to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:55.611381Z DEBUG tungstenite::protocol: Received close frame: Some(CloseFrame { code: Policy, reason: Utf8Bytes(b"") })
2026-02-27T18:27:55.822204Z  INFO codex_api::endpoint::responses_websocket: connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:56.332352Z  INFO codex_api::endpoint::responses_websocket: successfully connected to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:56.339828Z DEBUG tungstenite::protocol: Received close frame: Some(CloseFrame { code: Policy, reason: Utf8Bytes(b"") })
Reconnecting... 2/5 (stream disconnected before completion: websocket closed by server before response.completed)
2026-02-27T18:27:56.725861Z  INFO codex_api::endpoint::responses_websocket: connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:57.021299Z  INFO codex_api::endpoint::responses_websocket: successfully connected to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:57.021518Z DEBUG tungstenite::protocol: Received close frame: Some(CloseFrame { code: Policy, reason: Utf8Bytes(b"") })
Reconnecting... 3/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)
2026-02-27T18:27:57.760883Z  INFO codex_api::endpoint::responses_websocket: connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:58.126456Z  INFO codex_api::endpoint::responses_websocket: successfully connected to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:58.126738Z DEBUG tungstenite::protocol: Received close frame: Some(CloseFrame { code: Policy, reason: Utf8Bytes(b"") })
Reconnecting... 4/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)
2026-02-27T18:27:59.871851Z  INFO codex_api::endpoint::responses_websocket: connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:28:00.243959Z  INFO codex_api::endpoint::responses_websocket: successfully connected to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:28:00.244204Z DEBUG tungstenite::protocol: Received close frame: Some(CloseFrame { code: Policy, reason: Utf8Bytes(b"") })
Reconnecting... 5/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)
2026-02-27T18:28:03.562616Z  INFO codex_api::endpoint::responses_websocket: connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:28:03.930484Z  INFO codex_api::endpoint::responses_websocket: successfully connected to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:28:03.930770Z DEBUG tungstenite::protocol: Received close frame: Some(CloseFrame { code: Policy, reason: Utf8Bytes(b"") })
{"type":"item.completed","item":{"id":"item_1","type":"error","message":"Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: Connection closed normally"}}

Sanitized codex exec --json output

{"type":"thread.started","thread_id":"019ca058-ef8b-7a40-9cad-64885362c9f9"}
{"type":"item.completed","item":{"id":"item_0","type":"error","message":"Under-development features enabled: realtime_conversation, responses_websockets_v2, voice_transcription. Under-development features are incomplete and may behave unpredictably. To suppress this warning, set `suppress_unstable_features_warning = true` in /home/arch/.codex/config.toml."}}
{"type":"turn.started"}
{"type":"error","message":"Reconnecting... 2/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
{"type":"error","message":"Reconnecting... 3/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
{"type":"error","message":"Reconnecting... 4/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
{"type":"error","message":"Reconnecting... 5/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
{"type":"item.completed","item":{"id":"item_1","type":"error","message":"Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: Connection closed normally"}}
{"type":"item.completed","item":{"id":"item_2","type":"reasoning","text":"**Preparing final output**"}}
{"type":"item.completed","item":{"id":"item_3","type":"agent_message","text":"WS_FINAL_CHECK"}}
{"type":"turn.completed","usage":{"input_tokens":9350,"cached_input_tokens":8320,"output_tokens":49}}

@pakrym-oai Follow-up with corrected formatting from my previous comment:

Repro is outside corporate environment (no corporate proxy/VPN), and proxy env vars are unset.

Observed behavior remains: websocket upgrade succeeds, then server immediately closes with 1008 Policy, and client falls back to HTTPS after retries.

If useful, I can run any additional diagnostics you want on this machine/account.

Just to add to the report: I can confirm this is also happening on macOS Tahoe.
I’m using the ChatGPT login flow. However, when I switch to API key authentication, the problem does not happen.

@bruno-ortiz, if you're able to reliably repro the failure, can you use /feedback to upload your logs and a sample session, then post the thread ID here? Thanks!

Hey @etraut-openai, here is the thread ID. 019ca10b-6a31-7bd0-9c2e-1a9d7f309f79. Let me know if I can help in any other way.

Thanks, I see the failure in your logs. Are you using a VPN or corporate network proxy?

Another thread ID: 019ca197-45c7-7700-a15c-ae5d694daefe

Not on a VPN or a proxy =)

same: Falling back from WebSockets to HTTPS transport. stream disconnected before completion: websocket closed by server before response.completed

@etraut-openai no vpn or proxy.

same: codex app 26.227.1448 (747)

We encountered the same problem on Mac, but we used the company's VPN.

Same here, no VPN or Proxy @etraut-openai
I hope this helps > 019ca36e-6685-7791-a1d6-9b8cfe5e8a3f

<img width="478" height="493" alt="Image" src="https://github.com/user-attachments/assets/805bac18-9571-460e-9e93-6c08f8f573cf" />

@etraut-openai no vpn or proxy. the thread ID is 019ca37b-863f-72a3-958a-799e338cc67a

<img width="721" height="331" alt="Image" src="https://github.com/user-attachments/assets/e3215385-1733-4f6a-b140-c58ddbc69b14" />

+1 facing the same problem. How to solve it?

Same problem, thread ID 019ca48a-fc94-7b01-8dd0-968da5be4519 if that helps

reverted to the previous version

Adding one more confirmed variant from Windows/PowerShell (ChatGPT auth):

• Error mode here is handshake-time HTTP 403 Forbidden
• Message: failed to connect realtime websocket: HTTP error: 403 Forbidden
• So this differs slightly from the 1008 Policy after successful upgrade traces already in this thread

Related issue I opened (now centralizing discussion here): #13124

If useful, I can share a sanitized thread ID/log snippet specific to this 403-handshake variant as well.

Same problem here, started happening mid-work when codex updated to latest version during a codex restart, zero other changes

MacOS Sequoia 15.5

Same problem here MacOs 26.2 No VPN or any proxy or filtering its broke.

Thanks to everyone on the thread who reported the issue. We've fixed a few problems on the server side that we think should address most (all?) of the problems that have been reported. Please let us know if you're still seeing a problem. If so, use /feedback to upload logs if you haven't already done so.

Thread Id: 019ca668-fb90-7da3-b0c9-4c655cf0aac5
Falling back from WebSockets to HTTPS transport. stream disconnected before completion: websocket closed by server before response.completed

Codex CLI − v0.106.0
Windows 10 21H2
Using Codex on WSL Ubuntu 24.04.4 LTS

I'm using VPN on Windows.
Codex-CLI websockets work properly on my Windows OS, but not the case on WSL Ubuntu.

Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: Connection
closed normally

Thread id 019ca684-0dd4-7f70-9a4c-1361192f7ead

Codex CLI (v0.106.0)
Windows 11 23H2 using WSL Ubuntu 24.04.3

Still happening for me: 019ca716-9fbc-7fe2-af7f-f6293485b8a2

I am running tailscale, but I've checked with tailscale down, and I still get the same behavior.
Ubuntu 22.04 (running on an old 2015 imac), with codex cli v0.106.0

WSL (Ubuntu) and tailscale too. Both the Codex vscode extension and CLI fallback.
Thread ID: 019ca77b-7861-7ec2-a4b1-5669f43c0689

+1, still the same issue on MacOS Tahoe 26.3. No VPN connected.

Thread ID: 019ca788-6c89-7152-8dc3-282bc4584d4e

Same issue on macos...

Repro report from macOS + proxy network (Clash Verge), still reproducible on codex-cli 0.106.0.

Environment

• OS: macOS 15.7.4 (24G517), Apple Silicon
• CLI: codex-cli 0.106.0
• Auth mode: chatgpt
• Network: traffic via Clash Verge proxy
• Corporate VPN/proxy: not in corporate environment

Minimal repro

Run:

codex exec --json "Reply with OK only."

Output (abridged):

{"type":"thread.started","thread_id":"019ca7a6-b28a-7c11-8ae0-88e74dcbea35"}
{"type":"turn.started"}
{"type":"error","message":"Reconnecting... 2/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
{"type":"error","message":"Reconnecting... 3/5 (...)"}
{"type":"error","message":"Reconnecting... 4/5 (...)"}
{"type":"error","message":"Reconnecting... 5/5 (...)"}
{"type":"item.completed","item":{"id":"item_0","type":"error","message":"Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: Connection closed normally"}}
{"type":"item.completed","item":{"id":"item_2","type":"agent_message","text":"OK"}}

Attempts to avoid WebSocket first-hop (still fails)

1) Disable websocket feature flags:

codex exec --json --disable responses_websockets --disable responses_websockets_v2 "Reply with OK only."

Thread: 019ca7a6-fd8e-7a90-a5d9-86d095c20ed6
Still shows reconnect 2/5..5/5 and then fallback to HTTPS.

2) Force transport="https" via config override:

codex exec --json -c 'transport="https"' "Reply with OK only."

Thread: 019ca7a6-fda4-7240-bc70-2963c3dcec4f
Still shows reconnect 2/5..5/5 and then fallback to HTTPS.

Why this is painful

HTTPS fallback is usually successful, but each turn pays extra retry latency due to initial WS attempts. In this network environment it happens frequently enough to impact usability.

If there is currently no supported "HTTPS-only" mode, could we add one (or expose a config key) so affected users can skip WS pre-attempts?

I'm also getting the websocket retries to 5/5 then fallback to https, Ubuntu cli, never edited the config for these settings

same problem here, no vpn. authenticating via chatgpt oauth. is there a chance this is cloudflare related?

Also reproduces for me on codex-cli 0.107.0-alpha.8 (ChatGPT auth, Arch Linux, zsh+tmux). Same fallback behavior: 'failed to send websocket request: Connection closed normally' and occasional 'websocket closed by server before response.completed'.

@etraut-openai still hapening. thread id --> 019ca9a8-9b24-7080-9c02-1cac33cfa4a0

Same issue here unfortunately @etraut-openai . Here is the thread ID: 019ca9c6-e105-7fa0-ab61-17299131901e
Not using a VPN or corporate proxy either. I notice this in both the cli and extension.

Environment

• Client version : OpenAI Codex (v0.106.0)
• model: gpt-5.3-codex high
• OS: Ubuntu 22.04.5 LTS on WSL (Windows 11)
• Auth mode: chatgpt
• No VPN

Run:

codex exec --json "Reply with OK only."

{"type":"thread.started","thread_id":"019caa56-13d2-7651-9fc3-8a4aaf88f925"}
{"type":"turn.started"}
{"type":"error","message":"Reconnecting... 2/5 ()"}
...
{"type":"error","message":"Reconnecting... 5/5 ()"}
{"type":"item.completed","item":{"id":"item_0","type":"error","message":"Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: Connection closed normally"}}
{"type":"item.completed","item":{"id":"item_1","type":"agent_message","text":"OK"}}

I got same issue.

What does this do, is it a little bit slower or worse ?

Issue first started to appear a few days ago.

also getting this issue on windows with v0.106

Same here since CLI 0.106.0
_Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: Connection closed normally_

Same issue no vpn or anything. Started happening yesterday. Macos Tahoe 26.3 cli v.106. It seems to not edit code in files and just prints code back to me because of this.

Websocket connections to wss://chatgpt.com/backend-api/codex/responses open successfully but are then closed cleanly with code 1008 (policy violation) and no reason after ~2–3 seconds, even with valid auth and regardless of payload. HTTPS streaming to the same backend works with the same auth, so this points to a websocket-specific edge policy issue, likely Cloudflare/WAF (or a gateway behind it), rather than a general auth or network problem.

Hey guys, quick workaround to disable websockets until this is fixed: setting only features.responses_websockets = false is not enough in current behavior, because Codex can still choose WS when the model metadata has prefer_websockets = true. The reliable way is to use an HTTP-only provider and set

```supports_websockets = false:

model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false
base_url = "https://chatgpt.com/backend-api/codex"

After updating config.toml, restart Codex/tasks so it reloads config. This forces HTTPS transport until the websocket path is fixed.

Interesting... If I load an existing session, then Websockets fails and falls back to HTTPS, but if I start a new session in the same folder, it works fine from the start and works very quick.

It seems the new version v0.107.0 doesn't use websockets it seems. Thanks for the update.

I found a related but distinct failure mode from this policy-close/fallback thread.

In my case, under stock/default behavior, websocket setup for ChatGPT auth does not reach upgrade; it times out during connect to wss://chatgpt.com/backend-api/codex/responses.
Local instrumentation points to a likely IPv6-first connect path stall before TLS/websocket upgrade.
In a local diagnostic build (not stock), preferring IPv4 makes upgrade succeed and the stream complete.

Full details: https://github.com/openai/codex/issues/13406

@etraut-openai I am having the same issue with both codex app and cli (v0.111.0). I am not behind any vpn.

thread ID 019cb80b-99b9-7562-b481-3a5669fd33be

Have started facing the same issue again!! Also for god sake please do some testing and then push changes! Don't vibe code always on persistent issues.

For other folks facing issues - please use the same shared here - https://github.com/openai/codex/issues/13041#issuecomment-3981110494

Still having this issue.

running into this with the latest codex-cli 0.114.0 version.
the clue in my case for the team is - it triggered when it was searching the web...

◦ Searching the web

⚠ Falling back from WebSockets to HTTPS transport. stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through
  our help center at help.openai.com if the error persists. Please include the request ID 2a45ca7c-... in your message.

Was happening a lot with codex cli 0.113.0 version in a longer conversation with multiple compactions.
In 0.114.0 it happened only once so far, on the same conversation.

Still having this issue :(

For people like me behind a corporate proxy (palo alto URL filtering) that requires a disclaimer to be clicked, codex exec -C /home/arch --skip-git-repo-check --json "Reply with exactly: WS_FINAL_CHECK" will output the HTML of the proxy's webpage.

I had to access https://chatgpt.com/backend-api/codex/responses to validate the access before I could use codex again

This problem persists; it occurs in the first conversation of almost every thread.

any updates? how to turn off websocket and stick on https for good

I have same issue still also

Same here. Think I'll have to just use Claude Code at this rate.

I have same issue still also

I have same issue still also

any solution?

For anyone using a proxy,
please try setting the SOCKS5 proxy environment variable.

One quick way: https://github.com/openai/codex/issues/6060#issuecomment-4186045653 in ~/.codex/.env, add:

HTTP_PROXY="http://127.0.0.1:10808"
HTTPS_PROXY="http://127.0.0.1:10808"
ALL_PROXY="socks5://127.0.0.1:10808"

I suspect this is because wss may not work properly over an HTTP proxy.

---

Update: I do not know why, but now it works normally even with only HTTP_PROXY and HTTPS_PROXY set. However, the Codex GUI in VS Code still cannot access /status and does not display the usage quota. Perhaps that network request is coming from the extension itself?

I'm also having the issue as of today : Falling back from WebSockets to HTTPS transport. stream disconnected before completion: An error occurred while processing your request. You can retry your
request, or contact us through our help center at help.openai.com if the error persists. Please include the request....

Also getting this issue as of today.

I also noticed the issue, however, it happens only in old threads. Starting a new one works fine for me.

I also noticed the issue, however, it happens only in old threads. Starting a new one works fine for me.

same here, but a new thread after an hour of working or so, develops the same issue:

⚠ Falling back from WebSockets to HTTPS transport. stream disconnected before completion: websocket closed by server
before response.completed

■ {"detail":"Bad Request"}

Happened to me after leaving codex opened over night, seems like there may be a correleation between how long a thread/codex process has been running and this issue.

I hit this on macOS with Codex CLI 0.129.0. I don’t have any MCP servers configured, but Codex was failing to connect/login, and the Codex app was freezing at the login screen. ChatGPT was also unreachable from the same Mac on my home Wi-Fi.

The root cause in my case was macOS Private Wi-Fi Address being enabled for that network. With it enabled, curl -4vI https://chatgpt.com would resolve the hostname successfully, but then fail with No route to host. IPv6 failed similarly. Switching to a phone hotspot worked, which pointed to the Wi-Fi/router path rather than Codex itself. Turning off Private Wi-Fi Address for that Wi-Fi network fixed it immediately. After that, ChatGPT loaded again and Codex login worked.

I’m not sure whether this is specific to my router, but the router UI did indicate that the private MAC address was limiting connection quality. So for anyone seeing Codex auth/login/connectivity failures on macOS, it may be worth checking:

• System Settings → Wi-Fi → Details → Private Wi-Fi Address
• Whether curl -4vI https://chatgpt.com resolves but then fails with No route to host
• Whether the same Mac works on a phone hotspot

Yeah, well, I just hit this issue and I specifically have the Mac set to a fixed address in the Wi-Fi settings, and that was before I got this issue.

I have no VPN running.

and it was a completely fresh codex session, because actually I had a different issue where GhostTTY got detached from its context and it lost its view of the world.

I completely restarted the whole terminal, and when I relaunched Codex, this issue happened straight away.

So it's not related to the length of time it's open.

Yep, I can confirm that my comment above didn't fix it, I've just run into the same problem again. Not sure whats going on.

However, when swapping over to my mobile tether, it starts working again, so I'm certain its a networking issue connecting to chatgpt.com (for me anyway).

I've just seen in my deco networking app, it was flagged as a DDOS attack and therefore was blocked, happened at the same time I lost ability to use codex, so its either a coincidence or my network is too sensitive. 🤷🏻‍♂️

Having turned off intrusion prevention on my deco network seems have got it working again, it could be that my network is seeing me chatting with codex as a potential DDOS attack?

Maybe I'm chatting with chatgpt.com too much 😆

happened twice for the first time today. Is this a new bug ._.

I had a similar issue. Frequent "Reconnecting ../5", high latency, and long sessions become unusable when running codex cli on a vps and connecting to it either directly on the vps or via Mac codex app.
See feedback 019e63c6-d9fe-7b10-b1be-ba2e7315a94e

Errors I saw:
"Falling back from WebSockets to HTTPS transport"
"stream disconnected before completion: websocket closed by server before response.completed"
"Connection reset without closing handshake"

still happening. for me also

the workaround mentioned here worked for me. It is however much slower than with websockets (and even when using fast mode)

Having this issue on aws ec2 ubuntu

This issue is a regular for me, my codex is always the latest version - MacOS Tahoe 26.4

Falling back from WebSockets to HTTPS transport. stream disconnected before completion: websocket
closed by server before response.completed

Edit: With a bit of debugging - my likely cause is overloading the context with a single message - likely by sending images (likely when compaction was near)

Ditto +1

OS: Arch Linux (x86_64), kernel 7.0.11-arch1-1
Codex CLI: openai-codex 0.140.0-1
Node: v26.2.0
npm: 11.17.0

Reconnecting 2/5
stream disconnected before completion: idle timeout waiting for websocket

I get this very often; it's incredibly frustrating.