›_ Codex Issues
Codex Issues / #29868

Codex Desktop exposes stale ghost conversations that cannot be resumed or archived

Resolved 💬 5 comments Opened Jun 24, 2026 by infoechoes Closed Aug 4, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop can expose stale/ghost conversation IDs in the UI/recent-tasks path. These IDs are not present in the local thread index, so opening them repeatedly fails with no rollout found for thread id .... Attempting to archive one of these stale entries also fails, so the user cannot clear the broken item from the app UI.

This appears distinct from a shell snapshot validation issue I filed separately in #29864.

Environment

  • Codex Desktop: 26.616.81150 (CFBundleVersion 4306)
  • Bundled CLI: codex-cli 0.142.0
  • macOS: 26.4 (25E246)
  • Darwin: 25.4.0 arm64

Symptoms

Multiple conversations shown/accessible from the Desktop UI fail to restore. The app-server/local thread tools do not know about these IDs, but the renderer still attempts to read/resume/archive them.

Representative sanitized log snippets:

method=thread/resume conversationId=019ef957-...-0e6 errorCode=-32600
Request failed ... error={"code":-32600,"message":"no rollout found for thread id 019ef957-..."}
Failed to resume conversation ... errorMessage="no rollout found for thread id 019ef957-..."

method=thread/archive conversationId=019ef956-...-5e4 errorCode=-32600
Archive skipped because thread has no active rollout ... "no rollout found for thread id 019ef956-..."
Failed to persist inactive thread archive ... "Inactive thread archive did not persist"

No cwd found for local task conversationId=019ef956-...
No cwd found for local task conversationId=019ef957-...

Local validation

I checked the local state and the issue does not look like general thread database corruption:

sqlite3 ~/.codex/state_5.sqlite 'pragma quick_check;' => ok
threads_total=663
unarchived=31
missing_unarchived_cwd_or_rollout=0

The ghost IDs are absent from the thread DB:

019ef957-...-0e6 => 0 rows in threads
019ef956-...-5e4 => 0 rows in threads
019efa16-...-d7a => 0 rows in threads
019ef961-...-7cf => 0 rows in threads
019ef955-...-0ce => 0 rows in threads
019efa13-...-62d => 0 rows in threads

The same IDs also do not appear in codex_app.list_threads(query=...), and codex_app.read_thread(threadId=...) reports no Codex thread found. By contrast, real notLoaded threads with valid DB rows and rollout files are readable.

Expected behavior

  • Desktop should not present non-existent local conversation IDs as restorable conversations.
  • If a stale recent-task/sidebar entry exists but the thread has no rollout, archive/remove should still be able to clear the stale UI entry.
  • thread/resume failure for a missing rollout should not trap the user in a repeated unopenable item.

Workarounds tried

  • Verified all unarchived real threads have existing cwd and rollout files.
  • Cleared/recreated ~/.codex/shell_snapshots; this fixed a separate resume failure for one older real thread, but not these ghost IDs.
  • Moved Electron/Chromium cache directories aside and recreated empty cache directories. After that, no new no rollout found errors appeared until another UI open attempt, but the source of the stale IDs was not found in common local text-searchable storage.

Why this matters

From a user's perspective, this looks like "many sessions won't open" and invites over-archiving or deleting local data. In this case, archiving more real threads is not the root fix: the broken IDs are not real threads in the state DB at all.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28276

Powered by Codex Action

OmerFarukOruc · 2 months ago

I can reproduce the same ghost-conversation/archive failure on Linux.

Environment:

  • Codex Desktop: 26.616.81150
  • Codex CLI used by the app server path: codex-cli 0.142.2
  • OS: CachyOS / Arch-family Linux, KDE, Wayland
  • Electron: 42.1.0

Failing conversation id:

019f033c-2d80-7c92-bc60-0d44a3910ba1

Observed log signature in ~/.cache/codex-desktop/launcher.log:

IAB_LIFECYCLE registered browser sidebar thread conversationId=019f033c-2d80-7c92-bc60-0d44a3910ba1
method=thread/read ... errorCode=null
method=thread/resume ... errorCode=-32600
method=thread/goal/get ... errorCode=-32600
Request failed ... method=thread/resume ... "no rollout found for thread id 019f033c-2d80-7c92-bc60-0d44a3910ba1"
Request failed ... method=thread/goal/get ... "ephemeral thread does not support goals: 019f033c-2d80-7c92-bc60-0d44a3910ba1"
Archive requested ... source=recent_tasks_menu
method=thread/archive ... errorCode=-32600
Archive skipped because thread has no active rollout ... "no rollout found for thread id 019f033c-2d80-7c92-bc60-0d44a3910ba1"
Failed to persist inactive thread archive ... "Inactive thread archive did not persist"

Local validation:

