Windows desktop in WSL mode uses the Windows CODEX_HOME inside WSL and creates/stores worktrees on /mnt/c instead of the WSL filesystem

[matheuspimentaa]

What version of the Codex App are you using (From “About Codex” dialog)?

23.35.950

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

When Codex Desktop is installed on Windows and WSL mode is enabled, the WSL app-server inherits the Windows CODEX_HOME (C:\Users\<user>\.codex) instead of using a WSL-native home directory.

As a result, worktrees are resolved under /mnt/c/Users/<user>/.codex/worktrees/... even when the repository itself lives entirely inside WSL, for example under /home/<user>/Development/....

This causes two classes of problems:

1. Worktrees are created on the Windows-mounted filesystem instead of native WSL storage, which makes Git operations much slower.
2. The desktop app can keep stale references to Windows-side worktree paths even after the real worktree exists in WSL, which breaks branch/worktree/Git features intermittently.

During debugging I also saw related failures such as:

• WSL mode is enabled but no eligible distro is available
• SqliteError: database is locked
• failed to read CODEX_HOME ... os error 161 when trying to move the entire desktop CODEX_HOME to a WSL UNC path

What steps can reproduce the bug?

1. Install Codex Desktop from the Microsoft Store on Windows.
2. Enable WSL mode and select an Ubuntu distro.
3. Keep the repository inside WSL, for example /home/<user>/Development/Monest/monest-prompts.
4. Open that repository in Codex Desktop.
5. Use a Git feature that relies on worktrees, such as creating a worktree or selecting a Codex-managed branch/worktree.
6. Observe that the worktree path is resolved under /mnt/c/Users/<user>/.codex/worktrees/... instead of a WSL-native path.
7. In some cases, after restarting the app or moving state around, Git features start failing and the UI may still try to access the old Windows path even though the actual worktree is already in WSL.

What is the expected behavior?

When WSL mode is enabled, the WSL app-server should use a WSL-native Codex home/worktree root by default, separate from the Windows desktop app state.

Expected behavior:

• Worktrees should be created on the Linux filesystem, not under /mnt/c/..., when the repo is inside WSL.
• The app should not keep stale references to previous Windows-side worktree paths.
• Windows desktop state (for example SQLite/UI state) and WSL worktree storage should be handled separately so that fixing worktree location does not require moving the entire desktop database into WSL.

Additional information

Relevant paths from my machine:

• Repository root: /home/matheuspimenta/Development/Monest/monest-prompts
• Legacy Windows-side worktree path that the app still referenced: /mnt/c/Users/matheus.pimenta/.codex/worktrees/a923/monest-prompts
• Actual WSL worktree path that worked correctly: /home/matheuspimenta/.codex-app/worktrees/a923/monest-prompts

What I found while debugging:

• The desktop WSL app-server was launched with CODEX_HOME=/mnt/c/Users/matheus.pimenta/.codex.
• The reliable workaround was to override CODEX_HOME inside WSL only for Codex Desktop, using a conditional export in ~/.profile keyed on CODEX_INTERNAL_ORIGINATOR_OVERRIDE=Codex Desktop.
• After that, the WSL app-server used /home/matheuspimenta/.codex-app and worktrees resolved correctly on the Linux filesystem.
• I still needed a compatibility symlink for an old path because the desktop app had cached/referenced /mnt/c/Users/matheus.pimenta/.codex/worktrees/a923/monest-prompts.

This looks like the root issue:

• In WSL mode, the desktop app should not blindly propagate the Windows CODEX_HOME into the WSL runtime.
• The WSL runtime should choose a Linux-native default for worktrees and internal state, or at least split WSL worktree storage from Windows desktop state explicitly.

[github-actions]

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

• Codex App on Windows, when configured to use WSL, continues to reference the Windows-hosted config.toml #13549
• Codex App worktree creation fails for WSL-backed repos with "Failed to resolve worktree git directory" #13618
• WSL startup failure when /mnt/c automount disabled #13588
• Codex Windows crashed with WSL - WSL config location #13699

Powered by Codex Action

[phob]

The reliable workaround was to override CODEX_HOME inside WSL only for Codex Desktop, using a conditional export in ~/.profile keyed on CODEX_INTERNAL_ORIGINATOR_OVERRIDE=Codex Desktop.

How did you do that?

[mirumirumi]

I agree.
Opening a local repository in WSL certainly works, but it's ridiculous that I have to duplicate and manage the ~/.codex/* assets I've been using with Codex CLI for this app in C:\Users\my-name\.codex\ (and config.toml currently doesn't support an import feature).

[matheuspimentaa]

The reliable workaround was to override CODEX_HOME inside WSL only for Codex Desktop, using a conditional export in ~/.profile keyed on CODEX_INTERNAL_ORIGINATOR_OVERRIDE=Codex Desktop.

How did you do that?

I don't know, Codex did that for me.

[limitless10101]

I’m seeing a closely related Windows 11 + WSL issue that may be part of the same bug family, and it may also connect to #13721, #13764, and #14182.

Setup:

• Codex Desktop on Windows 11
• WSL agent enabled
• repo stored inside WSL on the Linux filesystem
• normal Git operations work from WSL terminal

Symptoms:

• Codex Desktop shows a very large red Git/review count (roughly -18000 / 126 files)
• the app is noticeably laggy
• staging, committing, and pushing still work normally from Git

What Git actually showed in the same checkout:

• git rev-parse --show-toplevel matched the expected WSL repo root
• git branch --show-current matched the active branch
• git worktree list showed only the current checkout
• git ls-files --others --exclude-standard | wc -l returned 0
• git diff --cached --shortstat showed only a small normal change set

So the large red desktop count did not match actual Git state in the checkout.

What I verified about the Codex environment:

• session metadata pointed to the same WSL workspace path
• shell snapshots showed CODEX_HOME resolving to a Windows-mounted path under /mnt/c/.../.codex
• WSLENV included CODEX_HOME/p, so CODEX_HOME was being forwarded from Windows into WSL

What I tried:

1. Added a conditional ~/.bashrc override so Codex Desktop in WSL would use a Linux-side CODEX_HOME
2. Verified that fresh interactive shells could see the Linux-side path
3. Added a local WSL codex wrapper that forced Linux-side CODEX_HOME and removed CODEX_HOME from WSLENV

Results:

• these workarounds helped confirm the env propagation problem
• but Codex Desktop still showed the phantom large red diff count and remained laggy

Current best diagnosis:

• there is a real Windows -> WSL CODEX_HOME propagation issue
• there is also a separate desktop review-state / Git-state problem, because the app’s red count does not match actual Git output in the same checkout
• the lag may be a related WSL-agent issue rather than repo dirtiness

This feels like the same broader Windows/WSL app bug cluster as:

• Codex App on Windows/WSL: targeted patch workflow is inconsistent, and review pane can show unstaged diffs while Git stays clean #13721 review pane/diff state mismatch
• Windows App: WSL agent causes severe lag when running threads (agent restart / high resource usage) #13764 severe lag with WSL agent
• Windows app shows "Create git repository" for valid WSL worktrees and does not show branch in thread #14182 incorrect Git/worktree state for valid WSL repos