Repository navigation
Falling back from WebSockets to HTTPS transport. stream disconnected before completion: Operation timed out (os error 60) #15014
Description
What version of Codex CLI is running?
codex-cli 0.115.0
What subscription do you have?
plus
Which model were you using?
gpt-5.4
What platform is your computer?
macOS
What terminal emulator and version are you using (if applicable)?
AndroidStudio
What issue are you seeing?
Opening a new session will reconnect 5 times and then an error will occur. Falling back from WebSockets to HTTPS transport. stream disconnected before completion: Operation timed out (os error 60)
What steps can reproduce the bug?
Uploaded thread: 019cfed9-a67a-7cc2-b9fa-dedec92120d8
What is the expected behavior?
Opening a new session will reconnect 5 times and then an error will occur.
Additional information
No response
Activity
github-actions commentedon Mar 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Oldrich333 commentedon Apr 26, 2026
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 exitFrom 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 exitThis 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.
danisharora099 commentedon May 7, 2026
any update/duplicate issues on this?
simfor99 commentedon Jun 26, 2026
Same class of behavior on a newer CLI, with a slightly different OS error.
Environment:
gpt-5.5, high reasoningObserved 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 thanos error 60, but the user-visible behavior is the same: Codex spends several minutes onReconnecting... 5/5, then HTTP/SSE fallback works and the turn completes.In one affected long session, the recorded
time_to_first_token_mswas 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.
web3dev1337 commentedon Jul 24, 2026
Bump: ⚠ Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: IO error: Broken pipe (os error 32)
ColeMatthewBienek commentedon Aug 1, 2026
Reporting a much more disruptive variant of this on:
I cannot maintain a working session for longer than roughly 10–15 minutes before the active turn dies with:
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:
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.