Repository navigation
Codex desktop thread history is not persisted and task remains permanently in progress #41864
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.825.51511
What subscription do you have?
Pro
What platform is your computer?
macOS Tahoe 26.5.1 - Darwin 25.5.0 arm64 arm
What issue are you seeing?
Summary
A Codex desktop task appears to lose its conversation history after the initial user prompt and first assistant response. A background task remains marked as inProgress, while subsequent conversation and work are not visible when viewing the thread.
A previous task exhibited the same behavior, and the current thread appears affected as well.
The UI also shows:
You stopped after 0s
The background task may remain permanently marked as inProgress, despite no longer being active. This creates a mismatch between the visible conversation, task status, and any work performed through external tools or durable coordination systems.
Impact
- Conversation context is lost from the user-facing thread.
- The task cannot be reliably resumed from the UI.
- Task status becomes misleading or permanently stuck.
- Long-running agent workflows may continue or make progress without that history being visible.
- Users may need to recover context from external logs, handoffs, or project state.
Evidence
Attached screenshot showing the initial prompt, the first assistant response, and the You stopped after 0s state.
Additional observations
A prior Codex task in the same workflow displayed similar behavior: its original turn remained permanently inProgress, while later conversation was not persisted.
### What steps can reproduce the bug?
1. Start a Codex desktop task
2. Reopen or inspect the thread from the desktop application.
### What is the expected behavior?
## Expected behavior
The complete conversation should remain visible and the thread status should accurately reflect whether a task is running, stopped, completed, or failed.
## Actual behavior
Only the initial user prompt and the first assistant response are visible. Later conversation turns are missing from the thread.
### Additional information
https://github.com/user-attachments/assets/f23dbbed-71de-4593-9d23-20112eb37f2b
Activity
github-actions commentedon Aug 31, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
christolph commentedon Sep 6, 2026
Additional confirmed occurrence on macOS 26.5.1 arm64, Codex Desktop 26.901.41600 (build 7982), bundled codex-cli 0.153.4, ChatGPT Pro.
Two consecutive local tasks displayed the same
You stopped after 0s/ missing-reply behavior. In the affected rollout, the backend persisted an assistantresponse_item(606 characters) followed bytask_complete. The task API also reported the turncompleted, but returned zero visible response items. On resume, the desktop log recorded:The hidden
avatarOverlayrenderer started subsequent turns and issuedturn/interruptrequests that failed withno active turn to interrupt, even though the primary renderer continued presenting the task as streaming/stopped.The first occurrence followed an Astra pre-turn compaction at 244,770 / 244,800 tokens where the remote-compaction WebSocket reset without a closing handshake. However, the false streaming/missing-output state recurred after a successful compaction reduced the context to about 46k tokens, so the persistent symptom appears to be frontend/overlay reconciliation rather than an active model request. Switching models inside the affected task did not repair the UI. The saved replies and tool results remained intact in the local rollout.
Expected:
task_completeclears streaming state and the stored assistant message is rendered. Actual: the main renderer remainsmarkedStreaming=true, displaysYou stopped after 0s, and hides the completed reply. Full app restart/new task is the only confirmed recovery so far. Raw logs and rollout are not attached because they contain private project content.