Codex

Codex: "stream disconnected before completion: ..."

Last checked

The error

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)
stream disconnected before completion: stream closed before response.completed
stream disconnected before completion: websocket closed by server before response.completed
stream disconnected before completion: idle timeout waiting for SSE
stream disconnected before completion: An error occurred while processing your request.

Codex CLI, the IDE extension and the app all print this after the retries shown as "Reconnecting... 1/5" through 5/5 run out.

Codex prints this when the response stream breaks after the request was accepted but before the server sent response.completed. The text after the colon is the real cause: a network or TLS failure, a proxy closing the stream, an idle timeout, or a server-side error. Codex already retried five times. Read the suffix, run codex doctor, and fix proxy or CA settings before retrying.

Why it happens

In the Codex source this is one error type with a free-text reason appended. Codex treats it as transient, retries the stream (5 times by default, falling back from WebSockets to HTTPS), and only shows the error when every retry fails.

  1. A proxy, VPN or TLS-inspecting security tool cuts or rewrites the long-lived stream. One forum thread resolved after disabling Zscaler, and the codex doctor report in issue #24511 shows "invalid peer certificate: BadSignature", which is what TLS interception looks like.
  2. WSL networking. Issue #24511 (open, no maintainer fix yet) reports every request failing in WSL on Codex CLI 0.129.0 and later with "error sending request for url", while 0.128.0 and native Windows work with the same Enterprise account.
  3. A server-side failure inside the stream. Issue #24747 (open) on 0.134.0 shows the suffix "An error occurred while processing your request." with a request id. That one is not your network.
  4. A custom provider that does not emit response.completed the way Codex expects. Issue #41340 (open, CLI 0.148.0 and the VS Code extension) reports "stream closed before response.completed" against an OpenAI-compatible Responses endpoint.
  5. A stream that goes quiet for longer than the idle timeout (300,000 ms by default) during a very long turn or on a large context.

The fix

  1. 1 Read the suffix after the colon. "An error occurred while processing your request" is server-side: check status.openai.com and retry later with the request id handy.
  2. 2 Run codex doctor. It checks auth, config and WebSocket reachability and names TLS, proxy and DNS problems.
  3. 3 Behind a corporate proxy, export HTTPS_PROXY and NO_PROXY in the same shell that starts Codex. Inside WSL these are not inherited from Windows.
  4. 4 If your network inspects TLS, point CODEX_CA_CERTIFICATE (or SSL_CERT_FILE) at a PEM bundle containing your company's root CA. WSL does not use the Windows certificate store.
  5. 5 For a custom provider, raise stream_max_retries or stream_idle_timeout_ms in its [model_providers.<id>] block, or set supports_websockets = false. These keys do not apply to the built-in OpenAI provider.
  6. 6 Update Codex, and if a WSL regression blocks you, test the same prompt from native Windows to confirm it is WSL-specific.
codex doctor

Hermes and OpenClaw running on Codex auth

Agents that sign in with a ChatGPT account route through the same chatgpt.com Codex backend, so they surface the same string. OpenClaw issue #117366 showed the error mislabelled as "unknown" in model-fallback notices. PR #118130 now classifies it as a timeout, so fallback treats it as transient.

OpenClaw 2026.9.4 and 9.5 with proxy.enabled set to true sent local Codex loopback traffic through the external proxy, producing this error plus 502s (issue #153930). The workaround was proxy.enabled false with HTTP_PROXY, HTTPS_PROXY and NO_PROXY=127.0.0.1,localhost,::1. PR #154013 (merged 21 Sep 2026) keeps loopback direct.

In Hermes, issue #121299 (open) reports that the codex_app_server runtime can print a partial answer and hide this failure, so check the exit code and logs when a reply looks cut short.

Still failing?

  • Run Codex with RUST_LOG=debug and read codex-tui.log for the underlying connection error.
  • Remove stale OPENAI_BASE_URL or openai_base_url settings that point at an old local gateway, since they reroute the built-in provider.
  • Check whether a second Codex install or extension on the same machine is the one actually running.

Related errors

Hit a different error?

Paste any agent error and get the cause and fix in seconds.

Open the decoder

Frequently asked questions

Is my turn lost when this happens?

The failed turn stops, but the session and earlier work remain. Resume and send the request again, ideally split into smaller steps if it keeps failing late in long turns.

Why does it say Reconnecting before failing?

Codex retries a dropped stream up to five times by default, and on WebSockets it falls back to HTTPS before giving up. The error appears only after those attempts fail.

Does switching to an API key fix it?

Only if the problem is specific to the ChatGPT backend. Network, proxy and TLS causes affect API-key traffic too.

Stop firefighting agent errors

Decoding errors one at a time is the manual version of what BetterClaw automates. Run your agents on a no-code AI agent platform with managed models, retries and config validation built in.

Deploy Your Agent — Start FreeBook a Demo

Free plan available · Pro $49/mo · BYOK · 7-day money-back guarantee