WebSocket transport closes immediately with code 1008 (Policy) then falls back to HTTPS

[kali113]

Summary

Codex WebSocket transport to wss://chatgpt.com/backend-api/codex/responses consistently fails in my environment.

The websocket handshake succeeds (101 Upgrade), then the server immediately sends a close frame with code 1008 (Policy) and empty reason. Codex retries 5 times and falls back to HTTPS.

This blocks websocket transport usage for realtime/voice related features.

Environment

• OS: Arch Linux (x86_64), kernel 6.18.9-arch1-2
• Codex CLI: 0.106.0
• Also tested: 0.107.0-alpha.5 (same result)
• Node: v25.7.0
• npm: 11.10.1
• Auth mode: ChatGPT login (codex login status => Logged in using ChatGPT)
• Feature flags:
  • responses_websockets_v2 = true
  • realtime_conversation = true
  • voice_transcription = true

Repro steps

1. Enable websocket + realtime + voice feature flags.
2. Run:

   codex exec -C /home/arch --skip-git-repo-check --json "Reply with exactly: WS_FINAL_CHECK"

3. Observe reconnect loop and fallback.

Expected

WebSocket connection remains open and request/stream proceeds over websocket transport.

Actual

• Repeated:
  • Reconnecting... 2/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)
  • through 5/5
• Then:
  • Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: Connection closed normally

Trace evidence

Sanitized trace (auth redacted) shows successful websocket upgrade followed by immediate policy close:

2026-02-27T18:27:54.791212Z  INFO ... connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
2026-02-27T18:27:55.174925Z  INFO ... 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"") })
...
Reconnecting... 5/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)
... Falling back from WebSockets to HTTPS transport ...

Additional notes

• Reproduces across many attempts/sessions.
• Same behavior with responses_websockets (legacy) and responses_websockets_v2.
• No local proxy env vars configured.
• This looks like server-side policy rejection after successful upgrade.

Request

Please help identify why this account/session is policy-closed (1008) for Codex responses websocket, and whether there are account entitlements/conditions required for websocket transport.

[github-actions]

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

• Falling back from WebSockets to HTTPS transport #12273
• Regression: stream disconnected before completion on Windows in 0.100.0+ (works in 0.99.0) #11682
• Stuck in reconnecting loop. Finally times out 5/5 with message: "stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses) #12548
• stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses) #11741

Powered by Codex Action

[kali113]

Follow-up triage details to help de-duplicate correctly:

• This is not just generic reconnect/fallback; trace consistently shows:
  • successful WS upgrade to wss://chatgpt.com/backend-api/codex/responses
  • immediate server close frame: CloseFrame { code: Policy (1008), reason: "" }
  • then reconnect loop and HTTPS fallback
• Reproduced on Linux (Arch), not only Windows.
• Reproduced on both websocket variants:
  • responses_websockets_v2 = true
  • responses_websockets = true (legacy)
• Reproduced on:
  • codex-cli 0.106.0 (stable)
  • codex-cli 0.107.0-alpha.5
• No proxy env vars set.

Sanitized evidence excerpt:

INFO  connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
INFO  successfully connected to websocket: wss://chatgpt.com/backend-api/codex/responses
DEBUG 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)
Falling back from WebSockets to HTTPS transport ...

Given the immediate 1008 post-upgrade behavior, this looks like a server policy/entitlement gate on websocket transport rather than local connectivity.

[pakrym-oai]

Any chance you are in a corporate environment, possibly behind a proxy?

[kali113]

Closing per reporter preference; will recreate later with a sanitized report package and fresh repro. (For context: this was reproduced outside corporate proxy/VPN conditions.)

[yoloyash]

I know this issue is closed but just wanted to point out that this is happening to me too (Ubuntu 24, not in a corporate env/proxy).

[etraut-openai]

@yoloyash, we're tracking this in #13041. We're investigating the problem.

[Lucas-ljx]

Falling back from WebSockets to HTTPS transport 这个问题如何解决呢

[nylla8444]

Still happening btw