codex_app.list_threads(query=019f033c-2d80-7c92-bc60-0d44a3910ba1) => []
codex_app.read_thread(threadId=019f033c-2d80-7c92-bc60-0d44a3910ba1) => No Codex thread found
~/.codex/state_5.sqlite threads row for that id => 0 rows
no matching rollout file under ~/.codex/sessions or ~/.codex/archived_sessions

There is a nearby real thread prefix (019f033c-2510-...) in state_5.sqlite, but the exact failing id has no backing thread row or rollout. The interesting part in this reproduction is that the stale id appears to come through the browser/IAB sidebar route, then the UI/recent-tasks path treats it as a normal archiveable/resumable conversation.

Expected behavior: if the app knows a route is ephemeral/browser-sidebar-backed, or if thread/resume returns no rollout found plus thread/goal/get returns ephemeral thread does not support goals, the recent/sidebar entry should be locally removable without sending a normal thread/archive request that requires a rollout.

Superfishintights · 1 month ago

I can still reproduce this on Linux, and it appears to be the same failure family as #28276.

Environment:

  • Codex Desktop: 26.623.101652
  • Electron: 42.1.0
  • app-server / CLI: 0.142.5
  • OS: CachyOS rolling, Linux 7.0.12-1-cachyos, Wayland

Repro notes:

  • Full Codex Desktop restart before the smoke test.
  • Normal Desktop -> app-server path.
  • One real thread was created, completed, and archived successfully.
  • During that same smoke test, Desktop also surfaced a ghost/ephemeral conversation id with no durable backing record.

Smoke test result:

  • Real thread: 019f397a-a6f3-7393-94bd-6a32765e6429
  • Ghost id: 019f397a-aa99-77b2-92e3-08a03db8f939

The ghost id produced a New chat / turn-complete UI artifact even though it has no backing thread row, session index entry, or rollout file.

Relevant log sequence from ~/.local/state/codex/logs/2026/07/06/codex-desktop-154c1f8a-0d57-4140-b316-de978556e32b-448771-t0-i1-220817-0.log:

2026-07-06T22:08:17.537Z info [StdioConnection] stdio_transport_spawned argsCount=2 executablePath=/home/jay/.npm-global/bin/codex pid=448865 spawnCommand=/home/jay/.npm-global/bin/codex
2026-07-06T22:08:17.758Z info [AppServerConnection] Current reported app-server version: currentVersion=0.142.5 hostId=local

2026-07-06T22:09:28.044Z info [electron-message-handler] Conversation created conversationId=019f397a-a6f3-7393-94bd-6a32765e6429 rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=false rendererWindowId=1 rendererWindowVisible=true
2026-07-06T22:09:28.573Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=019f397a-a6f3-7393-94bd-6a32765e6429 durationMs=42 errorCode=null hadInternalHandler=false hadPending=true method=turn/start originWebcontentsId=1 requestId=cdb0daba-39f3-465b-9354-a7e172dc73ee targetDestroyed=false
2026-07-06T22:09:29.125Z warning [electron-message-handler] Skipping hydration for ambiguous turn/started conversationId=019f397a-aa99-77b2-92e3-08a03db8f939 rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=false rendererWindowId=1 rendererWindowVisible=true resolvedConversationId=null turnId=019f397a-ad69-75d1-8ab5-06b6e58f132c
2026-07-06T22:09:32.484Z warning [electron-message-handler] Hydrating conversation for turn/completed conversationId=019f397a-aa99-77b2-92e3-08a03db8f939 queuedNotificationCount=1 rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=false rendererWindowId=1 rendererWindowVisible=true
2026-07-06T22:09:32.585Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=019f397a-aa99-77b2-92e3-08a03db8f939 durationMs=100 errorCode=null hadInternalHandler=false hadPending=true method=thread/read originWebcontentsId=1 requestId=666a6cc6-6fff-4424-8b9b-047a02083285 targetDestroyed=false
2026-07-06T22:09:32.662Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=019f397a-a6f3-7393-94bd-6a32765e6429 durationMs=30 errorCode=null hadInternalHandler=false hadPending=true method=thread/name/set originWebcontentsId=1 requestId=a7916268-e0ed-433f-840e-bc4516328ffc targetDestroyed=false
2026-07-06T22:09:32.802Z error [electron-message-handler] No turns for conversation conversationId=019f397a-aa99-77b2-92e3-08a03db8f939 rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=false rendererWindowId=1 rendererWindowVisible=true
2026-07-06T22:09:32.952Z info [electron-message-handler] [desktop-notifications] show turn-complete conversationId=019f397a-aa99-77b2-92e3-08a03db8f939 rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=false rendererWindowId=1 rendererWindowVisible=true turnId=019f397a-ad69-75d1-8ab5-06b6e58f132c

