Falling back from WebSockets to HTTPS transport. stream disconnected before completion: Operation timed out (os error 60)

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

• #13710
• #14877
• #14080
• #14062
• #13832

Powered by Codex Action

Seeing this on every launch with Codex CLI 0.125.0 on Linux x64.

What I get:

• Reconnecting... 2/5 ... Timeout waiting for child process to exit
• ⚠ Falling back from WebSockets to HTTPS transport. timeout waiting for child process to exit

From local logs, the session still proceeds after the fallback via responses_http, so this is a startup degradation rather than a hard failure. The timeout is in the startup websocket prewarm path:

• startup websocket prewarm setup failed: timeout waiting for child process to exit

This happens consistently even when no stale Codex processes are involved. experimental_realtime_ws_startup_context = "" does not stop the prewarm attempt; it only disables the startup context injection.

If useful, I can share the exact log excerpt and environment details.

any update/duplicate issues on this?

Same class of behavior on a newer CLI, with a slightly different OS error.

Environment:

• Codex CLI 0.142.2
• WSL2 Ubuntu via Windows Terminal
• Built-in OpenAI provider / ChatGPT auth
• Model gpt-5.5, high reasoning

Observed warning:

Falling back from WebSockets to HTTP(S) transport: stream disconnected before completion: failed to send websocket request: IO error: Broken pipe (os error 32)

So this case is os error 32 / Broken pipe rather than os error 60, but the user-visible behavior is the same: Codex spends several minutes on Reconnecting... 5/5, then HTTP/SSE fallback works and the turn completes.

In one affected long session, the recorded time_to_first_token_ms was about 295,506 (~4m56s), with full turn duration around 386,761 ms. The local transcript was large (~623 MB / 12,050 JSONL lines), and the turn was high-context (~222k input tokens against a 258,400 context window).

This is not fatal, but it is very disruptive because the working transport is only used after the retry budget is burned. Please consider treating WebSocket timeout/write/network failures as a fast fallback case, or exposing a supported HTTP/SSE-only transport option.

Bump: ⚠ Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: IO error: Broken pipe (os error 32)

Reporting a much more disruptive variant of this on:

• Codex CLI 0.145.0-alpha.18
• WSL2 Linux x86_64
• xterm-256color
• Observed across an active coding session; switching to gpt-5.6-terra did not recover it

I cannot maintain a working session for longer than roughly 10–15 minutes before the active turn dies with:

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

This is not merely a slow startup followed by a successful HTTP fallback. It hard-terminates an in-progress turn. In the latest occurrence, Codex had completed an authenticated browser reproduction and was running final lint/build verification when the stream disconnected. Afterward:

1. Resume immediately produced the same disconnect.
2. A second Resume immediately produced the same disconnect.
3. Switching models did not recover the session.
4. Additional messages continued failing with the same error.
5. I had to start a new session, paste the surviving transcript, reconstruct the worktree state, and rerun the unfinished verification.

This is happening repeatedly and makes sustained agent work unreliable because turn/session continuity is effectively lost every 10–15 minutes. Please treat websocket closure as a fast automatic HTTP/SSE fallback case, or provide a supported HTTP/SSE-only option. Resume also needs to recover the interrupted response instead of entering the same disconnect loop.