codex - 💡(How to fix) Fix Codex Desktop project threads disappear from project views/search while session JSONL remains readable

Summary

Codex Desktop can silently hide local project conversations from the project page and search even though the underlying conversation data still exists on disk and can be read/resumed. In the latest case, a saved RSSHub project appeared empty in the Desktop UI, but four ~/Code/RSSHub threads were still present in ~/.codex/sessions, present in state_5.sqlite, and readable by thread id. After manually refreshing local metadata/index files, the same four threads became visible again.

This looks like a local Desktop indexing/listing consistency bug rather than deleted conversation data.

Related issues I found before filing this: #21581, #22592, #22452, #23979, #23825.

Environment

• OS: macOS 26.5 (25F71)
• Codex Desktop app: 26.527.31326
• Codex CLI: 0.135.0-alpha.1
• Local state involved:
  • ~/.codex/sessions/**/*.jsonl
  • ~/.codex/session_index.jsonl
  • ~/.codex/state_5.sqlite
  • ~/.codex/.codex-global-state.json

What happened

Several saved project histories disappeared from the Desktop UI, including projects such as jitashe, RSSHub, Folo, and LeanRead.

The most concrete reproduction was RSSHub:

• The Desktop project page for ~/Code/RSSHub appeared empty.
• Searching for rsshub, 公众号, route, or Panwiki did not show the expected RSSHub conversations.
• A general thread list also did not surface those project threads.
• However, direct thread reads by id still worked, and the threads showed cwd: ~/Code/RSSHub.

Example affected thread ids:

019e30d8-7eac-7bc1-ac2f-0ced04035720  RSSHub / WeChat subscription discussion
019e16c8-3959-7432-970f-4f687708ad2c  RSSHub source update delay investigation
019e11b7-ae2e-71d1-ae6e-44d8953dff50  RSSHub custom route dashboard discussion
019e1182-e46e-75a3-bae2-ff9dae7a2fa1  RSSHub Panwiki login/cookie route discussion

Evidence that the data was not lost

The affected RSSHub threads were still available in local source files and local state:

• Matching rollout JSONL files existed under ~/.codex/sessions/....
• state_5.sqlite contained rows for those thread ids with:
  • cwd = ~/Code/RSSHub
  • archived = 0
  • valid titles/previews
  • valid rollout paths
• Reading the threads directly by id returned their turn history and cwd: ~/Code/RSSHub.
• codex resume <thread_id> remained a reliable fallback for continuation.

This means the UI/search/project listing was stale or inconsistent while the canonical conversation data still existed.

Manual recovery that made the threads visible again

After manually refreshing local metadata, the RSSHub threads immediately became visible in Desktop search and recent thread listing.

The recovery touched these local pieces of state:

1. Added/normalized thread_source: "user" in RSSHub session metadata.
2. Appended a metadata-only task_complete event tied to a real existing turn id, so the thread looked recently completed without changing conversation content.
3. Updated state_5.sqlite for the affected rows:
   • cwd = ~/Code/RSSHub
   • thread_source = user
   • refreshed updated_at / updated_at_ms
   • archived = 0
4. Refreshed ~/.codex/session_index.jsonl rows for the same thread ids.
5. Added workspace hints for the thread ids in ~/.codex/.codex-global-state.json.

After that, searching rsshub returned the four RSSHub threads again, and the unfiltered recent list also showed them.

Expected behavior

If a local session JSONL file exists, state_5.sqlite points to it, the thread is not archived, and its cwd belongs to a saved project, Codex Desktop should show it in the corresponding project history and search results.

At minimum, Desktop should provide a reliable local reindex/repair path so the UI cannot get stuck showing an empty project while the sessions are still recoverable on disk.

Actual behavior

The Desktop UI/project list/search can show an empty or incomplete project history even when:

• the session files still exist,
• SQLite rows still exist,
• the thread can be read directly by id,
• and codex resume <thread_id> can still continue the thread.

Why this is harmful

From a user perspective, it looks like conversation history was deleted. In reality the data is still present locally, but the UI makes it undiscoverable. This is especially risky for long-running local project work because users may start duplicate threads, lose project context, or assume data loss.

Suggested fixes

• Make Desktop project/search listing rebuild from ~/.codex/sessions/**/*.jsonl when local indexes are stale.
• Detect and repair drift between session_index.jsonl, state_5.sqlite, and .codex-global-state.json.
• Avoid relying on metadata-only recency/index fields to decide whether an existing local project thread is visible.
• Add a user-facing "Reindex local conversations" command or automatic repair when a saved project appears empty but matching sessions exist on disk.
• Consider showing a warning if a project has session files on disk but zero visible threads in the UI.