Codex Desktop unarchive leaves stale archived rollout path
Summary
Codex Desktop archive/unarchive appears to leave stale UI/app-server state after unarchiving a thread. The thread is correctly restored in the local thread database and active transcript path, but Desktop may still try to resume from the old ~/.codex/archived_sessions/... rollout path and shows "Failed to resume chat".
Observed behavior
After unarchiving a thread from Archived Threads, opening it can throw:
Failed to resume chat
failed to resolve rollout path `/Users/office/.codex/archived_sessions/rollout-2026-05-09T17-00-52-019e0f2f-d0e1-7931-a922-c1f25cdbeb98.jsonl`: No such file or directory (os error 2)
I saw the same stale-path shape on multiple recently unarchived threads. Example thread IDs:
019e0f2f-d0e1-7931-a922-c1f25cdbeb98
019e8d46-898d-7ae1-af82-654ce2d5a413
019e879a-5eec-7fc2-ad16-708f14b9787a
Local state after unarchive
For the example above, local state looked correct after unarchive:
threads.archived = 0
threads.archived_at = NULL
threads.rollout_path = /Users/office/.codex/sessions/2026/05/09/rollout-2026-05-09T17-00-52-019e0f2f-d0e1-7931-a922-c1f25cdbeb98.jsonl
active JSONL exists and parses cleanly
archived_sessions copy is gone, as expected after unarchive
Codex app read_thread can load the thread
Fresh app API reads can load the same thread, so this looks like Desktop is using stale cached archived metadata/path for the already-open Archived Threads view or resume request.
Expected behavior
After unarchive, Desktop should resume the thread from the active ~/.codex/sessions/... rollout path, or refresh the thread metadata before attempting thread/resume.
Versions
Codex Desktop: 26.601.21317, build 3511
Codex CLI: 0.125.0
Platform: macOS
Additional note
The error message also suggested running codex unarchive <session-id>, but this CLI build does not expose a codex unarchive command in codex --help.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Possibly relevant:
rust-v0.140.0includes #27276, which changes archive rollout lookup to try the exact rollout filename before falling back to broader file search when the state DB does not have a usable rollout path.If this stale archived-path case reaches that fallback, current builds may recover faster or more reliably. It likely does not by itself fix Desktop UI/cache state continuing to send an old
archived_sessionspath, so a retest on 0.140+ would help separate stale-metadata behavior from rollout lookup cost.