›_ Codex Issues
Codex Issues / #13039

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

Resolved 💬 8 comments Opened Feb 27, 2026 by kali113 Closed Feb 27, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

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

  1. 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.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 4 months ago

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

  • #12273
  • #11682
  • #12548
  • #11741

Powered by Codex Action

kali113 · 4 months ago

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 contributor · 4 months ago

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

kali113 · 4 months ago

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 · 4 months ago

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 contributor · 4 months ago

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

Lucas-ljx · 4 months ago

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

nylla8444 · 2 months ago

Still happening btw