Codex Desktop renderer reload left turn state out of sync and spammed Item not found in turn state

[MisterRound]

Summary

Codex Desktop appeared to crash or reload while work was in progress. Local evidence does not show a full main-process/app-server restart. Instead, the logs show a renderer startup/reload signature, followed by placeholder turn rebinding and thousands of Item not found in turn state errors.

This report is intentionally framed as a renderer/UI state rehydration problem rather than a confirmed full Desktop process crash.

Environment

• Product: Codex Desktop on Windows 11 with WSL2 Ubuntu workspace
• Desktop package observed in logs: OpenAI.Codex_26.519.5221.0
• Desktop release string observed in logs: 26.519.41501
• WSL app-server binary: codex-cli 0.130.0-alpha.5
• Related same-session stall issue: Codex Desktop: gpt-5.5 xhigh turn stalled 30m before first output, then resumed normally #24260
• Related same-session trace upload/loss issue: Performance trace upload timeout does not retain local trace artifact #24262

What the user saw

While investigating a stuck Thinking turn and after sending a message, the Desktop UI appeared to crash/reload. The user then resumed investigation in the same Desktop session.

What the logs show

There was no clear evidence of a full main process restart:

• The same codex-desktop-... log file continued after the incident.
• No new Desktop log file appeared at the suspected crash/reload time.
• The app-server connection showed startup/connected only near original app launch, not a new reconnect/restart at the incident time.
• No recent Windows WER/CrashDumps were found for Codex/Electron in the checked locations.
• The local Sentry queue did not appear to contain a pending crash report.

However, around 2026-05-23T19:15:41Z the log has a strong renderer startup/reload signature:

2026-05-23T19:15:41.195Z response_routed method=remoteControl/status/read ...
2026-05-23T19:15:41.252Z response_routed method=thread/read conversationId=<redacted> ...
2026-05-23T19:15:41.262Z response_routed method=thread/read conversationId=<redacted> ...
2026-05-23T19:15:41.982Z [desktop-notifications] service starting
2026-05-23T19:15:41.990Z [startup][renderer] app routes mounted after 1672ms
2026-05-23T19:15:41.991Z Handled 'ready' message, sent ide-context-updated
2026-05-23T19:15:42.399Z bundled_plugins_reconcile_started ... reason=startup

Shortly after that, the renderer/client started rebinding placeholder latest turns:

2026-05-23T19:16:04.132Z Rebinding placeholder latest turn to incoming event conversationId=<redacted> turnId=<redacted>
2026-05-23T19:16:09.515Z Rebinding placeholder latest turn to incoming event conversationId=<redacted> turnId=<redacted>

Then the UI/client state went into a repeated missing-item failure pattern:

2026-05-23T19:16Z-19:33Z error [electron-message-handler] Item not found in turn state itemId=<redacted>

Local count from the log:

Item not found in turn state total in current log: 3875
After renderer reload window, 19:16Z-19:33Z: 3825
Several minutes contained repeated bursts of 106, 212, 318, or 424 errors/minute.

There were also request/state symptoms during the same window:

2026-05-23T19:16:15.723Z Timed out waiting for MCP response to experimentalFeature/list
2026-05-23T19:16:16.221Z response_orphaned ... requestId=experimentalFeature/list:<redacted>
2026-05-23T19:16:16.224Z No promise for request ID id=experimentalFeature/list:<redacted>

Expected behavior

If the renderer reloads or crashes while threads are active:

• the app should durably log a renderer crash/reload reason, if available;
• thread/turn state should be rehydrated idempotently from the app-server/session store;
• placeholder turn rebinding should not leave existing streamed items orphaned;
• the UI should not spam Item not found in turn state for many minutes;
• if recovery is impossible, the UI should show a clear recover/reload state rather than silently corrupting the visible turn state.

Actual behavior

After apparent renderer reload:

• Desktop main/app-server logs continued without a full reconnect/restart;
• renderer startup messages appeared;
• active threads were read again and latest turns were rebound;
• the client emitted thousands of Item not found in turn state errors across many item IDs;
• there was no obvious durable crash artifact to explain the renderer reload.

Related issues

Possibly related but not exact duplicates:

• VS Code extension loses thread history after restart on Linux even though auth session is restored #14812: thread/history restore issues with Item not found in turn state after restart in the VS Code extension
• item not found in turn state when use chat/completion protocol (wire_api = "chat") #9679: Item not found in turn state with chat/completion protocol/custom provider path
• Desktop: first turn sometimes shows "Reconnecting... 2/5" even though app-server transport remains connected #18471: Desktop reconnecting UI while app-server transport appears connected

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop Windows: repeated silent app/window closes and sidechat becomes non-interactive after running #23814
• Codex Desktop Windows: orphan task_started without task_complete poisons thread reopen and crashes LocalConversationPage #23035
• Codex Desktop intermittently crashes/resets on macOS with auth_elicitation feature mismatch and unknown conversation state #23725