Backing-store checks for the ghost id:

sqlite3 ~/.codex/state_5.sqlite "select count(*) from threads where id='019f397a-aa99-77b2-92e3-08a03db8f939';"
=> 0

rg "019f397a-aa99-77b2-92e3-08a03db8f939" ~/.codex/session_index.jsonl
=> no matches

find ~/.codex/sessions ~/.codex/archived_sessions -name '*019f397a-aa99-77b2-92e3-08a03db8f939*'
=> no files

For comparison, the real smoke thread persisted normally:

sqlite3 ~/.codex/state_5.sqlite "select count(*) from threads where id='019f397a-a6f3-7393-94bd-6a32765e6429';"
=> 1

~/.codex/archived_sessions/rollout-2026-07-06T23-09-27-019f397a-a6f3-7393-94bd-6a32765e6429.jsonl

What looks wrong to me:

  • turn/started for the ghost id is skipped as ambiguous, but turn/completed later hydrates that same id anyway.
  • thread/read returns successfully for the ghost id, but Desktop then logs No turns for conversation.
  • Desktop still shows a turn-complete notification / sidebar artifact for that ghost id.
  • The ghost id has no durable backing record or rollout, so it behaves like the stale/ephemeral conversation described here and in #28276.
Superfishintights · 1 month ago

Follow-up after updating Codex Desktop today: the visible ghost New chat issue no longer reproduces for me in a fresh smoke test.

Environment now:

  • Codex Desktop: 26.623.141536
  • Electron: 42.1.0
  • app-server / CLI: 0.142.5
  • OS: CachyOS rolling, Linux 7.0.12-1-cachyos, Wayland

Smoke test:

  • Created one projectless thread: 019f3e5e-6a8d-7282-8b47-bc1d02d065a7
  • It completed with the expected response.
  • It persisted normally in state_5.sqlite and session_index.jsonl.
  • It had a rollout file:

~/.codex/archived_sessions/rollout-2026-07-07T21-56-42-019f3e5e-6a8d-7282-8b47-bc1d02d065a7.jsonl

  • It archived successfully.

Compared with my previous repro on 26.623.101652, I no longer see the failure chain:

Hydrating conversation for turn/completed
thread/read for the ghost id
No turns for conversation
desktop notification / New chat artifact for the ghost id

I did still see a residual unknown-conversation pair for a nearby id:

2026-07-07T20:56:45.082Z error [electron-message-handler] Received turn/started for unknown conversation conversationId=019f3e5e-6eb6-7621-938c-e951b2963362
2026-07-07T20:56:49.240Z error [electron-message-handler] Received turn/completed for unknown conversation conversationId=019f3e5e-6eb6-7621-938c-e951b2963362

But that id did not persist and did not appear to cause the user-visible bug:

sqlite3 ~/.codex/state_5.sqlite "select count(*) from threads where id='019f3e5e-6eb6-7621-938c-e951b2963362';"
=> 0

rg "019f3e5e-6eb6-7621-938c-e951b2963362" ~/.codex/session_index.jsonl
=> no matches

find ~/.codex/sessions ~/.codex/archived_sessions -name '*019f3e5e-6eb6-7621-938c-e951b2963362*'
=> no files

So from my side this looks materially improved/fixed for the visible ghost-sidebar behavior after 26.623.141536, with a possible remaining lower-level unknown-turn event still present in logs.

cndaimin · 1 month ago

I can reproduce this failure family in Codex Desktop 26.715.72359 on macOS, with a more specific source for the ghost entry: an ephemeral ambient-suggestions session leaked into the normal task sidebar.

Reproduction / evidence

  • The sidebar shows a perpetual-spinner entry named ‘New Task’ under project lstoragehub.
  • Clicking it reports: no rollout found for thread id 019f8da7-0900-7e20-ac2a-a9cacf1a7144.
  • The app recognizes this ID as an ephemeral thread, but there is no row in the normal thread DB, no session-index entry, and no rollout file.
  • Local app logs identify the session prompt as: ‘Generate 0 to 3 hyperpersonalized suggestions for what this user can do with Codex in this local project…’
  • Timeline (Asia/Shanghai): started 2026-07-23 14:26:02, waited on an MCP approval/elicitation during a read-only connected-app scan, then was interrupted at 14:36:02.
  • The ambient-suggestions output remained empty, but the sidebar kept the normal-looking task row and spinner.

Expected

Ephemeral ambient-suggestions sessions should never appear as normal resumable tasks. If interrupted, their sidebar state should be removed even though no rollout exists.

Actual

The ephemeral session remains visible as a normal ‘New Task’; selecting it takes the normal resume path and fails because there is intentionally no rollout.

I also captured a screenshot of the Chinese UI; the second spinner row is the ghost task. No connected-app content is included in this report.