Chat history disappeared from sidebar after app update

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #26157
• #26031
• #25500
• #25574
• #25084

Powered by Codex Action

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.

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/**/*.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.

Additional Windows datapoint (2026-08-02)

• Codex Desktop package: 26.727.6591.0
• 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.

Since the old conversations appear to remain locally accessible, this is a good index-vs-durable-data field case for codex-rescue==0.1.0a4.

If you still have the affected local state, could you try:

pipx install codex-rescue==0.1.0a4
codex-rescue sessions
codex-rescue doctor --latest

The diagnostic is read-only. It won’t repair the Desktop sidebar, but it can tell us whether the underlying rollout/session inventory is healthy while the UI index is missing entries.

A sanitized status/findings/count summary is enough. Please don’t post raw rollout files, SQLite databases, prompts, tool output, credentials, repository data, session IDs, or private paths.