Pricing
Codex "Stream Disconnected Before Completion": Causes and Fixes
Codex failing with 'stream disconnected before completion'? The two usual causes, network or a custom provider, and the checks that fix each one, in order.
7 min read
Error wording checked Oct 30, 2026 in two issues on OpenAI’s official Codex GitHub repo (#41340, #9830). Config keys checked Oct 30, 2026 in OpenAI’s Codex configuration reference. Usage-limit wording checked Oct 26, 2026 on Codex pricing. Every source is listed at the bottom. No affiliate links on this page (how we work).
The exact error: stream disconnected before completion
The full message most people are searching for:
stream disconnected before completion: stream closed before response.completed
Source: openai/codex issue #41340, verified Oct 30, 2026. It has a sibling, from issue #9830 (verified Oct 30, 2026), that names the endpoint instead:
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)
The one-line answer (as of Oct 30, 2026): Codex opened a streaming connection to the model and it died before the model said “done”. On the standard OpenAI setup, OpenAI’s own maintainer points at your network (proxy, VPN, firewall) or, now and then, OpenAI’s servers. On a custom OpenAI-compatible provider, it’s an open bug report with no official fix yet.
So the first question is simple: are you signed in with ChatGPT or an OpenAI key on the default provider, or did you point Codex at your own model_providers entry? The fixes split right there.
What the message actually means
Codex talks to models over the Responses API as a stream. A healthy turn ends with an event called response.completed. If the stream closes or stalls before that event arrives, Codex retries, and if the retries run out, you get this error.
You can often see the retries before the failure. One report in #41340 shows log lines like stream disconnected - retrying sampling request (5/5 in 3.304s)... followed by the error. That “5/5” lines up with Codex’s documented default: stream_max_retries is the “Retry count for SSE streaming interruptions (default: 5)” (config reference, verified Oct 30, 2026). Five tries, five rakes to the face. Sideshow Bob would relate.
Cause 1: network, proxy, VPN or firewall
This is the common case on the default OpenAI provider. In #9830, an OpenAI contributor looked at the reporter’s logs and said: “this looks like a normal connectivity issue. Codex isn’t able to access the server endpoint. Double check your network connectivity and network configuration — especially if you’re using any proxies, VPNs, or firewalls.”
Codex is basically E.T. at this point: it knows where home is, it just can’t phone it.
Checks, in this order:
- Turn off the VPN or proxy and retry one turn. Corporate proxies and VPNs that inspect or buffer traffic are the usual suspects the maintainer named.
- Try a different network. One user in #9830 said switching from home Wi-Fi to a phone hotspot got Codex working again. That’s one person’s report, not an official fix, but it’s a two-minute test that tells you whether the problem is your network.
- Check status.openai.com. It isn’t always you. Later in the same issue, the same OpenAI contributor wrote: “We saw elevated errors in one of our clusters. We’ve rerouted traffic, so things should be back to normal now.” If lots of people hit the error at once, it’s probably on OpenAI’s side and waiting is the fix.
- Run
codex doctor. OpenAI’s CLI reference lists it as a stable command that will “Generate a diagnostic report for local installation, config, auth, runtime, Git, terminal, app-server, and thread inventory issues” (CLI reference, verified Oct 30, 2026). Attach that report if you open an issue. - Turn on a log. Setting
log_dir“enables the opt-in plaintext TUI log, codex-tui.log”. For one run:codex -c log_dir=./.codex-log(basic config, verified Oct 30, 2026). Look for the retry lines and what happened right before them.
Cause 2: a custom OpenAI-compatible provider
Issue #41340, which carries the exact error at the top of this page, is about this setup: a custom provider in config.toml with wire_api = "responses", failing in both the Codex CLI and the VS Code extension. The reporter says the same provider works fine with direct streamed calls outside Codex, including the response.completed event, and suspects Codex mishandles some valid stream patterns (for example, a turn that ends in a tool call with no final text message). A second user added the same error from Codex desktop on macOS on Oct 6, 2026.
As of Oct 30, 2026, the issue is open and has no reply from OpenAI. So there’s no official fix to quote. That’s frustrating if your team runs Codex through an internal gateway, and we’re not going to pretend otherwise. What the docs do let you check:
wire_apimust beresponses. The reference says “responses is the only supported value, and it is the default when omitted.” Since Codex supports only the Responses protocol, a provider that doesn’t implement Responses-style streaming can’t work, however the rest of the config looks.- The provider has to finish the stream properly. Codex waits for
response.completed. If your gateway or proxy cuts long streams or drops that final event, Codex reports a disconnect even when the model answered. - Retry and timeout headroom. Per provider you can set
stream_max_retries(default 5),stream_idle_timeout_ms(“Idle timeout for SSE streams in milliseconds (default: 300000)”) andrequest_max_retries(“Retry count for HTTP requests to the provider (default: 4)”). OpenAI’s advanced-config example setsstream_max_retries = 10(advanced config, verified Oct 30, 2026). More retries help a flaky link. They won’t help a provider that never sendsresponse.completed. - Using a proxy for OpenAI itself? Don’t build a custom provider. The docs say to set
openai_base_urlinstead, and “don’t create [model_providers.openai], because you can’t override built-in provider IDs.”
A minimal provider block with the documented keys looks like this:
[model_providers.custom]
name = "My provider"
base_url = "https://example.com/v1"
env_key = "PROVIDER_API_KEY"
wire_api = "responses"
stream_max_retries = 10
stream_idle_timeout_ms = 300000
If none of that helps, add your codex doctor report and log lines to #41340 rather than opening a duplicate.
Is it a usage limit?
No. This is a connection error, not a quota message. Codex limits run on a five-hour window, with weekly limits that “may also apply”, and you can check what’s left with /status in an active CLI session (Codex pricing, verified Oct 26, 2026). If you’re out of usage, Codex tells you that in different words. The limit side of things is in Codex usage limits.
Does a failed turn still count against your usage or credits? OpenAI doesn’t say. We checked the pricing page and the issues, and it isn’t published, so we won’t guess.
Symptom, cause, fix
| Symptom | Likely cause | Fix |
|---|---|---|
| Fails on VPN | Network/proxy | Disable, retry |
| Many users at once | OpenAI side | Check status |
| Works on hotspot | Local network | Fix firewall |
| Custom provider | Stream handling | Check config |
| Retries 5/5 | Flaky stream | Raise retries |
Sources: #9830 and #41340 on OpenAI’s Codex repo, Codex config reference, all verified Oct 30, 2026. Raising retries is a documented setting, not a guaranteed fix.
Here’s what I’d do
On the default OpenAI setup: check the status page, kill the VPN, retry one turn. If it works on a hotspot and not at the office, send the firewall team the endpoint from the second error string and go get coffee.
On a custom provider: confirm wire_api = "responses", bump stream_max_retries, and make sure nothing between Codex and the model is cutting long streams. If it still fails, it’s likely the open bug, and your best move is a good report on #41340.
Shopping for something less fragile instead? Codex vs Claude Code and Codex alternatives compare the options, Codex pricing and Is Codex free? cover the plans, and AI coding tools compared puts everything side by side.
Running Codex from a script or CI job? Codex CLI “stdin is not a terminal” explains when to use codex exec instead.
If Codex fails before a reply even starts, the Codex “Error submitting message” fix covers the thread-not-found and project-root versions.
Seeing turn/start failed in TUI instead? The Codex turn/start failed fix covers that agent-loop error.
Stream dropped mid-reply is different from “Error loading messages” on a second client — Codex Error Loading Messages.
“Error in message stream” in the reports we found is a ChatGPT web banner, not the Codex CLI stream-disconnected error: ChatGPT error in message stream.
FAQ
What does “stream disconnected before completion” mean in Codex? The streaming connection to the model closed before the final response.completed event arrived, so Codex retried and then gave up.
How do I fix Codex stream disconnected? Disable VPNs and proxies, try another network, check status.openai.com, and on custom providers confirm wire_api = “responses” and raise stream_max_retries.
Why does Codex say “stream closed before response.completed” with a custom provider? It’s an open issue (#41340) with no official fix as of Oct 30, 2026; the provider must stream through to response.completed.
Is Codex down? Check status.openai.com; OpenAI has confirmed cluster-level errors behind this message before, but a single failure is usually your network.
Does a disconnected turn use my Codex credits? OpenAI doesn’t publish whether failed turns count against usage or credits.
What is stream_max_retries in Codex? A per-provider setting for the retry count on SSE streaming interruptions; the default is 5.
Sources
- OpenAI Codex GitHub, issue #41340 (exact error string, custom Responses provider, open): https://github.com/openai/codex/issues/41340 (verified 2026-10-30)
- OpenAI Codex GitHub, issue #9830 (endpoint variant, OpenAI contributor on network causes and cluster errors): https://github.com/openai/codex/issues/9830 (verified 2026-10-30)
- OpenAI Codex configuration reference (stream_max_retries, stream_idle_timeout_ms, request_max_retries, wire_api): https://developers.openai.com/codex/config-reference (verified 2026-10-30)
- OpenAI Codex advanced configuration (provider example, openai_base_url): https://developers.openai.com/codex/config-advanced (verified 2026-10-30)
- OpenAI Codex basic configuration (log_dir, codex-tui.log): https://developers.openai.com/codex/config-basic (verified 2026-10-30)
- OpenAI Codex CLI reference (codex doctor): https://developers.openai.com/codex/cli/reference (verified 2026-10-30)
- OpenAI status page: https://status.openai.com (checked 2026-10-30)
- OpenAI Codex pricing (five-hour and weekly limits, /status): https://developers.openai.com/codex/pricing (verified 2026-10-26)