›_ Codex Issues
Codex Issues / #13406

ChatGPT-auth websocket connect to chatgpt.com hangs before upgrade; local diagnostics point to IPv6-first address selection

Open 💬 7 comments Opened Mar 3, 2026 by egillax
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

  • On Linux with ChatGPT auth, Codex hangs during websocket connect to wss://chatgpt.com/backend-api/codex/responses.
  • This does not appear to be a post-upgrade close-frame problem.
  • Local instrumentation shows the hang occurs during websocket connect/setup before TLS/websocket upgrade completes.
  • In a locally instrumented diagnostic build, preferring/forcing IPv4 makes websocket connect succeed immediately, return 101 Switching Protocols, and the stream complete.

Environment

  • Codex CLI version: 0.107.0
  • OS: Ubuntu 24.04.4 LTS
  • Terminal stack: Alacritty + tmux
  • Auth modes compared on same machine:
  • ChatGPT auth: failing
  • API key auth: working

Stock repro

  • Use Codex CLI 0.107.0
  • Authenticate with ChatGPT auth
  • Start Codex
  • Submit a simple prompt such as hello
  • Observe that the session hangs and does not produce a response
  • Local instrumentation shows this corresponds to websocket connect timing out before upgrade

Diagnostic findings from a local instrumented build

  • ChatGPT auth path:
  • endpoint: wss://chatgpt.com/backend-api/codex/responses
  • auth branch observed in logs: bearer_plus_chatgpt_account_id
  • sanitized handshake metadata showed:
  • authorization header present
  • ChatGPT account id header present
  • no cookie header
  • DNS resolution was fast
  • first resolved candidate was IPv6
  • a preflight TCP connect to the first IPv6 candidate timed out
  • websocket connect then timed out after 30s
  • no TLS/websocket upgrade success was reached
  • API key path:
  • endpoint: wss://api.openai.com/v1/responses
  • auth branch observed in logs: bearer_only
  • DNS resolution succeeded
  • preflight TCP connect succeeded quickly
  • websocket connect succeeded in ~585ms
  • stream completed

Strongest diagnostic result

  • In a local diagnostic build, I added temporary address-family selection logic only for investigation.
  • Under default/system address ordering, the ChatGPT-auth websocket connect timed out.
  • When IPv4 was preferred in that diagnostic build:
  • TCP connect succeeded on IPv4 in ~13ms
  • websocket upgrade succeeded with 101 Switching Protocols
  • stream completed
  • When IPv4-only was used in that diagnostic build:
  • same successful outcome

Practical root-cause boundary

  • The practical boundary appears to be IPv6/address-selection/fallback behavior to chatgpt.com before TLS/websocket upgrade in the current websocket connect path.
  • This appears distinct from the issue where websocket upgrade succeeds and the server then closes with a policy code.

Suggested fix direction

  • Improve websocket dual-stack connect behavior (for example Happy Eyeballs or faster fallback across resolved addresses)
  • or expose a supported address-family preference / IPv4 fallback if needed
  • current behavior appears to stall too long on the first bad IPv6 candidate

Notes

  • API-auth works on the same machine/network, so this does not look like a general websocket/TLS failure.
  • The difference appears tied to the chatgpt.com websocket endpoint and its address-selection path.
  • I can provide the local diagnostic patch details if useful, but the public repro above uses stock Codex behavior.

Concise log excerpts

ChatGPT auth, stock/default behavior:

  • opening responses websocket connection connect_phase="initial_session_websocket_setup" auth_mode="chatgpt"
  • connecting to websocket: wss://chatgpt.com/backend-api/codex/responses
  • websocket connect timed out ... connect_elapsed_ms=30000
  • responses websocket connection failed ... auth_mode="chatgpt"

Local diagnostic build, IPv4-preferred ordering:

  • resolved_addresses=[IPv6, IPv6, 172.64.155.209:443, 104.18.32.47:443]
  • ordered_addresses=[172.64.155.209:443, 104.18.32.47:443, IPv6, IPv6]
  • candidate tcp success ... address_family="ipv4" tcp_elapsed_ms=13
  • websocket upgrade succeeded ... response_status=101 Switching Protocols
  • responses websocket connection established ... auth_mode="chatgpt"

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

  • #13168

Powered by Codex Action

etraut-openai contributor · 4 months ago

