Skip to content

Codex Desktop Windows: orphan task_started without task_complete poisons thread reopen and crashes LocalConversationPage #23035

Open

Description

@gzsisogaoguoqiang

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:

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

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    app-serverIssues involving app server protocol or interfaces
    on May 16, 2026
  2. ryanye981006-sudo commented on May 20, 2026

    @ryanye981006-sudo

    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:

    1. Open a conversation, let the agent run several tool calls
      (exec_command, etc.)
    2. All tool call traces render correctly during the session
    3. Exit Codex completely
    4. Reopen Codex and navigate back to the same conversation
    5. The tool call "已运行" entries are gone from the UI

    Evidence gathered:

    • The session JSONL file still contains all 45 function_call entries
      and is intact on disk
    • Deleting state_5.sqlite to force a full reindex from JSONL does NOT
      fix the issue
    • The agent backend can still access the full tool call history;
      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.

  3. ESKehler commented on Sep 8, 2026

    @ESKehler

    Reproduced again on Windows, this time with a different user-visible failure mode.

    Environment

    • Codex Desktop 26.901.6511.0
    • app-server/CLI 0.153.4
    • Windows 10 Home 22H2, build 19045.7663, x64

    Lifecycle evidence from a long-running local task

    • A task_started event was persisted at 2026-09-06T05:51:35.109Z.
    • 26 item_completed events followed through 05:54:51.265Z.
    • No matching task_complete was ever persisted.
    • A later turn started at 05:57:29.350Z and completed normally at 06:11:22.730Z.
    • Many additional later turns also started and completed normally, and the rollout contains ordinary assistant messages through 2026-09-07T19:41:35.049Z.

    Despite that, both the native desktop read_thread surface and an independent offline thread reader still select the orphaned Sep 6 turn as the newest turn, mark it inProgress, 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_started prevents 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions