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
What version of the Codex App are you using (From “About Codex” dialog)?
26.429.20946
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64
What issue are you seeing?
After the last update or two, nearly all of my chat history was wiped from all projects. Went from dozens and dozens across many projects to maybe 7 total now.
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.
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.
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.
Activity
github-actions commentedon Apr 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
AndersAdmin commentedon May 2, 2026
I’m seeing what appears to be the same issue on Windows with WSL projects after a recent Codex Desktop update.
Environment:
/home/user1234/projects/Servicenowreports
\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports
Observed behavior:
Local data observations:
C:\Users\user.userlastname\.codex\state_5.sqlite, thethreadstable contains the old thread.archived = 0).\?\UNC\wsl.localhost\Ubuntu\home\user1234\projects\Servicenowreports
C:\Users\user.userlastname\.codex\sessions\2026\04\28\rollout-2026-04-28T23-56-20-019dd617-da60-76a2-a36f-d5ab72d3bc05.jsonl
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.
LeeeeTX commentedon May 10, 2026
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.
huajiexiewenfeng commentedon May 31, 2026
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.sqlitestill contain the missing sessions, but the Desktop app no longer shows them because local index, project/sidebar state, SQLitecwd, or exact path matching became inconsistent after an update.It starts with a dry-run, backs up before writing, and verifies the recovery afterward.