Codex Desktop on macOS gets stuck reconnecting because failed/completed turns are restored with markedStreaming=true

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

26.422.30944

What subscription do you have?

Free

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

The Codex Desktop app on macOS gets stuck showing reconnecting/connecting/compressing context for a conversation even after the latest turn is already failed or completed in the local rollout. In the desktop logs, thread resume repeatedly shows latestTurnStatus=failed or completed but markedStreaming=true for the restored conversation. The affected conversation is 019da98a-89e3-7df3-abc3-1b044f3f0872. The issue is not isolated to one conversation; another unrelated conversation also showed latestTurnStatus=completed with markedStreaming=true. The app UI then keeps behaving as if the conversation is still streaming. We also saw repeated internal_server_error/high demand events mixed in, but the persistent reconnecting behavior appears to be caused by desktop resume state recovery, not just temporary server failure.

What steps can reproduce the bug?

1. Launch Codex Desktop on macOS.
2. Open conversation 019da98a-89e3-7df3-abc3-1b044f3f0872.
3. Restart Codex Desktop.
4. Desktop restores the thread and calls thread/resume.
5. In desktop logs, maybe_resume_success shows latestTurnStatus=failed or completed but markedStreaming=true.
6. The UI then continues showing reconnecting/connecting/compressing context instead of settling to an ended state.
7. Sending another user message may start a new turn, but the UI can still get stuck again.

Relevant observed logs included entries like:

• maybe_resume_success conversationId=019da98a-89e3-7df3-abc3-1b044f3f0872 latestTurnStatus=failed markedStreaming=true
• another unrelated conversation also restored with latestTurnStatus=completed markedStreaming=true

Additional detail:

• This same conversation can be resumed successfully from CLI with:

/Applications/Codex.app/Contents/Resources/codex resume 019da98a-89e3-7df3-abc3-1b044f3f0872 --no-alt-screen -C /Users/wangyaok2/Desktop -m gpt-5.4

• That suggests the issue is in Desktop resume/renderer state recovery rather than the underlying conversation data alone.

What is the expected behavior?

After a conversation is restored, the Desktop app should recognize that the latest turn is already ended when latestTurnStatus is failed/completed/interrupted. The UI should stop showing reconnecting/connecting/compressing context and allow normal continued use of the thread without getting stuck in a pseudo-streaming state.

Additional information

Conversation ID involved: 019da98a-89e3-7df3-abc3-1b044f3f0872

Relevant desktop log example:

• codex-desktop-3a3d2458-33c3-4932-a68a-1a95e7d78212-40838-t0-i1-105920-0.log

Example observed resume line:

• maybe_resume_success conversationId=019da98a-89e3-7df3-abc3-1b044f3f0872 latestTurnId=019dc96e-2694-7ef3-92ce-942881563126 latestTurnStatus=failed markedStreaming=true

I also observed another unrelated conversation restore with latestTurnStatus=completed and markedStreaming=true, which suggests this is not limited to a single corrupted conversation.

Short-term workaround confirmed:

• Resume the same conversation from CLI instead of the Desktop UI:

/Applications/Codex.app/Contents/Resources/codex resume 019da98a-89e3-7df3-abc3-1b044f3f0872 --no-alt-screen -C /Users/wangyaok2/Desktop -m gpt-5.4