Codex Desktop hides searchable local threads and shows stale/recent dates after path migration

What happened

After local project path migration / session migration, Codex Desktop shows inconsistent thread history for local projects:

1. Some historical threads exist on disk and can be opened by exact thread id, but they do not appear in the project sidebar or search results.
2. thread/list / Desktop project grouping returns fewer threads than state_5.sqlite and the raw rollout store for the same cwd.
3. The Desktop UI sometimes displays many old conversations as recently updated (for example, "within 30 minutes"), even though the SQLite created_at / updated_at timestamps are much older or only a small subset changed.
4. Pinning a thread by id makes some hidden threads visible, but search still may not find them by title.

This looks like an app-server / Desktop search-index / project-grouping cache issue rather than data loss.

Environment

• Codex Desktop app build: 26.602.30954 (prod)
• Bundled Codex CLI: codex-cli 0.137.0-alpha.4
• OS: macOS 26.5.1 (25F80)
• Local state DB: ~/.codex/state_5.sqlite
• Session store: ~/.codex/sessions/**/rollout-*.jsonl
• Archived session store: ~/.codex/archived_sessions/*.jsonl

Evidence

The counts below were collected with a local read-only diagnostic comparing raw rollout files, SQLite, and app-server thread/list for exact cwd values.

Project A:

• raw rollout count: 30
• SQLite thread count: 30
• app-server thread count: 4
• explicit project config: true
• diagnosis: app-server filtering or metadata issue
• Desktop search for project-specific keywords returns no threads, while direct thread reads by id work.

Project B:

• raw rollout count: 60
• SQLite thread count: 60
• app-server thread count: 53
• explicit project config: true after adding config
• direct reads by id work, but global search by exact title sometimes returns no results.

Project C:

• raw rollout count: 6
• SQLite thread count: 6
• app-server thread count: 6
• direct thread reads work
• one interrupted thread could be opened by id but was not searchable by its title.

Example symptom:

• read_thread(<thread_id>) succeeds and returns title/turns.
• list_threads(query=<exact title substring>) returns [] for the same thread.
• Pinning that thread id succeeds and may make it visible in the sidebar.

Timestamp / date display issue

The Desktop UI showed many historical conversations as updated within the last ~30 minutes. A SQLite check did not fully match that display:

• total threads in SQLite: 273
• updated within 30 minutes at the time of check: 1
• updated within 2 hours: 5
• top repeated updated_at values included older migration timestamps such as 2026-04-19 and 2026-04-18, plus a small repeated batch at 2026-06-05 09:42:03.

This suggests the UI may sometimes display a sidebar/index refresh time, project grouping metadata time, or app-server metadata time instead of the thread's own updated_at.

Why this seems like a bug

The underlying records are still present:

• raw rollout files exist
• SQLite threads.cwd rows exist
• direct reads by thread id work

But the Desktop sidebar/search and app-server project listing can hide or mis-date those same threads.

Expected behavior

For a local project cwd, if raw rollout files and SQLite agree, Codex Desktop / app-server should:

1. show the same non-archived local threads in the project sidebar, or explain the active filter;
2. find a thread by exact title substring in search;
3. show the thread's actual updated_at / creation date, not an index refresh time;
4. keep behavior stable after path migration and app restart.

Actual behavior

• Project sidebar and search are incomplete.
• Direct id-based reads work while title search fails.
• Date display can show old threads as recently updated.
• Restarting the app can partially change the visible set, suggesting cache/index instability.

Notes

I am not attaching raw session transcripts or app logs here because they may contain private local paths and conversation contents. I can provide sanitized diagnostics or submit feedback through the in-app /feedback flow if needed.