`stream disconnected before completion` is account-scoped — switching ChatGPT accounts changes the failure rate ~7×

What version of the Codex App are you using (From "About Codex" dialog)?

26.908.70816 (Codex core client_version=0.154.0)

What subscription do you have?

Pro (x-codex-plan-type: pro, x-codex-active-limit: premium)

What platform are you computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Repeated stream disconnected before completion errors, always after an HTTP 200 OK has already been returned:

stream disconnected before completion: An error occurred while processing your request.
You can retry your request, or contact us through our help center at help.openai.com if the
error persists. Please include the request ID <id> in your message.

The failure rate is account-scoped. On the same machine, same network, same proxy, same app version and same models, the failure rate follows the ChatGPT account and not the environment:

Account	Stream disconnects	Successful output items	Failure rate
A (first period)	98	2,258	4.34%
B (second period)	92	5,652	1.63%
A (after switching back)	51	431	11.83%

After switching back to account A the failure rate was roughly 7x that of account B.

What steps can reproduce the bug?

1. Use account A continuously → stream disconnected before completion occurs regularly.
2. Switch to account B. Nothing else changes (same machine, network, proxy, app version, model). → failure rate drops substantially.
3. Switch back to account A. → failures reproduce immediately.

The symptom follows the account, not the environment.

Account fingerprints (independent confirmation of the switch): the response header x-codex-primary-reset-at (the end of the 7-day billing window) acts as an account fingerprint:

• Account A (before switch): 1789805617
• Account A (after switching back): 1789805589 — within 28 seconds of the above
• Account B: 1789950507 — about 40 hours apart from A

A's two periods share the same window boundary; B differs.

Sample request IDs (server-side identifiers — they carry the exact server-side timestamps, which is the most reliable way to correlate):

• d43273fb-c928-4de6-9d2d-298b31939330
• 237a7c72-3547-4870-bb26-e44b88f55c6b
• e5552916-802a-45c7-a2c2-dcf282a737f5

The same 25-second window also produced request IDs 16e0017d, cc99d4ce, 99b85aed, c6d3ffc9, b7f6f277, 480812a1, 6196de1e, 44e36eb7, 41bb1583.

What is the expected behavior?

The SSE stream should run to completion, or a retryable error should be surfaced that does not require the user to identify which account is affected.

Additional information

The HTTP request itself succeeds. From the client log:

Request completed method=POST
  url=https://chatgpt.com/backend-api/codex/responses
  status=200 OK
  server=cloudflare
  cf-ray: a3bf5c40bd9d8a80-LAX

200 OK means DNS, proxy, TLS, auth and the request-body upload all succeeded. The stream then breaks after it has started. The error text is generated server-side (it carries an OpenAI request ID and points at help.openai.com).

Scale: 752 occurrences over 10 consecutive days (2026-09-06 to 2026-09-16), across 111 distinct threads.

It is neither model-specific nor effort-specific:

Model	Count
gpt-5.6-sol	281
gpt-6-astra	271
gpt-5.6-luna	172
gpt-5.6-terra	15
gpt-5.4-mini	10

reasoning_effort	Count
high	268
medium	225
low	179

Ruled out — identical or inverted between the two accounts:

Factor	Account A	Account B
x-codex-plan-type	pro	pro
x-codex-active-limit	premium	premium
x-codex-credits-has-credits	False	False
x-codex-credits-balance	0	0
x-codex-primary-window-minutes	10080	10080
x-codex-secondary-used-percent	0	0
x-codex-primary-used-percent	33 / 53	57
Client feature flags	60 flags	identical, 0 differences

Note that usage percentage is not the cause: account B was more used (57%) and was markedly more stable. Client feature flags are byte-identical across both periods, so they are build-level rather than account-level.

Ruled out locally:

• Proxy (V2rayU / xray-core): 102,504 log lines mentioning OpenAI domains, 0 error lines; 25,566 dispatcher decisions, 100% routed through the proxy; 0 failures on the outbound node.
• Network: chatgpt.com requested 15 consecutive times, 15/15 succeeded, stable ~0.70 s; a 20 MB long-lived download completed at 1.48 MB/s.
• Version regression: #9677 (0.88 SOCKS → HTTP CONNECT regression) was fixed in 0.89.0; this client is 0.154.0.
• Not related to the custom-provider variant in #41989 — this is the official chatgpt.com/backend-api/codex/responses endpoint.

Request to maintainers: could you check the server-side state of the account whose x-codex-primary-reset-at is 1789805617?

1. Is it routed to a different backend shard / capacity pool than the account with x-codex-primary-reset-at = 1789950507?
2. Does it carry an account-level risk or degradation flag?
3. Is it enrolled in an account-scoped experiment affecting the /backend-api/codex/responses streaming path?

Methodology caveat (stated honestly): this is an observational comparison, not a randomized trial. The two periods carried different workloads (A's first period: 2,258 successes; B: 5,652) — B handled more load yet was more stable, which strengthens rather than weakens the conclusion. The final A period is short, so 11.83% should not be treated as a stable estimate. "Disconnects" counts include automatic retry attempts, so it is not exactly equal to failed conversation turns.

No repository file or test is identified in the report. Start by investigating the official chatgpt.com/backend-api/codex/responses SSE path and correlating the supplied request IDs with the account and server state. Done means identifying the account-scoped cause and ensuring the stream completes or exposes an appropriate retryable error.