Repository navigation
Codex Desktop Windows: orphan task_started without task_complete poisons thread reopen and crashes LocalConversationPage #23035
Description
What version of the Codex App are you using?
- Codex Desktop release shown in local logs:
26.513.31313 - Thread metadata
cli_version:0.131.0-alpha.9
What subscription do you have?
Not included in this public report.
What platform is your computer?
Windows x64. Codex Desktop from the Microsoft Store package family OpenAI.Codex_2p2nqsd0c76g0. Workspace shell was PowerShell.
What issue are you seeing?
A local Codex Desktop conversation entered a persistent error state after an interrupted turn. Reopening the same conversation showed the generic error page:
糟糕,出错了
Clicking retry / reopening the session continued to show the same error.
This looks like a Codex Desktop session recovery bug rather than project-code corruption: the rollout JSONL was valid JSONL, but one turn had task_started without a matching task_complete. When the app reopened, renderer/app logs showed stale stream events arriving for a conversation that no longer had matching in-memory state.
Steps that led to the issue
- Start a normal Codex Desktop conversation on Windows.
- During an active turn, interrupt/accidentally switch or restart the interaction.
- Continue in the same conversation, creating a later turn that does complete successfully.
- Reopen the affected historical conversation from the sidebar/history.
- The LocalConversationPage displays the generic error page and retry does not recover it.
Local diagnostic evidence
Affected local conversation id, sanitized only by context omission:
019e3109-9a55-7d33-8c4a-a0cf134a9240
Rollout file path shape:
%USERPROFILE%\.codex\sessions\2026\05\16\rollout-2026-05-16T21-46-13-019e3109-9a55-7d33-8c4a-a0cf134a9240.jsonl
The rollout file parsed cleanly:
lines=1709 bad=0
But task lifecycle events were unbalanced before manual repair:
TurnId StartedLine CompletedLine
019e3109-9aed-7463-a025-3eb421355863 2 36
019e3112-07b4-72d0-ac6e-c22e4e792dd2 38 <missing>
019e3113-f7a7-7902-b10e-038972a045a3 99 1709
Relevant Codex Desktop logs around reopening/resume:
response_routed ... method=turn/start ... conversationId=019e3109-9a55-7d33-8c4a-a0cf134a9240
IAB_LIFECYCLE captured turn route conversationId=019e3109-9a55-7d33-8c4a-a0cf134a9240 turnId=019e3112-07b4-72d0-ac6e-c22e4e792dd2
error [electron-message-handler] Received item/started for unknown conversation conversationId=019e3109-9a55-7d33-8c4a-a0cf134a9240
error [electron-message-handler] Conversation state not found conversationId=019e3109-9a55-7d33-8c4a-a0cf134a9240
error [electron-message-handler] Received item/completed for unknown conversation conversationId=019e3109-9a55-7d33-8c4a-a0cf134a9240
warning [electron-message-handler] Rebinding placeholder latest turn to incoming event conversationId=019e3109-9a55-7d33-8c4a-a0cf134a9240 turnId=019e3112-07b4-72d0-ac6e-c22e4e792dd2
error [electron-message-handler] Item not found in turn state itemId=call_rzzlChH1DjmgGQZtmWtQKQFS
There were also unrelated-looking feature sync errors during the same startup window:
unsupported feature enablement `auth_elicitation`: currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation
Those may be incidental, but they appeared during the same recovery path.
Manual recovery evidence
Adding a synthetic task_complete event for the orphan turn made the rollout lifecycle balanced again:
VALID_JSONL lines=1710
BALANCED_TURNS started=3 completed=3
The inserted event was placed after the last assistant message for the orphan turn and before the next session_meta / next turn. This is not a proposed user workaround, but it strongly suggests the app should mark interrupted turns as failed/interrupted or tolerate this orphan state during resume.
Expected behavior
If Codex Desktop is interrupted during an active turn, reopening the conversation should recover gracefully:
- synthesize or persist an interrupted/failed completion state for orphan
task_startedturns, or - ignore/tombstone stale stream item events whose conversation state is missing, and
- keep LocalConversationPage usable instead of crashing into the generic error page.
The user should be able to continue the conversation without manually editing local session JSONL.
Related issues
This appears related to, but more specific than:
- Specific Codex conversation gets stuck in perpetual "thinking" after PC restart during an active turn #15849: missing
task_completeafter restart leaves a conversation stuck thinking - Desktop thread can enter persistent conversation-state desync after request_user_input in Default mode #10952: persistent conversation-state desync with
unknown conversation/Conversation state not found - LocalConversationPage crashes when opening some existing chats #22963: LocalConversationPage crashes when opening existing chats
- Codex Desktop on Windows: existing history thread opens/resumes inconsistently; thread/goal/get returns "goals feature is disabled" #22981: Windows Desktop history/open/resume inconsistency
This report adds current-version Windows Desktop evidence that a valid rollout with an orphan task_started can poison the reopen/resume path and produce Conversation state not found / Item not found in turn state before the generic error page.
Activity
github-actions commentedon May 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ryanye981006-sudo commentedon May 20, 2026
I'm seeing a variant of this on the same platform. Instead of a crash,
tool call entries silently disappear from the conversation page
after exiting and re-entering the same session.
Version: Codex Desktop 26.513.4821.0 (Microsoft Store)
Platform: Windows 10 x64, PowerShell
Steps to reproduce:
(exec_command, etc.)
Evidence gathered:
and is intact on disk
fix the issue
only the frontend rendering is affected
Suspected cause:
Likely the same orphan task_started / task_complete mismatch
described in this issue, but in this case it causes silent
UI omission rather than a hard crash on LocalConversationPage.
ESKehler commentedon Sep 8, 2026
Reproduced again on Windows, this time with a different user-visible failure mode.
Environment
Lifecycle evidence from a long-running local task
task_startedevent was persisted at2026-09-06T05:51:35.109Z.item_completedevents followed through05:54:51.265Z.task_completewas ever persisted.05:57:29.350Zand completed normally at06:11:22.730Z.2026-09-07T19:41:35.049Z.Despite that, both the native desktop
read_threadsurface and an independent offline thread reader still select the orphaned Sep 6 turn as the newest turn, mark itinProgress, and stop there. Codex mobile displays the same stale endpoint. Thread metadata continues updating, so the task looks current while later visible conversation is missing.This is therefore not mobile-only and not just a renderer/scrolling problem: the persisted rollout is ahead of both app-reader/index surfaces. The lifecycle evidence strongly supports the same root class reported here—an orphaned
task_startedprevents later valid turns from becoming visible.Related: #43182. A safe recovery path should reconcile or tombstone orphaned turns, continue projecting subsequent valid turns, and provide a supported reindex/recovery mechanism for already-affected tasks.