Switching Codex from WSL to Windows-native breaks existing chats, rewrites /mnt/d paths as C:\mnt\d, and loses project associations
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.5k
- PR merge metrics
- PR metrics pending
Description
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
-
On Windows, configure Codex Desktop to use WSL as the Agent environment.
-
Open a project that physically resides on a Windows drive, for example:
D:\Programming\InvestPlanneraccessed from WSL as:
/mnt/d/Programming/InvestPlanner -
Create and use one or more long-running chats in that project while running under WSL.
-
Switch Codex Desktop Agent environment to Windows Native and restart the app.
-
Open one of the existing WSL-created chats.
-
The old chat remains visible, but sending any message fails with:
Invalid request: AbsolutePathBuf deserialized without a base path -
Create a brand-new chat in the same project under Windows Native.
-
The new chat works normally, confirming the Windows Native project itself is valid.
-
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.codexpathshost_skillsfile locationsshell = 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:
-
state_5.sqlitethreads.cwdthreads.sandbox_policy
-
.codex-global-state.jsonthread-writable-roots- workspace/project roots where applicable
-
sessions/**/rollout-*.jsonl- structured
turn_contextrecords - structured
world_staterecords - embedded WSL paths in filesystem / permission / host skill state
- structured
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:
-
Recognizes WSL drive mappings, for example:
/mnt/d/Programming/InvestPlanner -> D:\Programming\InvestPlanner -
Never converts WSL paths into malformed Windows paths such as:
C:\mnt\d\Programming\InvestPlanner -
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
-
Preserves project/sidebar association for existing chats.
-
Preserves all conversation history and accumulated context.
-
Validates the migrated paths before committing the migration.
-
Creates a backup / rollback point automatically.
-
Warns the user before switching execution environments if existing chats require migration.
-
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing environment-switch migration across state_5.sqlite, .codex-global-state.json, and sessions/**/rollout-*.jsonl, focusing on cwd, writable roots, sandbox paths, and rollout environment records. Verify how /mnt drive mappings are converted and how project associations are derived. Done means an atomic, validated migration preserves chat usability, history, and sidebar association without malformed paths, with backup or rollback support.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- sqlite
- Domain
- desktop-dev, devtools, operating-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100