Codex Desktop project sidebar loses thread history when switching between Windows and WSL path views

Resolved 💬 2 comments Opened Jun 30, 2026 by M0M0KO Closed Aug 26, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

OS: Windows
Codex Desktop version: 26.623.9142.0
Projects are stored on a non-system drive
The same projects may be opened through both Windows paths and WSL paths

Problem

After a system crash/restart and later switching between Windows and WSL workspace views, Codex Desktop stops showing historical threads under the correct project in the sidebar.

The thread data is not deleted:

Search can still find the threads.
Raw session files still exist under ~/.codex/sessions.
SQLite indexes still contain thread rows.

However, the project sidebar shows no conversations, incomplete conversations, or conversations briefly appear and then disappear after background indexing.

Observed path mismatch

The same workspace can appear in several incompatible forms:

D:\Projects\ProjectA
/mnt/d/Projects/ProjectA
\\?\D:\Projects\ProjectA

In one case, Codex appeared to treat a Windows path as relative and prepended the app resources directory:

<Codex WindowsApps package>/app/resources/D:\Projects\ProjectA

This causes project/thread grouping to break.

Affected local state

The mismatch appears across:

~/.codex/sessions/*.jsonl
~/.codex/state_5.sqlite
~/.codex/sqlite/codex-dev.db
~/.codex/.codex-global-state.json

Examples of affected fields:

session_meta.cwd
turn_context.cwd
turn_context.workspace_roots
threads.cwd
local_thread_catalog.cwd
electron-saved-workspace-roots
active-workspace-roots
project-order

Expected behavior

Codex should canonicalize Windows drive paths, WSL /mnt/... paths, and \\?\ long-path-prefixed Windows paths as the same workspace when they refer to the same underlying folder.

It should also avoid prepending the app resources path to Windows-style cwd values.

Actual behavior

Threads are still searchable, but project sidebar grouping becomes unstable:

Some project histories disappear.
Some threads appear briefly and then vanish.
Background indexing seems to rewrite or reclassify paths inconsistently.

Why this matters

This looks like a path canonicalization/indexing issue rather than data loss. Users may think their history disappeared, while the raw session files and database rows are still present.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

#30288
#30435
#30385
#29366

Powered by Codex Action

M0M0KO · 1 month ago

Thanks. I reviewed the suggested issues.

This is related to #30288 and #30435, but I think it is not an exact duplicate.

The key difference here is that the same workspace is being indexed under multiple path identities across Windows and WSL views:

D:\Projects\ProjectA
/mnt/d/Projects/ProjectA
\\?\D:\Projects\ProjectA
<Codex WindowsApps package>/app/resources/D:\Projects\ProjectA

The visible symptom is that project history can briefly appear in the sidebar and then disappear again after background indexing. The raw session files and SQLite rows still exist, so this looks like a path canonicalization / local catalog rebuild issue rather than data loss.

#30435 looks closest for the malformed app/resources/...C:\... cwd issue, while #30288 looks closest for WSL path personality causing project chats to disappear. This issue adds the Windows drive <-> WSL /mnt/... <-> long-path-prefix mismatch across state_5.sqlite, codex-dev.db, .codex-global-state.json, and session JSONL metadata.