Codex Desktop project chat histories disappeared after recent update

[GGBondBlueWhale]

What version of the Codex App are you using (From “About Codex” dialog)?

26.429.30905 (2345)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS Tahoe 26.4.1
MacBook Pro 16-inch, Apple M5 Max, 128 GB memory

What issue are you seeing?

After what appears to be a recent Codex Desktop update today, almost all of my project chat histories disappeared from the sidebar.

The projects themselves are still listed, but most of them now show No chats. Only one main project still shows its previous conversation history. Before the update/restart, those other projects had existing conversation history.

This looks like a local history/indexing or migration issue rather than an intentional project deletion, because the project entries still exist while their associated conversations are missing from the UI.

Observed sidebar state from my screenshot:

• GGame still shows recent conversations
• CloudKitAdminPlatform shows No chats
• RaspberryPi shows No chats
• weighted-wheel shows No chats
• WAN Project shows No chats
• CodexAutoSwitcher shows No chats
• regular Chats also shows No chats

This is high impact because those missing project conversations contain important development context and task history.

What steps can reproduce the bug?

I do not yet have a deterministic repro, but this is what happened:

1. Use Codex Desktop with multiple projects that already have chat history.
2. Receive/apply the recent Codex Desktop update, or reopen Codex after the update.
3. Open Codex Desktop again.
4. Check the left sidebar project list.
5. Observe that most projects are still present but their chat histories are gone / shown as No chats.
6. Only one main project still shows previous conversations.

What is the expected behavior?

All existing project conversations should remain visible and searchable after a Codex Desktop update or app restart.

Specifically:

• Updating/restarting Codex should not hide or remove project chat histories.
• Existing projects should continue to show their associated conversations.
• If this is an indexing problem, there should be a safe way to re-index/recover the local project conversations.

Additional information

I have screenshots showing:

1. The sidebar state where only one project still has conversations while the other projects show No chats.
2. The Codex Desktop About dialog showing version 26.429.30905 (2345).
3. The macOS system information showing macOS Tahoe 26.4.1 and MacBook Pro Apple M5 Max.

Please investigate whether this is a UI/sidebar indexing bug, local migration issue, or possible data-loss problem. Also, please advise whether there is a safe recovery/re-indexing procedure for the missing project conversations.

Possibly related to prior local-thread/sidebar visibility issues, but this report is for Codex Desktop on macOS and affects project-level chat history after the latest update/restart.

[github-actions]

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

• Desktop project sidebar shows No chats after Symphony automation creates many threads #20187
• macOS Desktop sidebar hides older local conversations despite existing thread state #20419
• Chat History Deleted #20506
• Windows Desktop: Sidebar shows No chats and no projects after update, but Search can still find/open existing chats #19290
• Codex Windows app and VS Code extension memory usage climbs above 10GB after update #19381

Powered by Codex Action

[GGBondBlueWhale]

Additional urgency note: please fix this as soon as possible. I currently cannot see the histories for my other Codex projects, so I cannot continue working in those projects with the required previous context. A safe recovery or re-indexing procedure would also help if the underlying data still exists locally.

[vishkrish200]

This looks very similar to what I hit in #20493. In my case the chats were not actually deleted; they still existed on disk/in SQLite, but Codex Desktop stopped treating them as visible sidebar chats after the update/import path.

I documented the fuller recovery here: #20493 (comment)

Quick thing to check

Before changing anything, make a backup:

backup_dir="$HOME/.codex/chat-metadata-repair-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$backup_dir"

sqlite3 "$HOME/.codex/state_5.sqlite" ".backup '$backup_dir/state_5.before.sqlite'"
cp "$HOME/.codex/.codex-global-state.json" "$backup_dir/codex-global-state.before.json"

Then check whether your hidden chats have the same broken metadata pattern:

sqlite3 "$HOME/.codex/state_5.sqlite" "pragma integrity_check;"

sqlite3 "$HOME/.codex/state_5.sqlite" \
  "select cwd, source, has_user_event, count(*)
   from threads
   where archived=0
     and first_user_message <> ''
     and (has_user_event=0 or source='exec')
   group by cwd, source, has_user_event
   order by count(*) desc, cwd;"

If that returns your missing project roots, this may be the same issue.

Repair that worked for me

This only touches active rows with a real first user message. It does not unarchive everything:

sqlite3 "$HOME/.codex/state_5.sqlite" "
begin immediate;

update threads
set has_user_event=1
where archived=0
  and first_user_message <> ''
  and has_user_event=0
  and source in ('vscode', 'cli', 'exec');

update threads
set source='vscode'
where archived=0
  and first_user_message <> ''
  and source='exec';

commit;

pragma wal_checkpoint(full);
pragma integrity_check;
"

After this, refresh/restart Codex Desktop. In my case a normal UI refresh was enough once the metadata was repaired.

If the chats exist but still appear under the wrong project, also inspect ~/.codex/.codex-global-state.json, especially:

• thread-workspace-root-hints
• project-order
• electron-saved-workspace-roots

The short version: the data may still be there, but rows with first_user_message <> '' can end up with has_user_event=0 or source='exec', and then Desktop seems to hide them from the normal project sidebar.

[GGBondBlueWhale]

@vishkrish200 Thank you very much. I will try this.

That said, I still think the Codex team should treat this as a real bug and fix it seriously. Users should not have to manually repair local SQLite metadata just to recover visible project chat history after an update.

[souljorje]

Faced the same. Not available in app sidebar, but visible in cli.
Resumed chat with cli -> sent a message -> chat reappeared in app sidebar.

macOS 15

[AndersAdmin]

I’m seeing what appears to be the same issue on Windows with WSL projects after a recent Codex Desktop update.

Environment:

Codex Desktop on Windows
Project is inside WSL:
/home/user1234/projects/Servicenowreports
Same project is also accessible from Windows as:
\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports
Observed behavior:

The project still appears in the Codex Desktop project/sidebar UI.
The old project chats do not appear under the project chat list.
Switching/opening the project via the alternate WSL/UNC path did not restore the old project chat list.
However, in-app Search still finds the old chat title.
Clicking the old chat from Search opens the thread successfully, and the assistant can respond in that old thread.
Even after sending a new message in that old thread, it still does not reappear in the project chat list/sidebar.
Local data observations:

The old thread still exists in the local Codex database.
In C:\Users\user.userlastname.codex\state_5.sqlite, the threads table contains the old thread.
The thread is not archived (archived = 0).
The old thread has this cwd:
?\UNC\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports
The rollout/session file still exists at:
C:\Users\user.userlastname.codex\sessions\2026\04\28\rollout-2026-04-28T23-56-20-019dd617-da60-76a2-a36f-d5ab72d3bc05.jsonl
The thread title is:
Planera ServiceNow-rapportimport
This suggests the chat data itself is still present and loadable, but the project chat list/sidebar no longer associates existing threads with the project correctly. It looks more like a project/thread indexing or path normalization regression than actual data loss.

One possible contributing factor is WSL path identity/normalization. The current workspace may appear as:
/home/user1234/projects/Servicenowreports
while older stored threads use:
?\UNC\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports

But opening the project through the alternate path did not fix the project chat list.

Additional observation: the project files also no longer appear correctly in the Codex Desktop UI, even though they still exist in WSL and the agent can read them from /home/user1234/projects/Servicenowreports. In one resumed thread, the cwd appeared malformed, combining the Windows app resources path with the WSL UNC path:
/mnt/c/Program Files/WindowsApps/OpenAI.Codex_.../app/resources/\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports

This suggests the issue may affect project root/path resolution, not only chat history listing.