Codex Desktop exposes stale ghost conversations that cannot be resumed or archived
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(CFBundleVersion4306) - 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/resumefailure 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 founderrors 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.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