Switching Codex from WSL to Windows-native breaks existing chats, rewrites /mnt/d paths as C:\mnt\d, and loses project associations

What issue are you seeing?

Switching the Codex Windows app from WSL execution to Windows-native execution breaks existing chats that were created while the agent environment was WSL.

The conversation history remains visible, and completely new chats created in the same Windows project work normally, but old chats cannot be continued. Sending any message in an affected chat fails with:

Invalid request: AbsolutePathBuf deserialized without a base path

The affected project physically lives on a Windows drive and was accessed from WSL through /mnt/d, so the WSL and Windows paths refer to the same folder:

WSL:     /mnt/d/Programming/InvestPlanner
Windows: D:\Programming\InvestPlanner

After switching the Agent environment to Windows Native, persisted chat state was only partially / incorrectly migrated. In particular, an affected thread was rewritten to the invalid Windows path:

C:\mnt\d\Programming\InvestPlanner

rather than:

D:\Programming\InvestPlanner

The broken path was confirmed in state_5.sqlite, and Codex tool execution logged:

CreateProcessAsUserW failed: 267 (The directory name is invalid.)
cwd=C:\mnt\d\Programming\InvestPlanner

The same chat also disappeared from the InvestPlanner project group in the sidebar and was only visible under Recent chats, despite the conversation itself remaining intact.

Steps to reproduce

1. On Windows, configure Codex Desktop to use WSL as the Agent environment.
2. Open a project that physically resides on a Windows drive, for example:

``text
D:\Programming\InvestPlanner
``

accessed from WSL as:

``text
/mnt/d/Programming/InvestPlanner
``

1. Create and use one or more long-running chats in that project while running under WSL.
2. Switch Codex Desktop Agent environment to Windows Native and restart the app.
3. Open one of the existing WSL-created chats.
4. The old chat remains visible, but sending any message fails with:

``text
Invalid request: AbsolutePathBuf deserialized without a base path
``

1. Create a brand-new chat in the same project under Windows Native.
2. The new chat works normally, confirming the Windows Native project itself is valid.
3. Inspect persisted local state for the old thread.

Persisted state observed

For one affected thread, the original rollout history contained WSL paths such as:

cwd = /mnt/d/Programming/InvestPlanner
workspace root = /mnt/d/Programming/InvestPlanner
visualization root = /mnt/c/Users/<user>/.codex/visualizations/...
shell = bash

After switching to Windows Native, state_5.sqlite -> threads.cwd contained:

C:\mnt\d\Programming\InvestPlanner

instead of:

D:\Programming\InvestPlanner

threads.sandbox_policy also retained the malformed path:

C:\mnt\d\Programming\InvestPlanner
C:\mnt\d\Programming\InvestPlanner\.git
C:\mnt\d\Programming\InvestPlanner\.agents
C:\mnt\d\Programming\InvestPlanner\.codex

.codex-global-state.json -> thread-writable-roots still contained WSL roots even after the project-level root had already become a Windows path:

project root:
D:\Programming\InvestPlanner

thread writable roots:
/mnt/d/Programming/InvestPlanner
/mnt/c/Users/<user>/.codex/visualizations/...

The rollout JSONL also retained WSL-specific environment state in turn_context and world_state, including:

• /mnt/d/Programming/InvestPlanner
• /mnt/c/Users/<user>/.codex/...
• workspace roots
• sandbox / permission paths
• .git, .agents, and .codex paths
• host_skills file locations
• shell = bash

Sidebar / project association problem

After partially correcting the old thread's cwd to:

D:\Programming\InvestPlanner

the conversation stopped appearing under the InvestPlanner project and was visible only in Recent chats.

The project-level state already used:

D:\Programming\InvestPlanner

while the thread still had WSL thread-writable-roots, so project/thread identity appears to depend on multiple independently persisted path representations.

Manual recovery that worked

The affected conversations were recoverable without losing chat history, but only after manually migrating all of the following persisted state while Codex was fully closed:

1. state_5.sqlite

• threads.cwd
• threads.sandbox_policy

1. .codex-global-state.json

• thread-writable-roots
• workspace/project roots where applicable

1. sessions/**/rollout-*.jsonl

• structured turn_context records
• structured world_state records
• embedded WSL paths in filesystem / permission / host skill state

Path conversion used:

/mnt/d/... -> D:\...
/mnt/c/... -> C:\...
C:\mnt\d\... -> D:\...

For a batch migration of the remaining chats, the local repair changed:

SQLite threads changed: 8
Global-state paths changed: 7
Session files changed: 8
Session records changed: 95
Session strings changed: 1261
Invalid JSON lines: 0

After all structured WSL path state was migrated to Windows-native paths, the previously broken chat could be continued again.

Expected behavior

Changing the Agent environment from WSL to Windows Native should not make existing chats unusable.

Codex should provide a supported migration / rebinding flow that:

1. Recognizes WSL drive mappings, for example:

``text
/mnt/d/Programming/InvestPlanner
->
D:\Programming\InvestPlanner
``

1. Never converts WSL paths into malformed Windows paths such as:

``text
C:\mnt\d\Programming\InvestPlanner
``

1. Migrates all persisted thread environment state atomically, including:

• cwd
• workspace roots
• writable roots
• sandbox / permission profiles
• rollout environment snapshots
• host skill paths
• shell/environment metadata

1. Preserves project/sidebar association for existing chats.
2. Preserves all conversation history and accumulated context.
3. Validates the migrated paths before committing the migration.
4. Creates a backup / rollback point automatically.
5. Warns the user before switching execution environments if existing chats require migration.
6. Ideally exposes a "Rebind / migrate this chat to the current project environment" action.

Additional information

This appears to be the inverse direction of #36608, which reports Windows-native -> WSL migration failures. This report is specifically WSL -> Windows Native.

The important distinction is that the affected repository is not inside the WSL Linux filesystem: it is a normal Windows-drive repository accessed from WSL through /mnt/d, so there is a deterministic mapping back to D:\....

The chat transcript data itself was not corrupted. The failure was caused by inconsistent execution-environment metadata spread across SQLite, global state, and rollout JSONL. A new Windows-native chat in the exact same project worked normally throughout.