[macOS][ChatGPT Desktop] Ordinary Chat generation stops after WebSocket timeout and conversation-state desynchronization

What version of the Codex App are you using?

• Current ChatGPT Desktop version: 26.814.41407 (build 6720)
• Current bundled Codex CLI: 0.148.0-alpha.15
• Version at reproduction: 26.803.61601

What subscription do you have?

ChatGPT Plus.

What platform is your computer?

macOS 26.5.2 (25F84), Apple Silicon (arm64).

What issue are you seeing?

In ordinary Chat—not a Project or Work task—an active generation stops making progress and is interrupted automatically. The same behavior occurred in a new chat, so it was not limited to one long conversation.

The desktop logs for the incident show a WebSocket stream timeout followed by conversation-state errors:

ChatGPT websocket timed out waiting for stream data
Received turn/started for unknown conversation
HTTP 404 conversation_inaccessible

During the first reproduction on August 13, 2026, the application needed four recovery attempts before reporting recovery completion. Six unknown conversation events were recorded before the first feedback submission. There were no corresponding HTTP 429, 500, or 503 responses in this incident window.

A second WebSocket timeout occurred at 2026-08-13 13:41:49 CEST after two feedback submissions. Recovery completed on attempt 1 approximately one second later, but the task had already stopped progressing from the user's perspective.

This appears to be a synchronization problem between the active streamed response and the conversation state. Even when transport recovery completes technically, the user-visible task can remain interrupted.

What steps can reproduce the bug?

The trigger is intermittent, but it reproduced in more than one ordinary Chat:

1. Open ChatGPT Desktop on macOS.
2. Start a new ordinary Chat.
3. Send a task that produces a streamed response.
4. While the response is running, the stream stops delivering data.
5. The task shows no further progress or ends unexpectedly.
6. The desktop logs record a WebSocket timeout, recovery activity, and conversation-state errors.

What is the expected behavior?

A temporary stream interruption should not stop the task or make the conversation temporarily inaccessible. The application should resume the response from the last persisted state, or show a clear recoverable error while preserving the task and conversation.

Incoming turn events should not be handled as belonging to an unknown conversation after the conversation has already been created and displayed.

Additional information

Related feedback session IDs accepted by the application:

• no-active-thread-019ffaea-94f1-7372-9529-9be3be63b1a5
• no-active-thread-019ffaec-8d27-7e33-86b7-1fb197df0e62
• no-active-thread-019ffaf0-d3a8-76a1-8566-bf65593497a0

Related existing reports:

• #34999 reports conversation inaccessibility after a WebSocket timeout, but with persistent HTTP 500 failures. This reproduction differs because it produced HTTP 404 conversation_inaccessible and recovery later completed.
• #21167 reports reconnect loops associated with turn/started for unknown conversation. This reproduction adds an ordinary-Chat incident with a WebSocket timeout and a temporary server-side 404 response.

No chat content, conversation IDs, request IDs, local paths, account data, or full logs are included. Sanitized log excerpts can be provided if a maintainer requests them.

No source file, test, or entry point is identified. Start by reviewing the sanitized WebSocket timeout and conversation-state logs alongside reports #34999 and #21167; done means reproducing the interruption and ensuring the conversation resumes or presents a clear recoverable error without unknown-conversation failures.