Codex Desktop: recent local project threads are missing from sidebar/search although session_index and read_thread can load them

Summary

Codex Desktop on Windows is not showing several recent local project threads in the project sidebar or thread search, even after multiple app restarts. The threads are not lost: they exist on disk, are present in ~/.codex/session_index.jsonl, and can be loaded directly by thread id via read_thread. However, list_threads / sidebar search does not return them.

This looks like a stale or divergent local sidebar/search index rather than data loss.

Environment

• OS: Windows
• Codex surface: Codex Desktop app
• Observed date: 2026-06-28, timezone Europe/Prague
• Workspace/project root: C:\Projects\ai-assistent
• Active local Codex state files observed:
• ~/.codex/session_index.jsonl
• ~/.codex/sessions/2026/06/27/*.jsonl
• ~/.codex/state_5.sqlite
• App/plugin version signal observed in local config: BROWSER_USE_CODEX_APP_VERSION = "26.623.42026"

Impact

The project sidebar makes it look like the last ~12 hours of work/chats are missing, even though the underlying sessions and repository changes exist. This is confusing and risky because the user may believe work was lost or may repeat work unnecessarily.

What I already tried

• Restarted Codex Desktop several times.
• Reopened the same project.
• Verified that the repository work itself is intact.
• Verified local session/index evidence.

The problem persists after restart.

Evidence: repository work exists

In the local project C:\Projects\ai-assistent, the last ~12 hours of work produced real commits and current-state docs. For example:

786cb16b 2026-06-27 22:56:34 +0200 Record P29 privacy tuning evidence
4d80f9a2 2026-06-27 22:44:32 +0200 Implement P29 privacy gate tuning and canary closure
e7985dd8 2026-06-27 21:51:54 +0200 Record P28 canary expansion evidence
77320902 2026-06-27 21:44:17 +0200 Implement P28 controlled provider canary expansion
27efbe3a 2026-06-27 20:00:30 +0200 Record P27 DGX provider canary evidence
d4f00301 2026-06-27 19:52:09 +0200 Pass P27 canary config through DGX app compose
1a83ed01 2026-06-27 19:44:26 +0200 Implement P27 provider canary gate
444bf496 2026-06-27 17:27:44 +0200 Record P25 deploy evidence
95e9670a 2026-06-27 17:19:55 +0200 Implement P25 offline cloud handoff review
75ba8ec4 2026-06-27 14:49:55 +0200 Record P24 deploy evidence
65586d1c 2026-06-27 14:25:36 +0200 Implement P24 durable fulfillment and local faithfulness

git status --short --branch reports:

## main...origin/main

Evidence: sessions exist in session_index.jsonl

The following entries are present in ~/.codex/session_index.jsonl:

[
  {
    "id": "019f0986-2794-7af1-aad1-8c96afb880f1",
    "thread_name": "Dokonči P25 offline handoff",
    "updated_at": "2026-06-27T14:40:24.2132668Z"
  },
  {
    "id": "019f0a0c-f555-7523-a9c2-e692ebd9106a",
    "thread_name": "Implementuj P27 canary approval",
    "updated_at": "2026-06-27T17:07:41.8963268Z"
  },
  {
    "id": "019f0a7a-bf7d-7ac2-8f3a-d5a9cde3dd83",
    "thread_name": "Implementovat P28 canary rozšíření",
    "updated_at": "2026-06-27T19:07:33.7527505Z"
  },
  {
    "id": "019f0aaf-4ff1-7283-993f-c36fd4380f6e",
    "thread_name": "Implementovat P29 privacy tuning",
    "updated_at": "2026-06-27T20:04:57.4723878Z"
  }
]

Corresponding JSONL files also exist under ~/.codex/sessions/2026/06/27/, for example:

~/.codex/sessions/2026/06/27/rollout-2026-06-27T22-04-54-019f0aaf-4ff1-7283-993f-c36fd4380f6e.jsonl
~/.codex/sessions/2026/06/27/rollout-2026-06-27T21-07-29-019f0a7a-bf7d-7ac2-8f3a-d5a9cde3dd83.jsonl
~/.codex/sessions/2026/06/27/rollout-2026-06-27T19-07-34-019f0a0c-f555-7523-a9c2-e692ebd9106a.jsonl

Evidence: direct thread reads work

Directly reading those thread IDs works. For example, read_thread for 019f0aaf-4ff1-7283-993f-c36fd4380f6e returns:

id: 019f0aaf-4ff1-7283-993f-c36fd4380f6e
title: Implementovat P29 privacy tuning
status: notLoaded
cwd: C:\Projects\ai-assistent
createdAt: 2026-06-27 22:04:54 +02:00
updatedAt: 2026-06-27 22:57:12 +02:00
turn status: completed
final answer present

The same was true for P25, P27, and P28 thread IDs. They all have cwd=C:\Projects\ai-assistent and completed final answers.

Actual behavior

Project sidebar/search does not show these recent threads.

list_threads without a query returns the current thread and some older project threads, but omits the P24-P29 recent threads listed above.

Search also misses them:

list_threads(query="P29") -> []
list_threads(query="Implementovat P28") -> []
list_threads(query="Dokonči P25") -> []
list_threads(query="Implementuj P27") -> []

This is despite read_thread(threadId=...) being able to load them directly.

Expected behavior

Any local thread that:

• exists under ~/.codex/sessions,
• is present in ~/.codex/session_index.jsonl,
• has cwd under a saved/active project root,
• is not archived,
• and can be loaded by read_thread

should appear in the corresponding project sidebar and be discoverable by thread search after restart.

Possible contributing factor

The missing recent threads were created from requests where the user supplied the main prompt as an attached/pasted text file. In read_thread, the initial user message is attachment-oriented, and the thread preview can be empty even though the generated title is present.

Example initial user message shape, paraphrased:

The attached pasted text file(s) contain the user's request. Read and act on that content.

Hypothesis: attachment-only / empty-preview threads may be written to session_index.jsonl and readable by id, but omitted from the sidebar/search index or hydration query.

Related issues that may be connected

I found several possibly related open issues while checking for duplicates:

• #22452
• #25500
• #26634
• #27159
• #27314
• #29130
• #29550

This report may be a duplicate, but it includes a concrete reproduction where the same thread IDs are present in session_index and readable by direct thread id while list_threads/search returns nothing.

Suggested investigation points

• Compare the data sources used by:
• project sidebar hydration,
• list_threads,
• thread search,
• direct read_thread.
• Check whether attachment-only threads or empty-preview threads are filtered out.
• Check whether cwd / workspace root mapping is backfilled correctly for threads that are notLoaded but present in session_index.jsonl.
• Check for drift between session_index.jsonl and state_5.sqlite after long-running completed local threads and app restart.
• Consider adding a repair/reindex action for local Desktop thread/sidebar state.

Workaround

If the user knows the thread ID, direct thread loading works. But the normal UI/sidebar/search path is currently not enough to discover the affected threads.