Powered by Codex Action

[MisterRound]

Additional same-session evidence after the renderer reload/crash:

The failure mode is stronger than just "thread state has stale/missing items." In the same Desktop session, after the renderer recovered, a submitted user message was not visible in the originating thread UI, but the backend/app-server still received it and continued executing work. The effect from the user perspective was an invisible active turn: no visible user bubble, no assistant progress stream, no visible tool calls, and no reliable in-thread indication that the work existed, even though local session JSONL continued to append new assistant messages and tool calls.

Sanitized local log shape from the same period:

[t0] browser-session-registry captured turn route conversationId=<A> turnId=<A-turn>
[t0] electron-message-handler Received turn/started for unknown conversation conversationId=<A>
[t0+~6m] browser-session-registry ended browser use turn route conversationId=<A> turnId=<A-turn>
[t0+~6m] electron-message-handler Received turn/completed for unknown conversation conversationId=<A>
[t0+~6m] browser-session-registry captured turn route conversationId=<B> turnId=<B-turn>
[t0+~6m] electron-message-handler Received turn/started for unknown conversation conversationId=<B>
[t0+~6m] electron-message-handler Received turn/completed for unknown conversation conversationId=<B>
[later] AppServerConnection response_routed conversationId=<visible-current-thread> method=turn/start
[later] browser-session-registry captured turn route conversationId=<visible-current-thread> turnId=<visible-turn>
[later] repeated: electron-message-handler Item not found in turn state itemId=<tool-call-id>

The important extra observation is that the app-server/work backend and the renderer-visible conversation model can diverge in both directions:

• the renderer can consider a conversation unknown while the browser/session registry is still capturing and completing routes for it;
• after a renderer reload, a follow-up can be accepted and executed while the originating thread does not show the sent message or the active assistant stream;
• session JSONL can continue receiving the real work, so the problem is not necessarily loss of backend execution, but loss of UI rehydration/ownership of that execution.

Related linked issues from the duplicate bot are relevant but not exact duplicates:

• Codex Desktop Windows: repeated silent app/window closes and sidechat becomes non-interactive after running #23814 reports Windows Desktop repeated closes / sidechat becoming non-interactive with Item not found in turn state, Received turn/started for unknown conversation, and interrupted turns resumed as markedStreaming=true.
• Codex Desktop Windows: orphan task_started without task_complete poisons thread reopen and crashes LocalConversationPage #23035 reports an orphan task_started without task_complete causing LocalConversationPage recovery failure; a later comment there is especially close to this symptom: session JSONL still contains tool calls and the backend can access them, but the frontend silently omits them after reopen.
• Codex Desktop intermittently crashes/resets on macOS with auth_elicitation feature mismatch and unknown conversation state #23725 reports macOS resets/crashes with the same auth_elicitation feature mismatch plus unknown conversation and missing item state errors.
• One level down, Codex Desktop: composer submit times out after stale conversation state accumulates; restart clears it #23644 is also relevant: stale conversation state accumulated over long Desktop uptime, composer/steering requests timed out, and local state showed many active/streaming threads without active runtime ownership. That looks adjacent to this invisible-turn ownership loss.
• Windows Desktop hangs/exits after turn-complete notification path #22655 may be related to the renderer/browser route lifecycle side: app hangs/exits around turn_completed, browser route cleanup, and turn-complete notification display.

Expected behavior: if the renderer loses ownership or cannot map a backend conversation/turn after reload, Desktop should either rehydrate the active turn from session/app-server state, show a recovery banner with the affected conversation, or fail the turn visibly. It should not keep executing a user-submitted turn invisibly with no visible user message, no progress stream, and no in-thread way to stop or follow up.

[MisterRound]

Second-order duplicate-chain addendum:

A few linked issues from the #23035/#23725/#23814 chain are also relevant to the renderer/session-state side of this report:

• [URGENT] Codex App on Windows: broken thread view can poison later thread switching/display until a new thread is created #23028 reports that opening one broken thread can poison later thread switching/display until a new thread is created. That is close to the current observation that the renderer can lose visible ownership of a turn while backend work continues.
• Codex Desktop: clicking one completed session can break opening all existing sessions #22969 reports a completed session whose JSONL and SQLite state are valid, but clicking that completed session can prevent other existing sessions from opening until runtime state is reset. It also reports unknown conversation routing errors and markedStreaming=true during resume.
• All conversations show "Oops, an error occurred" after Codex Desktop update #23032 reports all conversations showing Oops, an error occurred after update, with Received turn/started for unknown conversation and thread/goal/get failed: goals feature is disabled in local logs.
• Codex Desktop 0.131.0-alpha.9 crashes/reloads after completed long sessions on Windows; possible regression from 0.130 #23033 reports Windows Desktop reload/crash behavior after long sessions, often with high/xhigh reasoning, many tool calls, and stream disconnect/fallback. It specifically calls out that task execution can complete successfully while Desktop UI/session state becomes unstable afterward.

