›_ Codex Issues
Codex Issues / #24263

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

Open 💬 8 comments Opened May 23, 2026 by MisterRound
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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: #24260
  • Related same-session trace upload/loss issue: #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:

  • #14812: thread/history restore issues with Item not found in turn state after restart in the VS Code extension
  • #9679: Item not found in turn state with chat/completion protocol/custom provider path
  • #18471: Desktop reconnecting UI while app-server transport appears connected

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 1 month ago

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

  • #23814
  • #23035
  • #23725

Powered by Codex Action

MisterRound · 1 month ago

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:

  • #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.
  • #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.
  • #23725 reports macOS resets/crashes with the same auth_elicitation feature mismatch plus unknown conversation and missing item state errors.
  • One level down, #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.
  • #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 · 1 month ago

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:

  • #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.
  • #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.
  • #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.
  • #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 · 1 month ago

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 · 1 month ago

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: https://github.com/openai/codex/issues/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.

rzv-me · 1 month ago

Still reproduces on macOS with Codex Desktop 26.609.41114 build 3888.

Fresh repro:

  • Time: 2026-06-13T12:44:45Z / 15:44:45 EEST
  • Crashpad dump id: 1b0bb291-f210-4132-90c6-badb616e9c63
  • Sidecar: {"osarch":"arm64","ptype":"renderer"}

The app showed the loading screen/reload behavior, but agents/app-server continued.

After the renderer crash/reload, the same Desktop log shows the same recovery pattern:

  • thread/read
  • thread/resume
  • IAB_LIFECYCLE browser-use route capture/rebind
  • maybe_resume_success latestTurnStatus=completed markedStreaming=true
  • maybe_resume_success latestTurnStatus=inProgress markedStreaming=true

This confirms the issue still reproduces on a newer macOS Desktop build, and with a real renderer Crashpad artifact rather than only inferred renderer reload.

MisterRound · 1 month ago

Fresh Windows + WSL2 reproduction on a newer Desktop build. This looks like the same renderer recovery/state-ownership bug, with one new symptom: the user-facing UI hit the generic "oops / try again" render error while the active threads continued running, and the Reload button resumed the UI.

Environment:

  • Product: Codex Desktop on Windows 11 with WSL2 Ubuntu runtime/workspace
  • Store package observed: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
  • Release string in logs: 26.609.41114
  • Current workspace at the time was the Desktop Codex home, sanitized as %USERPROFILE%\.codex

User-visible symptom:

  • At about 2026-06-15T15:39:51Z, the Desktop UI showed the generic "oops / try again" render error.
  • Pressing Reload brought the UI back.
  • Existing/running threads were not killed; they continued running/resumed after the UI reload.

Relevant sanitized log shape from the same Desktop log:

2026-06-15T15:39:51Z error [electron-message-handler] error boundary
  name=LocalConversationPage
  errorName=Error
  errorMessage=""
  errorStack="Error at Object.error (app://-/assets/vscode-api-...js:1:4778)"
  componentStack starts with:
    at Hy (app://-/assets/composer-...js:46:37854)
    at rA (app://-/assets/local-conversation-thread-...js:43:84520)
    ...
    at Bt / qt (app://-/assets/local-conversation-page-...js:1:...)

2026-06-15T15:39:51Z error [electron-message-handler] error boundary
  name=LocalConversationPage
  errorName=Error
  errorMessage=""
  componentStack starts with:
    at $O (app://-/assets/local-conversation-thread-...js:43:29836)
    at iA (app://-/assets/local-conversation-thread-...js:43:87353)
    ...

Surrounding state/routing symptoms:

[desktop-notifications][global-error] AggregateError
Received item/started for unknown conversation
Received turn/started for unknown conversation
Received turn/completed for unknown conversation
Conversation state not found
No turns for conversation
Item not found in turn state
Failed to refresh ambient suggestions: Timed out waiting for MCP response to thread/list
response_orphaned requestId=app/list:<redacted>
No promise for request ID id=app/list:<redacted>

The same window had slow thread/list responses, including examples around:

11655ms
19102ms
29452ms
53539ms
24482ms
16015ms

Negative/clarifying evidence:

  • I did not find a new Crashpad dump at this event time.
  • The shared %USERPROFILE%\.codex\tmp\arg0 root stayed WSL/Linux-only, with no shared-root Windows .bat helper pollution.
  • No unsafe shared-home node_repl.exe -> codex.exe app-server --listen stdio:// sidecars were present in the post-event native inventory.
  • There were isolated wrapper sidecars under %USERPROFILE%\.codex\chrome-runtime-home, but those did not poison the shared WSL helper root. This makes the repro distinct from the Windows/WSL arg0-helper collision reports.

Adjacent but not proven causal:

2026-06-15T15:39:35Z primary_runtime_install_started release=latest target=win32-x64
2026-06-15T15:39:41Z primary_runtime_install_failed bundleVersion=26.614.11602 errorMessage="Failed to list primary runtime archive: "
2026-06-15T15:39:41Z primary_runtime_update_poll_failed

That runtime update failure happened about 10 seconds before the LocalConversationPage error boundary, so it may be related timing pressure or may be incidental.

Why I think this belongs on this issue:

  • The renderer-visible conversation model again diverged from backend/app-server work ownership.
  • The UI hit a LocalConversationPage error boundary, but the app-server/threads continued.
  • The same recovery window includes unknown conversation events, orphaned responses, slow thread/list, and missing turn-state items.

Expected invariant: LocalConversationPage should fail-soft or force a bounded re-read/reconcile when it receives late/stale conversation events or orphaned thread/list/app/list responses after reload. It should not trip a blank render error while backend work keeps running invisibly or semi-invisibly.

rzv-me · 27 days ago

This is still reproducing for me on newer Codex Desktop builds, now up to 26.616.71553.

Latest incident:

  • Time: 2026-06-23T09:23:20Z / 12:23:20 EEST
  • Platform: macOS arm64
  • App release in logs: 26.616.71553
  • User-visible behavior: UI showed the loading screen / renderer remounted, while agents kept running and no work was lost.
  • No new Crashpad dump for this latest event. Newest local Crashpad dump is still from 2026-06-16.

Relevant log sequence:

2026-06-23T09:23:02.967Z turn/start conversationId=019edff9-73df-7443-9041-93b4a273866f
2026-06-23T09:23:17.910Z Rebinding placeholder latest turn to incoming event conversationId=019edff9-73df-7443-9041-93b4a273866f
2026-06-23T09:23:18.729Z Item not found in turn state itemId=call_JYXPId3EvkhzJOzwEkTuVYjm
2026-06-23T09:23:20.320Z [startup][renderer] app routes mounted after 4840ms
2026-06-23T09:23:40.432Z maybe_resume_success conversationId=019edff9-73df-7443-9041-93b4a273866f latestTurnStatus=inProgress markedStreaming=true turnCount=5
2026-06-23T09:23:40.477Z repeated Item not found in turn state

So the earlier Crashpad-backed renderer crash variant has now become, or is accompanied by, repeated renderer remount/loading-screen events without new Crashpad dumps. The same state-rehydration pattern remains: placeholder turn rebinding, markedStreaming=true, and repeated Item not found in turn state.