Potential data loss: Conversation becomes inaccessible after WebSocket timeout; recovery returns HTTP 500 “Can’t load conversation”

Environment

• Application: ChatGPT/Codex Desktop
• Subscription: Plus
• Version: 26.715.72359
• macOS: 26.5.2 (25F84)
• Hardware: MacBook Air M2, 16 GB RAM
• Architecture: arm64 - Darwin 25.5.0 arm64 arm
• Time zone: Africa/Johannesburg (UTC+2)

Description

During ordinary use of the ChatGPT/Codex macOS application, an active conversation stopped receiving streamed data. The application initiated its built-in completion-transport recovery process, but the recovery process could no longer retrieve the conversation.

The application then repeatedly received HTTP 500 responses stating:

Can’t load conversation [conversation ID]

For one affected conversation, the application made 32 consecutive recovery attempts over approximately 15 minutes. Every attempt failed with the same response.

A second conversation became inaccessible shortly afterwards. Four recovery attempts for that conversation also failed before I quit and relaunched the application.

This was not merely a visual or window-restoration problem. The application logs show that the conversation-retrieval endpoint itself failed to return the affected conversations.

Steps to reproduce

1. Open an existing conversation in ChatGPT/Codex Desktop.
2. Continue the conversation and wait for a streamed response.
3. The response stream stops delivering data and times out.
4. The application initiates its completion-transport recovery process.
5. Recovery repeatedly requests the affected conversation.
6. The server responds with HTTP 500 and Can’t load conversation.
7. The conversation or incomplete response remains inaccessible.

I have experienced the problem repeatedly, although I cannot yet identify a completely deterministic trigger.

Actual result

At 20:47:40 SAST on 23 July 2026, the application logged:

chatgpt_completion_transport_recovery_started
error="ChatGPT websocket timed out waiting for stream data"

From 20:47:57 until 21:02:30 SAST, the application made 32 consecutive recovery attempts for the same conversation.

Every recovery attempt failed with:

status=500
detail="Can’t load conversation [redacted conversation ID]"

At 21:04:38 SAST, recovery started for another conversation. Four further recovery attempts failed with the same Can’t load conversation response before I quit the application at approximately 21:06.

The logs contain this error in relation to three distinct conversation IDs during that application session.

Expected result

A temporary streaming failure should not make the underlying conversation inaccessible.

The application should:

1. Resume the interrupted stream; or
2. Retrieve the last persisted conversation state successfully; or
3. Preserve and display the last confirmed conversation state with a clear explanation of what was and was not saved.

Recovery should stop with a clear user-facing error after a reasonable number of attempts rather than silently continuing to poll an endpoint that repeatedly returns HTTP 500.

Most importantly, a network or streaming interruption must not result in submitted or generated conversation content becoming inaccessible.

Comparison showing that recovery can work

Earlier on the same day, another WebSocket stream timed out at 12:43:06 SAST.

On that occasion, recovery completed successfully on the first attempt approximately 17 seconds later:

chatgpt_completion_transport_recovery_completed
attempt=1

The later incident differs because the conversation endpoint repeatedly returned HTTP 500 and Can’t load conversation, preventing recovery.

Additional connection instability

Across the supplied Codex Desktop logs, I also identified:

• 12 IPC socket errors reporting write EPIPE
• 18 IPC connection-reset broadcasts
• 33 pub-sub transport closures
• Repeated request timeouts and connection-closed errors

These events may be related to the loss of conversation availability, but I cannot establish causation from the logs alone.

Impact

This is a serious data-integrity and reliability issue.

Work submitted during an active conversation has become inaccessible after a stream interruption. The application provides no reliable indication whether the content:

• Has been permanently lost.
• Remains stored but temporarily inaccessible.
• Was only partially persisted.
• Can later be recovered.

The failure interrupts active work, creates uncertainty about whether material has been preserved and substantially undermines confidence in the desktop application.

Logs

Attached: sanitised_ChatGPT_20260723_21.46.log.txt

The redacted extract contains:

• An earlier timeout that recovered successfully;
• The later WebSocket timeout;
• The complete sequence of 32 failed recovery attempts;
• The second affected conversation and its failed recovery attempts;
• The application shutdown boundary.

I can provide the original unredacted log privately to an authorised maintainer if the full conversation IDs, request IDs or other correlation identifiers are required.