Responses WebSocket closes before response.completed

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

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_websocket transport path.
  • Host-level DNS and TCP connectivity to api.openai.com:443 succeed.

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.

  • #19703
  • #19330
  • #19983
  • #19745

Powered by Codex Action

anjulahettige · 1 day ago

I’m seeing the same issue on macOS through T3 Code.

My setup:

  • Codex CLI 0.150.0
  • T3 Code 0.0.34
  • macOS arm64, Darwin 25.6.0
  • ChatGPT login
  • gpt-5.6-sol

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.completed

It reached Reconnecting... 2/2 and 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/2 looks 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.