codex - 💡(How to fix) Fix Codex Desktop local thread can be hidden/stale when state_5.sqlite and session_index.jsonl drift on Windows [1 participants]

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.jsonl exists but has a stale or vague title / timestamp
• state_5.sqlite has a threads row, but Desktop does not surface the thread in sidebar/search until the SQLite row and session_index.jsonl are 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:

1. Back up:

%USERPROFILE%\.codex\state_5.sqlite
%USERPROFILE%\.codex\state_5.sqlite-wal
%USERPROFILE%\.codex\state_5.sqlite-shm
%USERPROFILE%\.codex\session_index.jsonl

1. 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>';

1. Update or add the corresponding session_index.jsonl record:

{"id":"<thread_id>","thread_name":"<restored title>","updated_at":"<current ISO timestamp>"}

1. 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.threads
• session_index.jsonl
• sessions/**/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.