Codex Desktop project chat history disappears after update due to WSL cwd/path migration mismatch

[ThicccRacer]

Summary

Codex Desktop can show an empty project chat history even though local session files and state DB rows still exist. In this case, every project sidebar appeared empty except the current chat. The local repair showed two related migration/path compatibility problems after a Codex Desktop/app-server update:

1. state_5.sqlite and logs_2.sqlite contained _sqlx_migrations checksum rows from an older build. A fresh codex app-server from the installed binary refused to initialize with:

failed to initialize sqlite state db: failed to initialize state runtime at <CODEX_HOME>: migration 1 was previously applied but has been modified

2. Older sessions had cwd values persisted as Windows paths such as:

C:\Users\<user>\Documents\codex-projects\surfaceguru

When queried by the current WSL app-server, thread/list treated those Windows paths as relative strings and produced unusable cwd values like:

/mnt/c/Users/<user>/Documents/codex-projects/surfaceguru/C:\Users\<user>\Documents\codex-projects\surfaceguru

As a result, project-scoped thread/list queries returned data: [] even though matching rows and rollout files existed.

Environment

• Product: Codex Desktop
• Windows package observed: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0
• App-server / CLI: codex-cli 0.131.0-alpha.9
• App-server command: codex app-server --analytics-default-enabled
• WSL: Ubuntu 24.04
• CODEX_HOME: Windows user profile .codex, exposed in WSL as /mnt/c/Users/<user>/.codex
• Desktop app-server env included CODEX_INTERNAL_ORIGINATOR_OVERRIDE=Codex Desktop

User-visible symptom

• Project chat sidebar showed only the current chat.
• Previous chats under multiple projects were missing from the UI.
• Local data was not actually gone:
  • 47 local session .jsonl files existed.
  • session_index.jsonl existed.
  • state_5.sqlite contained thread rows.

Local diagnostic evidence

Direct app-server probe before migration checksum repair:

$ codex app-server --analytics-default-enabled
failed to initialize sqlite state db: failed to initialize state runtime at /mnt/c/Users/<user>/.codex: migration 1 was previously applied but has been modified

After matching _sqlx_migrations checksums against a clean state created by the same installed codex-cli 0.131.0-alpha.9, app-server initialized successfully.

Then thread/list exposed the path mismatch. Before cwd repair, querying the current project returned no history:

{"id":2,"method":"thread/list","params":{"archived":false,"cwd":"C:\\Users\\<user>\\Documents\\codex-projects\\surfaceguru","limit":20,"useStateDbOnly":true,"sourceKinds":["vscode","cli","appServer","unknown"]}}

Response:

{"id":2,"result":{"data":[],"nextCursor":null,"backwardsCursor":null}}

Unfiltered results contained malformed cwd values:

/mnt/c/Users/<user>/Documents/codex-projects/surfaceguru/C:\Users\<user>\Documents\codex-projects\surfaceguru

After converting persisted cwd values in both state_5.sqlite and session JSONL session_meta / turn_context payloads from Windows paths to WSL paths, project-scoped thread/list returned the expected chats:

surface project: 4
network project: 4
burbflix project: 31
burbflix-iptv project: 4
burbfinity project: 1
playground: 1

Example successful query after repair:

{"id":2,"method":"thread/list","params":{"archived":false,"cwd":"/mnt/c/Users/<user>/Documents/codex-projects/surfaceguru","limit":20,"useStateDbOnly":true,"sourceKinds":["vscode","cli","exec","appServer","subAgent","subAgentReview","subAgentCompact","subAgentThreadSpawn","subAgentOther","unknown"]}}

Response contained the expected 4 project threads.

Expected behavior

Codex Desktop should preserve and display existing project chat history across updates and across Windows/WSL execution mode changes. Older rollout files containing Windows-style cwd values should still match project filters, or should be migrated automatically.

Actual behavior

Older project chats became invisible in the sidebar. The app-server could read the files but project filtering failed because persisted Windows paths were interpreted relative to the current WSL cwd instead of normalized/canonicalized.

Suggested fix areas

• Add a startup/read-repair migration for persisted thread cwd values that canonicalizes Windows paths when running under WSL.
• Normalize both the query-side cwd filter and stored cwd before exact matching in thread/list.
• Avoid treating C:\... as a relative Unix path under WSL.
• Add defensive handling when _sqlx_migrations checksum metadata changes across packaged Desktop/app-server builds, especially for state_5.sqlite and logs_2.sqlite.
• Add a regression test with old Windows-style rollout cwd fields and WSL-style project cwd filters.

Privacy note

This report intentionally omits private chat content and uses redacted paths. The original local data contained normal project chat history; the important failure was path/state classification, not missing files.

[github-actions]

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

• Bug: Codex Desktop fails after enabling WSL #23927
• WSL CLI cannot share Windows Codex App CODEX_HOME: migration 1 was previously applied but has been modified #23251
• VS Code extension WSL agent fails when Windows and WSL share CODEX_HOME on C drive SQLite state #24348
• Codex Desktop on Windows no longer shows older chats after update #23193
• Codex Desktop conversations become empty and resume fails with stale Windows path #24178

Powered by Codex Action

[yui-stingray]

This looks consistent with a cwd normalization mismatch in the thread listing path. thread/list normalizes cwd filters with AbsolutePathBuf::relative_to_current_dir(...), so a legacy Windows-style cwd can be interpreted relative to the WSL cwd. When useStateDbOnly is used, the lookup then goes directly to exact threads.cwd matching and skips the scan-and-repair path that would normalize/backfill existing rows. That could make older sessions remain invisible until they are rewritten or repaired.

[huajiexiewenfeng]

This looks very close to the local recovery case I ran into, especially the path/cwd migration angle.

I collected my recovery workflow here:

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

It is an unofficial workaround, not an upstream fix. The workflow dry-runs first, checks session_index.jsonl, .codex-global-state.json, SQLite threads.cwd, exact UI cwd matching, and Windows/WSL-style path mismatches such as \\?\ prefixes. It backs up files before writing and verifies the recovery afterward.

The part that may be relevant here is the cwd_exact_match_risk check: in some cases the data is still present locally, but the Desktop UI cannot find it because the stored thread cwd and the visible project root do not match as exact strings.