Codex keep reconnecting #28295

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Jun 15, 2026
2. github-actions commented on Jun 15, 2026

   

   github-actionsBot

   on Jun 15, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Repeated idle timeout waiting for websocket disconnects within a single Codex task #27625
   • Latest Codex repeatedly reconnects in old sessions and cannot start follow-up tasks #26720
   • Stream disconnects before completion with repeated 5/5 reconnect failures #26696
   • GPT-5.5 Fast spent 12+ minutes thinking, produced no output, then entered reconnecting state #27661
   • Codex uses chatgpt.com web endpoint instead of api.openai.com — causing 16,000+ connections/day and 65GB bandwidth in 6 days #27952

   Powered by Codex Action
3. tolgaergin commented on Jun 15, 2026

   

   tolgaergin

   on Jun 15, 2026

   More actions

   It's duplicated issue for a long time and it's not fixed.

   I'm seeing frequent stream disconnected before completion: idle timeout waiting for websocket errors in Codex App and VS Code.

   This is not related to repo size, model, or reasoning effort. I've reproduced it with GPT-5.5 Low, High, and XHigh, and even on very simple prompts. The behavior appears random.

   Typical pattern:

   Task starts normally.
   After ~5 minutes: Reconnecting 1/5
   Repeats through Reconnecting 5/5
   During reconnects the agent sometimes continues making progress (reading/editing files).
   After the final reconnect the task often resumes normally.

   

   This feels more like a websocket/streaming/agent transport issue than a model-quality or repo-size issue. Several users appear to be reporting similar idle timeout waiting for websocket reconnect loops.

   After 5/5 everything turns to normal for couple of minutes then it starts 1/5 2/5 3/5 4/5 5/5.

   Codex app, vscode, cli not usable anymore
4. xsourabhsharma commented on Jun 15, 2026

   

   xsourabhsharma

   on Jun 15, 2026

   More actions

   are you on window? check node_repl.exe if this is broken then it caused "timeout waiting for child process to exit"
5. tolgaergin commented on Jun 15, 2026

   

   tolgaergin

   on Jun 15, 2026

   More actions

   Thanks. I'm on macOS, not Windows.

   Codex App version: 26.609.41114
   codex-cli: 0.139.0
   No proxy, VPN, or MDM

   The behavior is random. Sometimes Codex works perfectly, sometimes a simple task ends up taking 20–40 minutes because it cycles through Reconnecting 1/5 → 2/5 → 3/5 → 4/5 → 5/5
6. tolgaergin commented on Jun 15, 2026

   

   tolgaergin

   on Jun 15, 2026

   More actions

   TL;DR - this is Cloudflare's ~100 s idle-WebSocket timeout, not your network.

   Codex's default Responses transport is a WebSocket, and chatgpt.com is served through Cloudflare, which closes any WebSocket with no frames in either direction for ~100 s. On a long turn the model can stay silent past 100 s → Cloudflare drops the socket → idle timeout waiting for websocket → Reconnecting 1/N. It's noticeably worse with high model_reasoning_effort, because the silent gaps between tokens are longer.

   Workaround that fixes it today force the HTTP/SSE transport (SSE is a normal HTTP stream, so the 100 s WebSocket cap never applies). Add to ~/.codex/config.toml and fully restart Codex:

   because it changes model_provider the previous conversations will not be visible after you uedit config.toml file and restart the codex app - I asked handoff prompt from the conversation that i want to continue.

   model_provider = "chatgpt-http"
   
   # Force SSE instead of WebSocket so Cloudflare's 100s idle-WS timeout can't drop long turns
   [model_providers.chatgpt-http]
   name = "ChatGPT (HTTP/SSE)"
   base_url = "https://chatgpt.com/backend-api/codex"
   wire_api = "responses"
   requires_openai_auth = true
   supports_websockets = false

   Root cause (confirmed in the codebase): the Responses WebSocket transport never sends client-initiated keepalive pings.

   In codex-rs/codex-api/src/endpoint/responses_websocket.rs, the WsStream pump task drives the socket with a tokio::select! that has only two arms, outgoing commands, and inner.next() for incoming frames. The incoming path answers a server Ping with a Pong but never initiates a ping, and there is no timer arm. tokio-tungstenite doesn't auto-ping, so during a long, quiet reasoning turn (no Text frames from the server, no client commands) the socket sits fully idle.

   chatgpt.com is fronted by Cloudflare, whose default idle-WebSocket timeout is 100 s (Free/Pro, not configurable below Enterprise). A quiet turn past ~100 s is closed by the edge and surfaces as idle timeout waiting for websocket → Reconnecting N/5. It's worse at higher model_reasoning_effort since the silent gaps are longer. Almost certainly the same root cause as #27625, #24533, #18960, #20739.

   I ruled out the local network from the affected machine: a control idle TLS connection to an unrelated host held 10 minutes untouched, and idle-close times varied per-CDN (i.e. server-side, not a local middlebox). So this is the edge in front of the Responses API, not users' networks.

   Fix outline - add a keepalive arm to the pump loop: a tokio::time::interval (~30 s, well under 100 s) that sends Message::Ping. The pump owns the sink and keeps running while the cached connection is idle between/within turns, so it keeps exactly the gaps that currently die warm. Mirrors the existing keepalive in app-server-transport/.../remote_control/websocket.rs.

   // inside the pump task in WsStream::new
   let mut keepalive =
       tokio::time::interval_at(Instant::now() + KEEPALIVE, KEEPALIVE);
   keepalive.set_missed_tick_behavior(MissedTickBehavior::Skip);
   // ...and a third select! arm:
   _ = keepalive.tick() => {
       if let Err(err) = inner.send(Message::Ping(Vec::new().into())).await {
           let _ = tx_message.send(Err(err));
           break;
       }
   }

   I've implemented this with a passing unit test (a loopback WS server asserting the pump emits a client-initiated ping). I see external contributions are invitation-only, happy to open a PR if the team would like it; tolgaergin@320a3c0

   👍React with 👍2Reacted by Usif and Tomczhang

   ❤️React with ❤️1Reacted by Shubhro Saha