Responses WebSocket closes before response.completed
Summary
Codex intermittently loses the Responses WebSocket stream before receiving response.completed, causing turns to retry or fail with:
stream disconnected before completion: websocket closed by server before response.completed
Reference/session id from the affected Codex run:
019de6d6-2863-7401-99e4-af3ed9b0f4a9
Environment
- Codex CLI:
codex-cli 0.128.0 - OS: macOS 26.4.1, Darwin 25.4.0, arm64
- Model:
gpt-5.5 - Wire API:
responses - Transport:
responses_websocket - Provider: OpenAI
What is happening
During normal Codex turns, the runtime opens a Responses WebSocket connection, then the connection closes before the stream emits a final response.completed event. The client retries the sampling request, but this has been recurring across turns.
Representative local log lines:
model_client.stream_responses_websocket{model=gpt-5.5 wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true websocket.warmup=false}: codex_core::client: new
model_client.websocket_connection{provider=OpenAI wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true}: codex_core::client: new
model_client.websocket_connection{provider=OpenAI wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true}: codex_core::client: close
codex_core::session::turn: stream disconnected - retrying sampling request (1/5 in 206ms)...
The stream appears to close at the transport layer rather than because of project code. The active project has no OpenAI/WebSocket streaming implementation; this is coming from Codex runtime logs.
Network sanity check
I checked local connectivity outside the Codex sandbox:
dscacheutil -q host -a name api.openai.com
name: api.openai.com
ip_address: 172.66.0.243
ip_address: 162.159.140.245
nc -vz api.openai.com 443
Connection to api.openai.com port 443 [tcp/https] succeeded!
Inside the sandbox, DNS/connectivity probes can fail, but the host network itself can resolve and connect to api.openai.com:443.
Expected behavior
Codex should keep the Responses WebSocket stream open until it receives response.completed, or surface a more specific upstream/server-close reason when the server closes the socket before completion.
Actual behavior
The WebSocket closes before response.completed, producing repeated stream disconnected retries and occasionally interrupting completion of the turn.
Notes
This looks upstream/runtime-side rather than repository/app-side:
- The affected project is a small Vite app with no OpenAI streaming code.
- The failure happens in Codex's
responses_websockettransport path. - Host-level DNS and TCP connectivity to
api.openai.com:443succeed.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I’m seeing the same issue on macOS through T3 Code.
My setup:
It happened several times while I was prompting in the same long-running thread. The thread was using approximately 718,000 of 828,400 tokens and started automatic context compaction.
The logs showed:
stream disconnected before completion: websocket closed by server before response.completedIt reached
Reconnecting... 2/2and then switched from WebSockets to HTTPS.I restarted T3 Code during the first two attempts because it looked stuck. On the third attempt, I left it running. The HTTPS fallback recovered after approximately 35 seconds, context compaction completed, and the prompt continued normally.
The context dropped to approximately 11,500 tokens after compaction.
The confusing part is that
Reconnecting... 2/2looks like the final failure, although the HTTPS fallback may still be working. Restarting during this period interrupts a recovery that could complete on its own.I can provide redacted logs and identifiers privately if they would help.