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

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.