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:
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:
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.
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 viaread_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
C:\Projects\ai-assistent~/.codex/session_index.jsonl~/.codex/sessions/2026/06/27/*.jsonl~/.codex/state_5.sqliteBROWSER_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
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:git status --short --branchreports:Evidence: sessions exist in
session_index.jsonlThe 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:Evidence: direct thread reads work
Directly reading those thread IDs works. For example,
read_threadfor019f0aaf-4ff1-7283-993f-c36fd4380f6ereturns:The same was true for P25, P27, and P28 thread IDs. They all have
cwd=C:\Projects\ai-assistentand completed final answers.Actual behavior
Project sidebar/search does not show these recent threads.
list_threadswithout a query returns the current thread and some older project threads, but omits the P24-P29 recent threads listed above.Search also misses them:
This is despite
read_thread(threadId=...)being able to load them directly.Expected behavior
Any local thread that:
~/.codex/sessions,~/.codex/session_index.jsonl,cwdunder a saved/active project root,read_threadshould 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:
Hypothesis: attachment-only / empty-preview threads may be written to
session_index.jsonland 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:
This report may be a duplicate, but it includes a concrete reproduction where the same thread IDs are present in
session_indexand readable by direct thread id whilelist_threads/search returns nothing.Suggested investigation points
list_threads,read_thread.cwd/ workspace root mapping is backfilled correctly for threads that arenotLoadedbut present insession_index.jsonl.session_index.jsonlandstate_5.sqliteafter long-running completed local threads and app restart.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.