Repository navigation
macOS Codex App: one existing chat repeatedly fails with stream disconnected while other chats work #53249
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.1007.30912
What subscription do you have?
ChatGPT Pro
What platform is your computer?
macOS 26.5.1; uname -mprs: Darwin 25.5.0 arm64 arm
What issue are you seeing?
One long-running local Codex App chat repeatedly fails with:
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.
Several consecutive turns in that chat failed, including very short follow-up messages. The chat history remains readable, but subsequent turns do not complete reliably. Other Codex chats on the same app and network continue to work.
What steps can reproduce the bug?
This was observed in one existing long-running chat; I do not have a deterministic public reproducer.
- Open the affected local chat in the macOS Codex App.
- Send a short follow-up message.
- The turn starts, then fails with the error above.
- Repeat with another short message in the same chat; it fails again.
- Send a message in another Codex chat on the same machine and network; that chat works.
The failures were observed repeatedly on 2026-10-12 around 10:27–10:49 China Standard Time (UTC+8). No network-switch test has been performed.
What is the expected behavior?
The affected chat should complete a new turn normally. If its persisted state is damaged or a stream fails, the app should offer a recoverable retry or resume path without losing the chat history.
Additional information
The thread identifier and request IDs were supplied privately to OpenAI through the Help Center support chat. They, along with conversation content, local logs, file paths, and business information, are omitted from this public issue. Please provide a secure channel if maintainers need narrower diagnostics.
Related reports show similar error text, but the key distinction here is that repeated failures are isolated to one existing chat while other chats continue to work.
Activity
github-actions commentedon Oct 12, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
kimihiro64 commentedon Oct 12, 2026
01a128be-765a-7812-916c-2f38e8586479 same issue, on Windows. it started about 24 hours ago, maybe a bit earlier, around the time the usage limits had reset
lok347 commentedon Oct 13, 2026
Additional independent macOS report from October 12–13, 2026, with locally verified timestamps.
Environment
sw_vers.Observed failures
Read-only inspection of persisted turn history confirmed six turns with terminal status
failed, all in one existing long-running local conversation, between October 12 00:00 and October 13 10:33:57 (UTC+8).Failure completion times (UTC+8):
The final error on these turns was:
stream disconnected before completion: An error occurred while processing your request.The October 13 turn began at 08:57:02. Its logs show:
falling back to HTTP.A later turn in the same conversation was marked
completedat 10:28:10, so the failure is intermittent. Retry log entries are not counted as separate failed turns.Network qualification
This machine uses a local HTTP proxy. A separate incident at 10:07:46–10:08:06 on October 13 produced 14 desktop
ERR_TUNNEL_CONNECTION_FAILEDrequest events and TLS/MCP connection errors. That occurred after the 09:23:32 terminal failure; it is not evidence that the proxy caused every failed turn. Short proxied HTTPS probes during the original morning investigation completed TLS and returned HTTP responses; those probes were not repeated for this follow-up and do not establish authenticated model-stream stability.Requested investigation
Please investigate the service-capacity/upstream-error responses and session retry/resume handling, including why HTTP fallback still ended in failure. A useful recovery path should preserve the recorded work and clearly identify which part of a turn can be continued.
Similar error wording is also reported in #52919 and #53167; a common root cause has not been established.
Request IDs, turn/thread identifiers, conversation content, local paths, and raw logs are retained privately and can be provided through a secure OpenAI support channel. This comment contains only the sanitized technical summary.
Follow-up: October 13, 2026 (UTC+8)
Two additional terminal failures have now been verified in the same existing conversation:
The total is now eight verified failed turns on October 12–13. These were the two consecutive turns after the 10:28:10 completed turn, with no intervening completed turn in that conversation. The earlier success therefore does not establish sustained recovery.
Both new request IDs have been matched to persisted failed-turn records and retained in the private support draft. Please correlate the capacity-error responses and HTTP fallback with the conversation's retry/resume state. The precise backend cause remains unconfirmed.
User impact and subscription risk
The repeated disconnections now prevent me from using Codex reliably for my work. This is materially increasing the likelihood that I will cancel my subscription. Please treat this as a service-usability issue and provide an effective recovery path.
Explicit model-capacity failures: October 13, 2026 (UTC+8)
Two more turns in the same conversation failed at 15:34:15 and 15:34:24. Both returned:
Selected model is at capacity. Please try a different model.Their persisted error classification is
serverOverloaded. Per-turn log metadata confirmsgpt-6.1-solwith reasoning effortmaxfor both attempts. These failures occurred approximately 9 and 7 seconds after the turns began.The verified total is now ten failed turns since October 12: eight earlier stream-disconnection/processing-error failures and these two explicit capacity failures. No alternate-effort/model comparison has established whether the capacity issue is specific to
max; the same cause is not established for every earlier failure. Please investigate model/effort capacity availability and provide an effective way to continue work.gomoorae commentedon Oct 13, 2026
Additional macOS evidence on the same app version, with an important difference: failures have occurred in at least two different local chats, so this is not confined to one existing chat in my case. Similar symptoms do not establish a shared root cause.
Environment verified on October 13, 2026:
Observed failures:
stream disconnected before completion: An error occurred while processing your request.and a server request ID. Accessible failure records had no additional diagnostic details.Observed workflow, not a deterministic minimal reproducer:
Please investigate recurring response-stream failures across chats and advise an effective mitigation or fix. Graceful reconnection and a reliable resume path are needed; repeated multi-minute attempts are making this workflow difficult to use.
Both server request IDs, exact UTC timestamps, and failed-turn identifiers were supplied privately through the OpenAI Help Center support chat, which directed the bug report to this tracker. Please provide a secure channel if narrower diagnostics are needed. Public conversation identifiers, email, manuscript contents, raw logs, credentials, and personal paths are omitted. We have not established context exhaustion, a network fault, or a specific upstream service cause.