Codex session repeatedly disconnects: websocket closed before response.completed

[GGBondBlueWhale]

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.

[github-actions]

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

• Codex App/CLI: subagent tasks trigger reconnect loop and stream disconnect #24475
• Reconnecting Issues #24444
• Recoverable reconnect loop before HTTP fallback when entering new or resumed thread #24045

Powered by Codex Action

[MisterRound]

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

#24260 (comment)

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.