Desktop: recurring long-running chats become inaccessible after stream/429 errors #54014

What issue are you seeing?

This keeps happening, and it has been happening for a long time: when I give the desktop app a substantial, multi-step task and work with it for an extended period, the ChatGPT-backed conversation can get stuck showing “working” and eventually become inaccessible.

The latest incident happened on October 14, 2026, after spending the morning working on a 3D racing game. The conversation kept appearing active for a long time without a usable status update. Opening it then showed:

No se ha podido cargar esta conversación de ChatGPT
Intentarlo de nuevo

This makes the product feel unreliable for serious, sustained work. A user should be able to give it an ambitious task without losing access to the conversation or having to guess whether anything is still running.

Confirmed observations from this incident

• The desktop chat list continued to mark the affected ChatGPT conversation as active.
• App logs recorded failed response-stream recovery with Resume stream unavailable and HTTP 404.
• Repeated requests to read the affected conversation returned HTTP 429 / Too many requests.
• The repeated 429 responses persisted across more than two hours in the inspected logs.
• A separate attempt to read the conversation through the desktop chat tools also returned Too many requests.
• The visible UI error prevented accessing the conversation's Stop control.

These observations establish a stream-recovery/conversation-loading failure. They do not establish whether the underlying task continued, how much work was saved, or whether any work was permanently lost.

Reproduction context

Observed workflow, rather than a deterministic minimal reproduction:

1. Work in a ChatGPT-backed conversation in the desktop app.
2. Give it an ambitious, multi-step development task and continue working in the same conversation.
3. Observe a prolonged “working” state.
4. Reopen the conversation.
5. The conversation can no longer load, while the list still marks it as active.

The recurrence and association with longer tasks are my reported experience; the exact trigger and root cause have not been established.

Expected behavior

• Preserve and reload the conversation and saved task progress after a stream disconnect.
• Show a reliable running, stopped, completed, or failed state.
• Keep cancellation and recovery available even if the transcript fails to load.
• Handle repeated HTTP 429 responses with an effective recovery/backoff strategy.
• Allow the user to resume from saved progress without rebuilding the conversation.

Splitting work into smaller tasks or starting a new conversation is a workaround, not a solution to reliability during long-running work.

Environment

• macOS desktop app.
• Desktop release shown in the inspected logs: 26.1007.71326.
• Affected surface: a ChatGPT-backed conversation, rather than a standalone Codex thread.

Related reports

These reports describe related stream-recovery symptoms; a shared root cause is not assumed:

• I test the webchat but some how it just randomly die, from "Resume stream unavailable" to " A network error occurred. Please check your connection and try again." #47711
• Deep Research repeatedly fails mid-report with “Resume stream unavailable” and cannot recover final output #43630

This report contains sanitized observations only. No private conversation contents, account identifiers, conversation IDs, or raw logs are attached.