codex - 💡(How to fix) Fix Codex Desktop Windows: orphan task_started without task_complete poisons thread reopen and crashes LocalConversationPage

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

1. Start a normal Codex Desktop conversation on Windows.
2. During an active turn, interrupt/accidentally switch or restart the interaction.
3. Continue in the same conversation, creating a later turn that does complete successfully.
4. Reopen the affected historical conversation from the sidebar/history.
5. 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_started turns, 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:

• #15849: missing task_complete after restart leaves a conversation stuck thinking
• #10952: persistent conversation-state desync with unknown conversation / Conversation state not found
• #22963: LocalConversationPage crashes when opening existing chats
• #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.