Stream disconnected before completion

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #9635

Powered by Codex Action

Adding another datapoint here, backend-api is down. Thread ID: 019c5415-cff1-7f73-a50f-e800a863614e

Backend-API is down for the last 18+ minutes. gpt-5.3-codex xhigh and gpt-5.3-codex-spark high, all requests. Failover to HTTPS doesn't work. p0 unbreak now. Thanks guys codex is awesome and so is your reliability.

⚠ Falling back from WebSockets to HTTPS transport. stream disconnected before completion: received
fatal alert: HandshakeFailure

◦ Reconnecting... 3/5 (27s • esc to interrupt)
└ Stream disconnected before completion: error sending request for url (https://chatgpt.com/
backend-api/codex/responses)

codex CLI is down too.

Error sending request for url (https://chatgpt.com/backend-api/codex/responses)

it's back

Yes, I've had this issue forever — never fully solved;
Feedback code: 019cba07-dd71-7053-b509-fe6fea071f2e

same error, need new session to solve...

■ stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/
responses)
I started getting this at my office on Wednesday evening March 4, 2026 and regularly receiving them at my home since then Wednesday through Friday March 6, 2026.
<img width="640" height="1080" alt="Image" src="https://github.com/user-attachments/assets/1495702d-d889-472a-9719-12e1f4691a98" />

Well, I see it works pretty well for my Enterprise subscription, but for regular Plus, they simply don't care too much :)

been having this exact issue for a few weeks

Adding a reproducible July 18/19 datapoint related to #11743. This appears to be more specific than a general outage or a CLI-version regression.

Isolation matrix

Using the same ChatGPT account and model family:

| Environment | Client | Result |
|---|---|---|
| macOS, residential egress | codex-cli 0.145.0-alpha.18 | succeeds in ~7s |
| macOS, residential egress | exact @openai/codex@0.144.3 | succeeds in ~9s |
| Linux VPS, US West datacenter egress | exact @openai/codex@0.144.3 | fails after ~35–39s, zero tokens |
| Linux VPS, US East datacenter egress | same account/client/model | fails identically |
| Linux VPS, direct OpenAI API | Responses API | succeeds |

The VPS failure is consistently:

stream disconnected before completion: error sending request for url
(https://chatgpt.com/backend-api/codex/responses)

OAuth resolution and usage/rate-limit reads remain healthy. No model output is produced. Changing VPS region does not help; moving the same client version and account to residential egress does. That strongly isolates this to the authenticated ChatGPT Codex streaming path plus egress class/ASN, rather than quota, model availability, the CLI release, TLS generally, or ordinary outbound connectivity.

An unauthenticated curl returning 401 is not sufficient to test this: the failure happens later on the authenticated streaming response.

Working mitigation for app-server integrations

This is a workaround, not a backend fix. Run Codex app-server on a trusted non-datacenter host and expose it only through a private reverse tunnel:

# Trusted host; keep the listener on loopback.
codex app-server \
  --listen ws://127.0.0.1:8765 \
  --ws-auth capability-token \
  --ws-token-file /absolute/path/to/token

# From the trusted host, create a loopback-only reverse forward on the VPS.
ssh -N -T \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=15 \
  -o ServerAliveCountMax=3 \
  -R 127.0.0.1:8766:127.0.0.1:8765 \
  user@vps

The app-server client on the VPS connects to ws://127.0.0.1:8766 and sends the capability token as Authorization: Bearer .... Both endpoints stay loopback-only; SSH owns the encrypted cross-host hop. Supervise the app-server and tunnel (systemd/launchd) so they reconnect after host or container replacement.

After moving only this transport boundary, repeated GPT-5.6 family calls completed with HTTP 200 and normal token usage. Returning to VPS-originated ChatGPT streaming reproduced the original zero-token disconnect.

For CLI-only usage, the equivalent mitigation is to run the CLI on the trusted host over SSH; the CLI itself does not automatically become a remote app-server client.

Questions for maintainers

1. Is ChatGPT OAuth-backed Codex inference intended to work from common VPS/datacenter ASNs?
2. If datacenter egress is intentionally restricted, can the backend return an actionable status/error instead of a generic stream disconnect?
3. If it is supported, which trace fields or /feedback artifacts would best distinguish an egress-policy rejection from an HTTP/WebSocket transport failure?

I can provide sanitized timestamps and feedback/thread IDs from a fresh reproduction if that would help.

Follow-up with a completed GCP reproduction and mitigation validation (related to #11743):

• A private Compute Engine VM in us-west1, using ChatGPT OAuth and @openai/codex@0.144.3, reproduced the same zero-token disconnect after ~40.5 seconds against https://chatgpt.com/backend-api/codex/responses.
• OAuth status and subscription usage reads were healthy, and an unauthenticated POST to that endpoint returned 401 in ~140 ms. This confirms that ordinary DNS/TLS/reachability checks do not exercise the failing authenticated stream.
• The same account and GPT-5.6 model family succeeded from macOS residential egress.
• Pinning @openai/codex@0.144.6 on that trusted macOS host, running codex app-server on 127.0.0.1 with capability-token WebSocket auth, and carrying only that loopback transport through a supervised IAP/SSH reverse forward fixed the integration. Repeated end-to-end calls through the cloud gateway completed in ~8–12.5 seconds with normal token usage.

Security properties of the mitigation: both WebSocket endpoints remain loopback-only; SSH/IAP owns encryption and reconnection; the capability token is distinct from OAuth; the OAuth credential never crosses the WebSocket/tunnel boundary; the cloud client is configured read-only and fails closed when the bridge is absent.

This remains a workaround, not a backend fix. The clean egress-class isolation still suggests either an authenticated-stream policy/reputation decision for datacenter ASNs or a backend path that does not return its intended error status to the client. An actionable backend response instead of the generic stream disconnect would make this much easier to operate and diagnose.