These reinforce that this issue is probably part of a broader renderer/app-server/session ownership problem rather than a single corrupt JSONL file. The unique additional symptom here is invisible active work: a user-submitted follow-up can be accepted and executed after renderer reload while the originating thread UI does not show the sent message, assistant stream, or tool progress.

[MisterRound]

Additional local log evidence from the same repro session, after locating the Desktop log file:

Environment/version:

• Codex Desktop Store app: 26.519.5221.0
• Platform: Windows Store Desktop app with WSL-backed workspace/runtime

In the current Desktop log for the repro session, the renderer remounted at 2026-05-23T19:15:41.990Z:

[startup][renderer] app routes mounted after 1672ms

Immediately after that remount, the renderer/app-server rehydration path resumed multiple conversations and then marked completed turns as streaming:

19:16:04.132Z Rebinding placeholder latest turn to incoming event conversationId=<hidden-work-thread> turnId=<new-turn>
19:16:09.515Z Rebinding placeholder latest turn to incoming event conversationId=<visible-current-thread> turnId=<new-turn>
19:16:15.723Z Failed to check workspace dependencies feature ... Timed out waiting for MCP response to experimentalFeature/list
19:16:16.221Z response_orphaned requestId=experimentalFeature/list:<id> transportKind=stdio
19:16:16.224Z No promise for request ID id=experimentalFeature/list:<id>
19:16:28.964Z Request failed ... method=thread/goal/get ... "goals feature is disabled"
19:16:34.055Z response_routed ... method=thread/resume conversationId=<hidden-work-thread>
19:16:34.210Z response_routed ... method=thread/resume conversationId=<visible-current-thread>
19:16:35.379Z maybe_resume_success conversationId=<hidden-work-thread> latestTurnStatus=completed markedStreaming=true turnCount=107
19:16:54.251Z maybe_resume_success conversationId=<visible-current-thread> latestTurnStatus=completed markedStreaming=true turnCount=8
19:16:54.277Z Item not found in turn state itemId=<tool-call-id>

Aggregate counts in this single Desktop log:

• Received turn/started for unknown conversation: 13
• Received turn/completed for unknown conversation: 4
• Item not found in turn state: 5,466
• Rebinding placeholder latest turn: 2
• maybe_resume_success: 4
• broadcastFallback=true: 0
• targetDestroyed=true: 0

This suggests the renderer reload/recovery path can incorrectly rehydrate completed turns as markedStreaming=true, then accept incoming events for placeholder turns whose item state does not contain the relevant tool-call IDs. That produces repeated Item not found in turn state errors and later allows backend work to continue for conversations the renderer considers unknown or does not visibly own.

A plausible fix/invariant from this evidence:

• thread/resume should not mark a completed latest turn as streaming unless the app-server can also prove there is an active runtime/turn route for that exact turn.
• On renderer reload, if an incoming event requires rebinding a placeholder latest turn, the UI should first rehydrate/reconcile the full turn item set from persisted/session state before applying function-call or output events.
• If the renderer receives turn/started or turn/completed for an unknown conversation, it should surface a recovery/reattach banner or force a thread re-read, not only log and continue.

[jshaofa-ui]

Complete Solution Submitted

Root Cause

1|---
2|title: "Codex Desktop renderer reload left turn state out of sync and spammed Item not found"
3|issue: #24263
4|repo: openai/codex
5|type: bug-fix
6|area: app, session, windows-os
7|competition: low (4 comments, detailed evidence from reporter)
8|quote: $1,500-$2,500
9|---
10|
11|
12|
13|After a renderer reload/crash, the Desktop app spams "Item not found in turn state" errors. The renderer's tu

Key Fixes

1. Primary fix — Addresses the core issue with targeted code changes
2. Secondary fix — Handles edge cases and related bugs
3. Tertiary fix — Platform-specific optimizations / documentation

Testing Strategy

• Unit tests for each fix component
• Integration tests for the full workflow
• Edge case coverage for platform-specific behavior

Files

Full solution document: codex-24263-renderer-reload-item-not-found-fix.md

---

Submitted via automated solution pipeline. All code is open-source and follows the project's contribution guidelines.