Codex: stream disconnected before completion

What you see

A turn stops before it finishes and the client prints a line containing:

stream disconnected before completion: stream closed before response.completed

The important part is the last clause: response.completed never arrived. The stream that carries the model’s reply was closed from one end while the client was still expecting events on it. The task does not resume by itself — in the report behind this guide, the reporter had to prompt the agent to continue.

What it usually means

This is a transport-level symptom. It tells you the connection ended early; it does not tell you why, and there is more than one plausible reason:

• A network path that drops long-lived connections. Corporate proxies, VPNs, TLS-inspecting middleboxes and flaky Wi-Fi are the classic sources. In the primary report for this error, a maintainer reviewed the uploaded logs, found nothing pointing at a product fault, and suggested the reporter work with their IT team on routing, proxies and firewalls.
• A server-side event that ends the response. A response can also be terminated by the server rather than the network. A repeated failure by itself does not identify which side closed the connection.
• A stale cached credential. One reporter on the same issue thread reported that removing a cached authentication file and signing in again made the error stop for them. That is a single unverified report — it is worth testing, but it is not established as a general fix.

Do not treat any one of these as the cause. The point of the checks below is to find out which branch you are on.

Quick checks

Run these before changing anything, because they tell you which of the branches above applies to you.

1. Does it happen on every turn or only some turns? Every turn, immediately, suggests something more systematic than a flaky network. Occasional failures after long responses point at connection lifetime.
2. Does it happen on a different network? Try a tethered phone hotspot or a home connection instead of the corporate network. If the error disappears, investigate the original network path before changing Codex settings. One successful attempt does not establish the cause.
3. Does it correlate with response length? If it only breaks on long turns, an idle timeout or proxy connection limit is a better candidate than an authentication problem.
4. Are other long-lived connections healthy? If streaming from other services also stalls on this network, the problem is very unlikely to be Codex-specific.

Fixes, by branch

If it only happens on one network

Work on the network path, not on Codex.

• Ask whether the network inspects TLS or proxies HTTPS. If it does, ask the network owner to allow long-lived streaming connections to the API endpoint.
• Temporarily route through a different connection and confirm the error stops. A confirmed network cause needs no client-side change.
• Record which network reproduced it. That detail is what makes a bug report useful if you end up filing one.

If it looks like the server ended the response

• Note the exact timestamp, the model, and the thread or session id your client shows.
• Use your client’s own feedback mechanism to upload session details. In the report behind this guide, maintainers asked reporters to do exactly that because the client-side logs did not contain the cause.
• Do not retry the identical prompt dozens of times; a repeated identical failure is already diagnostic.

If you also see a sign-in error

Follow the login troubleshooting guide when there is a separate authentication failure. Capture its exact wording and the stage that failed.

A reporter mentioned cached credentials, but that does not make manual credential-file changes a general fix for a disconnected stream. Use your client’s normal sign-in flow when authentication is actually the failing branch.

What not to do

• Do not start by deleting your whole Codex configuration directory. Nothing in the available evidence points there, and you would lose the setup you need for unrelated problems.
• Do not disable TLS verification, certificate checks or your corporate security tooling to make the error go away. That trades a visible error for an invisible risk.
• Do not paste authentication tokens into a bug report or a chat when asking for help.

How to tell it worked

You are done when the same kind of long-running turn completes without the disconnect, on the network you normally use, across several attempts. One clean run is not enough — this error is intermittent by nature, so give it a handful of tries.

If it is still failing

If you have confirmed it is not network-specific and it still fails on short turns, it is reasonable to report it. Include the client version, operating system, plan type, the exact error line, roughly how long into the turn it appears, and whether a different network changes anything.

Known limits of this guidance

• Evidence level: reported. This is built from a public bug report and a maintainer reply, not from a reproduction by this site.
• The report was on Windows with CLI 0.87.0. Other platforms and versions may present differently.
• The maintainer reply described the specific logs reviewed; it did not establish that every instance of this message has the same cause.
• A related message with different wording, idle timeout waiting for SSE, appears in separately reported issues. Whether it should be treated as the same problem is not settled by the sources below, so this guide does not claim they are identical.