Chat History Deleted

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

• #19873
• #19290
• #19615
• #20254
• #20493

Powered by Codex Action

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.

We built a small open-source macOS tool for managing local Codex App/CLI conversation history:

https://github.com/LeeeeTX/codex-history-cleaner

It provides a terminal UI to list, search, preview, and delete local Codex sessions from ~/.codex. Deletion is recoverable by default with backups, and permanent deletion is also available with an extra confirmation step.

Hope this is useful for anyone who wants local controls for Codex history cleanup.

I ran into a similar class of issue after a Codex Desktop update, where the UI made it look like history was gone but local session data was still present.

I documented the recovery workflow I used here:

https://github.com/huajiexiewenfeng/codex-session-recovery

This is an unofficial workaround, not an upstream fix. It is intended for cases where sessions/**/*.jsonl / state_5.sqlite still contain the missing sessions, but the Desktop app no longer shows them because local index, project/sidebar state, SQLite cwd, or exact path matching became inconsistent after an update.

It starts with a dry-run, backs up before writing, and verifies the recovery afterward.