Thanks for the bug report. When Codex cannot connect using websockets, it is designed to fall back to http. Currently, that happens only after five reconnect attempts (you'll see "Reconnecting 1/5" through 5/5 in the message stream), but it should eventually fall back and recover by using http. Does that happen in your case? Or does it hang indefinitely? If it hangs, that's a much worse problem than if it is able to fall back to http and continue after a short delay

egillax · 4 months ago

In my case it does not appear to recover or fall back to HTTP, at least not within a few minutes.

I also do not see the Reconnecting 1/5 … 5/5 messages in the UI.

Once it gets into that state, Ctrl+C / Ctrl+D do not stop it cleanly for me; the only reliable way I’ve found to exit is killing the tmux window/session.

moritzdemmer · 4 months ago

@egillax Same, does also not fall back to http but I see the 1/5 reconnecting attempts

Veridiann · 3 months ago

I'm having the same issue. Its unusable.

Trying to get claude code to debug.

Kiriketsuki · 3 months ago

Same issue confirmed on auth token exchange (not just websocket)

Environment

  • Codex CLI: 0.118.0
  • OS: Arch Linux 6.18.13-arch1-1, x86_64
  • Network: Dual-stack (IPv4 + IPv6), residential ISP (Singapore)

Symptom

codex login via ChatGPT auth (option 1) and Device Code (option 2) both fail:

Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)
error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode)

Log excerpt:

codex_login::server: oauth token exchange transport failure is_timeout=false is_connect=true is_request=true

Root cause confirmation

auth.openai.com resolves to IPv6-only via getent hosts:

2a06:98c1:3106::ac40:920f auth.openai.com.cdn.cloudflare.net
2606:4700:4406::6812:29f1 auth.openai.com.cdn.cloudflare.net

IPv6 connectivity is broken on this machine. curl -4 works, curl -6 hangs. Codex's reqwest client tries IPv6 first, fails to connect, and does not fall back to IPv4.

Also affects api.github.com and chatgpt.com — all outbound HTTPS from Codex fails:

Request failed method=GET url=https://api.github.com/repos/openai/codex/releases/latest error=error sending request for url
failed to send remote plugin sync request to https://chatgpt.com/backend-api/plugins/featured

Workaround

Force IPv4 via /etc/hosts:

104.18.41.241 auth.openai.com

Login succeeds immediately after this.

Note

This is the same IPv6-first / no-fallback issue as the websocket hang described in this issue, but manifesting earlier in the auth flow. Happy Eyeballs (RFC 6555) in the reqwest client would fix both.

Don-Yin · 26 days ago

Corroborating on macOS + Tailscale, with a clean version bisection: __0.141.0 works, 0.142.0 is broken.__

__Regression (the actionable bit):__

  • 0.141.0 connects instantly and works. 0.142.0 stalls ~15-20s at connection setup on _every_ OpenAI request, then fails. npm install -g @openai/codex@0.141.0 reliably restores it.
  • The 0.142.0 binary has ~3.7x more hickory(-dns) symbol refs than 0.141.0 (157 vs 42), so the connector/resolver path looks like what changed.

__Scope (not just the websocket):__

  • codex login (ChatGPT) gives token_exchange_failed: error sending request for url (https://auth.openai.com/oauth/token) (same as #26764).
  • Forcing responses_http (custom provider with supports_websockets=false) stalls _identically_ to responses_websocket, so it is the connection layer, not the transport.
  • Telemetry / plugins endpoints fail the same way.

__Localization (matches the IPv6-first address-selection theory):__

  • reqwest debug trace shows the gap is purely connection setup:

``
starting new connection: https://api.openai.com/
(+15.1s) connected to 162.159.140.245:443
``

  • dig resolves in <150ms, and curl to the same hosts and IPs is instant, including a manual WebSocket upgrade to wss://api.openai.com/v1/responses (returns 401 in 0.6s). macOS getaddrinfo suppresses AAAA when there is no global IPv6 address, so curl stays on IPv4; Codex's bundled resolver returns AAAA regardless, which fits the IPv6-first selection hypothesis.
  • Environment: macOS (Darwin 25.5.0, arm64), __Tailscale active__ (adds extra utun interfaces and IPv6 routes, a likely dual-stack trigger). Reproduced on two unrelated networks.

__Re: the intended HTTP fallback__ - on 0.142.0 it does _not_ recover here; it loops "Reconnecting 1/5 ... 5/5" and stays dead (matching @egillax / @moritzdemmer). Only downgrading to 0.141.0 restored it.