›_ Codex Issues
Codex Issues / #24533

Codex session repeatedly disconnects: websocket closed before response.completed

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

Summary

While running a Codex task, the connection became very unstable and repeatedly showed reconnecting behavior. The session eventually surfaced this error:

stream disconnected before completion: websocket closed by server before response.completed

The UI showed reconnect attempts such as Reconnecting... 2/5 during the task.

Feedback ID

019e62a9-9544-7780-864a-566226a188ac

Environment

  • Codex app version: 26.519.41501 (3044)
  • macOS: Tahoe 26.5
  • Device: MacBook Pro 16-inch, Apple M5 Max, 128 GB memory
  • Network: home network, no VPN enabled

Expected behavior

Codex should keep the session stream stable until the task completes, or recover cleanly after a transient reconnect without losing the response/completion state.

Actual behavior

The stream disconnected before completion and the websocket was closed by the server before response.completed, causing the task to become unstable instead of finishing normally.

<img width="2102" height="260" alt="Image" src="https://github.com/user-attachments/assets/9eb2fd65-100b-46fd-80cb-59e6af764612" />

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

  • #24475
  • #24444
  • #24045

Powered by Codex Action

MisterRound · 3 months ago

This exact error is now tied into the broader stream/retry/state synthesis in #24260:

https://github.com/openai/codex/issues/24260#issuecomment-4549511594

The short source-level mapping is:

  • current codex-rs/codex-api/src/endpoint/responses_websocket.rs emits websocket closed by server before response.completed when a Responses WebSocket close frame arrives before a response.completed event;
  • current default retry budget is 5 stream retries, and release builds hide the first WebSocket retry notification, which explains why users often first see Reconnecting... 2/5;
  • after the retry budget, Codex attempts HTTP fallback for the session;
  • related reports show this exact path can combine with separate Desktop/session-state bugs such as unknown conversation, terminal turns restored as markedStreaming=true, and missing turn items.

So I think this issue is a clean representative of the exact WebSocket-close subcluster, while #24260 is currently the broader cross-thread tracker for how this interacts with first-output stalls and Desktop state recovery.