Repository navigation
Codex Desktop local thread can be hidden/stale when state_5.sqlite and session_index.jsonl drift on Windows #22452
Description
Summary
Codex Desktop on Windows can hide or show stale metadata for a valid local thread when the local metadata stores drift:
- the rollout JSONL exists under
%USERPROFILE%\.codex\sessions\... session_index.jsonlexists but has a stale or vague title / timestampstate_5.sqlitehas athreadsrow, but Desktop does not surface the thread in sidebar/search until the SQLite row andsession_index.jsonlare manually repaired
This looks related to, but not exactly the same as, existing session metadata issues such as #20254 and #16405.
Environment
- Platform: Windows
- Codex local client observed:
codex-cli 0.130.0-alpha.5 - Codex Desktop local data directory:
%USERPROFILE%\.codex - Subscription/account details intentionally omitted
Observed behavior
A local project thread appeared to be missing from Codex Desktop after restart. Investigation showed the thread content was not lost.
Sanitized local state:
%USERPROFILE%\.codex\sessions\YYYY\MM\DD\rollout-YYYY-MM-DDTHH-MM-SS-<thread_id>.jsonl exists
%USERPROFILE%\.codex\session_index.jsonl has an entry, but stale/vague title and old updated_at
%USERPROFILE%\.codex\state_5.sqlite has a threads row
The state_5.sqlite.threads row had roughly this shape:
id = <thread_id>
title = <stale/vague auto-generated title>
cwd = \\?\%USERPROFILE%\Documents\Codex\Projects\<project>
rollout_path = %USERPROFILE%\.codex\sessions\...\rollout-...-<thread_id>.jsonl
archived = 0
updated_at = old timestamp
The thread was still not easy to find in Desktop because the visible metadata did not reconcile with the valid rollout file and the intended project context.
Local recovery that worked
The thread became visible again after manually repairing both metadata layers and restarting Codex Desktop:
- Back up:
%USERPROFILE%\.codex\state_5.sqlite
%USERPROFILE%\.codex\state_5.sqlite-wal
%USERPROFILE%\.codex\state_5.sqlite-shm
%USERPROFILE%\.codex\session_index.jsonl
- Update the SQLite row:
update threads
set title = '<restored title>',
updated_at = <current unix seconds>,
updated_at_ms = <current unix milliseconds>,
archived = 0,
archived_at = null
where id = '<thread_id>';- Update or add the corresponding
session_index.jsonlrecord:
{"id":"<thread_id>","thread_name":"<restored title>","updated_at":"<current ISO timestamp>"}- Restart Codex Desktop.
After this, the thread appeared in the Desktop UI again.
Expected behavior
Codex Desktop should reconcile local thread metadata from the available sources:
state_5.sqlite.threadssession_index.jsonlsessions/**/rollout-*.jsonl
If a rollout file exists and the SQLite row is unarchived, Desktop should not leave the thread hidden or only discoverable through stale metadata.
Suggested fixes
- Add a supported local reindex/repair command for Desktop-visible local threads.
- On startup, detect drift between
state_5.sqlite,session_index.jsonl, and existing rollout JSONL files. - If a thread is unarchived and its rollout file exists, prefer a recoverable visible state over hiding it.
- Keep thread title and updated timestamp writes consistent across SQLite and
session_index.jsonl. - Surface a warning/recovery prompt when metadata is stale rather than making the user inspect SQLite manually.
Privacy note
This report intentionally redacts local usernames, project names, thread IDs, and transcript content. The issue is about local metadata consistency, not the content of any specific session.
Activity
geegewu commentedon May 24, 2026
I hit a very similar local-history drift case on macOS, but with a larger
session_index.jsonlgap. This looks like the same class of Desktop-visible metadata becoming incomplete while the underlying rollout files are still intact.Environment:
Local evidence before repair:
The missing sessions were spread across multiple project roots, not just one project. Examples of affected root groups included normal home/project roots and several Codex Desktop project roots. The important part is that the raw
rollout-*.jsonlfiles were still present and parseable; they were just absent fromsession_index.jsonl, so the Desktop/resume history looked like many conversations had disappeared.Manual recovery that worked:
session_index.jsonlentries by scanning:Adjacent observation:
~/.codex/.codex-global-state.jsonalso had incompletethread-workspace-root-hints. Editing that file while Codex Desktop was running was not stable: the running Desktop process wrote its in-memory state back and overwrote the manual repair. That part seems related to #21076, where global/sidebar state can be stale and direct edits are overwritten by the app.Expected behavior:
Codex Desktop should provide a supported local repair/reindex path, or automatically reconcile local history when rollout files exist but
session_index.jsonlis incomplete. At minimum, startup should detect this drift and warn rather than making the user think conversations were deleted.Suggested repair source order:
This does not appear to be transcript data loss. It appears to be local metadata/index drift causing Desktop-visible history loss.