You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Chat history disappeared from sidebar after app update #26236
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.601.21317
What subscription do you have?
Free
What platform is your computer?
windows
What issue are you seeing?
After updating the Codex desktop app, my previous chat history no longer appears in the app sidebar/history view. It looks like all previous conversations were wiped.
However, the threads may still exist internally: a new Codex thread was able to list older conversations such as Implement achievements feature, Redesign hero section, and others. So this appears to be a UI/sidebar/history indexing issue rather than actual data loss.
What steps can reproduce the bug?
Feedback ID: 019e8f08-ac5a-7aa3-8409-5baf622b2fe8
Have existing Codex chat history in the desktop app.
Update the Codex desktop app.
Reopen the app after the update.
Check the sidebar/chat history list.
Previous chats are missing from the visible history list.
What is the expected behavior?
After updating the app, all existing chat history should still appear in the sidebar/history list. Existing conversations should remain searchable and accessible without needing to recover them through backend/thread tools.
Additional information
The missing threads do not appear to be deleted. The app/backend can still access older thread records, but the sidebar does not show them. This suggests the issue may be related to local history indexing, filtering, migration after update, or sidebar state not loading previous threads correctly.
Adding impact/frequency data: this is not a rare one-off for me.
On June 3, 2026 alone, I had about 10 separate cases where I actively needed a missing thread and had to recover/surface it manually via exact ids, local state, deep links, pinning, or other workarounds.
That count is only the incidents I actively chased down. The broader problem appears larger: many repos now show no threads at all in Codex Desktop, even though local thread state/transcripts still exist. So the UI impact is not limited to those ~10 recovery events; those are just the ones that interrupted active work enough for me to investigate.
The pattern is consistent: the threads are not necessarily archived or deleted. The underlying local data remains present, but sidebar/search/project history fails to surface it reliably.
Impact: this is extremely disruptive for daily Codex Desktop use. It breaks trust in long-running work because I cannot rely on the app to show active conversations, and I keep spending time recovering threads instead of continuing work.
Hi everyone, I'm tracking the same Codex Desktop missing-thread/sidebar-history issue on macOS.
For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?
Examples I'm trying to distinguish:
official update fixed it
restart/reindex fixed it
codex resume --all <thread-id> rehydrated it
repairing session_index.jsonl / state_5.sqlite / .codex-global-state.json fixed it
Codex Wake or another local recovery helper fixed it
app bundle / listAllThreads patch fixed it
nothing worked yet
In my case, the missing project threads still exist in ~/.codex/sessions and state_5.sqlite, but Desktop does not hydrate them back into the project sidebar after restart. Any confirmed durable fix would help. Please do not share private session contents; sanitized method/results are enough.
@wangyaok1
i was able to recover the chat history by opening an existing project, you can do this by opening a new conversation and using the "add new project" button. This doesnt work for normal chats, only projects.
Adding a macOS datapoint after updating to the latest Desktop build.
Environment:
macOS 15.5 (24F74)
Apple Silicon / arm64
Codex Desktop: 26.608.12217
CFBundleVersion: 3722
Local storage: default ~/.codex
Recovery status on my affected project:
The update appears to have restored some previously missing threads.
It did not restore everything.
Older project threads are still missing from the Desktop sidebar/project history.
The local data still appears to exist. For the affected project, state_5.sqlite still has 251 active/non-archived rows with the expected project cwd.
Earlier checks also confirmed matching rollout JSONL/session files under ~/.codex/sessions.
So my current result is: 26.608.12217 looks like a partial recovery, not a full recovery. It would still be very helpful to have an official full local reindex/recovery command that rebuilds sidebar/project history from durable local state.
In my case the chats were not actually deleted. The session data was still there in .codex/sessions/, and the thread records were still in .codex/state_5.sqlite, but some Codex metadata/index fields were empty or missing, so the chats stopped showing up in the sidebar.
The script only tries to repair local metadata/index state, mostly around:
.codex/state_5.sqlite
.codex/session_index.jsonl
.codex/sessions/**/*.jsonl
Just to be clear: this is not an official fix and probably won’t solve cases where Codex keeps rewriting/breaking the project index after every restart. But if your local session JSONL files and SQLite records are still there and the sidebar just lost track of them, it may help.
After upgrading the Windows version of Codex Desktop to the latest release (26.721.31836), I encountered the same issue: the "Recent Tasks" list on the left is empty—displaying neither past nor new sessions—and restarting the application does not resolve the problem. However, these sessions can still be found via search, indicating that the local session data has not been lost. Troubleshooting confirmed that the local .codex data remains intact: the threads table in state_5.sqlite contains records, session files exist in the .codex\sessions directory, and the rebuilt session_index.jsonl includes the expected entries. Logs show information such as thread_count_loaded_recent: 6, yet requests related to the sidebar task list (e.g., /wham/tasks/list?limit=20&task_filter=current) are timing out or failing to return the list correctly. Therefore, this does not appear to be an issue of corrupted local history data; rather, it seems to be a regression introduced by the upgrade, affecting the loading logic for the "Recent Tasks" sidebar, task filtering, request timeout handling, or the migration process for web configuration files or sidebar state.
After updates/restarts, existing project threads are missing from the sidebar and projects can show no tasks, while the underlying local data remains present.
Sanitized local evidence:
state_5.sqlite: 168 thread records; 161 active/unarchived and 7 archived.
.codex/sessions: 161 local session files (~9.84 GiB).
session_index.jsonl: 6,663 bytes.
logs_2.sqlite: ~917 MiB and 38,041 log rows.
This suggests that core local state and transcripts remain intact while the desktop sidebar/catalog fails to hydrate or display them.
Two sanitized sidebar screenshots are available as a visual reproduction; raw session/database files and full logs are intentionally not attached because they may contain private conversation, command, and project data.
Please investigate whether the desktop sidebar/catalog can rebuild from the durable local thread/session state, and whether a supported reindex or repair command can be provided.
Activity
github-actions commentedon Jun 3, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
twentyOne2x commentedon Jun 4, 2026
Adding impact/frequency data: this is not a rare one-off for me.
On June 3, 2026 alone, I had about 10 separate cases where I actively needed a missing thread and had to recover/surface it manually via exact ids, local state, deep links, pinning, or other workarounds.
That count is only the incidents I actively chased down. The broader problem appears larger: many repos now show no threads at all in Codex Desktop, even though local thread state/transcripts still exist. So the UI impact is not limited to those ~10 recovery events; those are just the ones that interrupted active work enough for me to investigate.
The pattern is consistent: the threads are not necessarily archived or deleted. The underlying local data remains present, but sidebar/search/project history fails to surface it reliably.
Impact: this is extremely disruptive for daily Codex Desktop use. It breaks trust in long-running work because I cannot rely on the app to show active conversations, and I keep spending time recovering threads instead of continuing work.
wangyaok1 commentedon Jun 7, 2026
Hi everyone, I'm tracking the same Codex Desktop missing-thread/sidebar-history issue on macOS.
For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?
Examples I'm trying to distinguish:
codex resume --all <thread-id>rehydrated itsession_index.jsonl/state_5.sqlite/.codex-global-state.jsonfixed itlistAllThreadspatch fixed itIn my case, the missing project threads still exist in
~/.codex/sessionsandstate_5.sqlite, but Desktop does not hydrate them back into the project sidebar after restart. Any confirmed durable fix would help. Please do not share private session contents; sanitized method/results are enough.RogueMutant commentedon Jun 7, 2026
@wangyaok1
i was able to recover the chat history by opening an existing project, you can do this by opening a new conversation and using the "add new project" button. This doesnt work for normal chats, only projects.
wangyaok1 commentedon Jun 10, 2026
Adding a macOS datapoint after updating to the latest Desktop build.
Environment:
~/.codexRecovery status on my affected project:
state_5.sqlitestill has 251 active/non-archived rows with the expected project cwd.~/.codex/sessions.So my current result is: 26.608.12217 looks like a partial recovery, not a full recovery. It would still be very helpful to have an official full local reindex/recovery command that rebuilds sidebar/project history from durable local state.
gifgiif commentedon Jun 11, 2026
I hit something very similar and made a python script that helped me recover the missing chats locally:
https://github.com/gifgiif/codex-chat-metadata-repair
In my case the chats were not actually deleted. The session data was still there in
.codex/sessions/, and the thread records were still in.codex/state_5.sqlite, but some Codex metadata/index fields were empty or missing, so the chats stopped showing up in the sidebar.The script only tries to repair local metadata/index state, mostly around:
.codex/state_5.sqlite.codex/session_index.jsonl.codex/sessions/**/*.jsonlJust to be clear: this is not an official fix and probably won’t solve cases where Codex keeps rewriting/breaking the project index after every restart. But if your local session JSONL files and SQLite records are still there and the sidebar just lost track of them, it may help.
Dwp317 commentedon Jul 24, 2026
After upgrading the Windows version of Codex Desktop to the latest release (26.721.31836), I encountered the same issue: the "Recent Tasks" list on the left is empty—displaying neither past nor new sessions—and restarting the application does not resolve the problem. However, these sessions can still be found via search, indicating that the local session data has not been lost. Troubleshooting confirmed that the local
.codexdata remains intact: thethreadstable instate_5.sqlitecontains records, session files exist in the.codex\sessionsdirectory, and the rebuiltsession_index.jsonlincludes the expected entries. Logs show information such asthread_count_loaded_recent: 6, yet requests related to the sidebar task list (e.g.,/wham/tasks/list?limit=20&task_filter=current) are timing out or failing to return the list correctly. Therefore, this does not appear to be an issue of corrupted local history data; rather, it seems to be a regression introduced by the upgrade, affecting the loading logic for the "Recent Tasks" sidebar, task filtering, request timeout handling, or the migration process for web configuration files or sidebar state.Hhidysn commentedon Aug 1, 2026
Additional Windows datapoint (2026-08-02)
Please investigate whether the desktop sidebar/catalog can rebuild from the durable local thread/session state, and whether a supported reindex or repair command can be provided.