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

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

• #13549
• #13618
• #13588
• #13699

Powered by Codex Action

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 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).

> 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.

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:

• #13721 review pane/diff state mismatch
• #13764 severe lag with WSL agent
• #14182 incorrect Git/worktree state for valid WSL repos

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

Did you figure it out? Are you currently able to use the Codex App in WSL, with the project located in the WSL filesystem, and when you create a worktree, does it get created inside WSL instead of Windows, in the mnt/c/ directory?

this is still a problem

Just wasted a couple hours on this this morning. Requested fixes:

1. The windows desktop app should automatically know that if execution environment is WSL, then any created worktrees must be on a WSL filesystem.
2. It would probably make sense to allow the user to easily configure their desired worktrees root in any event (separate from overall codex home)
3. I tried working around this with symlinks made from either windows or wsl side, but they both have problems. While many operations correctly traverse the symlink, the desktop app falsely warns the working directory does not exist, probably because it's doing some sort of naive string comparison on cwd.

One more note on impact, it's not just a performance issue. On my setup it is that the entire repo appears dirty immediately on creation due to the differing permissions implementations between wsl and windows.

Maybe there's a better workaround I just didn't reach in the two hours I invested, but my current conclusion is the windows desktop is not suitable for wsl use if you want the worktrees feature (which was the whole advantage for me over cli).

Guys this is genuinely a blocker for me to move to Codex

💯

Any update on this? I am also waiting to be able to select the CODEX_HOME within WSL2 in the Codex Windows Desktop App.

WSL integration seems to be rushed and buggy, accessing WSL files via windows path is slow, git work trees is broken, opening wsl terminal shows powershell icon, selecting agent environment option disappears randomly . It’s a real blocker , moving back to Claude code and copilot until codex fixes the issues . Vs code is the currently the best for wsl development from widows . Codex app features are very exciting but these issues are a real blocker , hope they fix it soon !

I can confirm a very similar problem on Windows + Codex Desktop + WSL.

Environment

1. Windows Codex Desktop installed on Windows
2. WSL enabled
3. Desktop app using WSL mode
4. Windows user profile path:

/mnt/c/Users/redde/.codex

1. Failing path reported by Codex:

/mnt/c/Users/redde/.codex/sessions

Error

Codex Desktop fails to create a thread with:

error creating thread: Fatal error: Codex cannot access session files at /mnt/c/Users/redde/.codex/sessions (permission denied). If sessions were created using sudo, fix ownership: sudo chown -R $(whoami) /mnt/c/Users/redde/.codex (underlying error: Operation not permitted (os error 1))

What I checked

1. takeown and icacls were applied on Windows side to C:\Users\redde\.codex
2. Windows ACLs now allow my user full access
3. From WSL, direct writes to the same path work fine

Example:

mkdir -p /mnt/c/Users/redde/.codex/sessions/test
touch /mnt/c/Users/redde/.codex/sessions/test/probe
printf 'ok\n' > /mnt/c/Users/redde/.codex/sessions/test/write.txt
ls -la /mnt/c/Users/redde/.codex/sessions/test

Output:

total 0
drwxrwxrwx 1 root root 512 Apr 21 10:50 .
drwxrwxrwx 1 root root 512 Apr 21 10:50 ..
-rwxrwxrwx 1 root root   0 Apr 21 10:50 probe
-rwxrwxrwx 1 root root   3 Apr 21 10:50 write.txt

So the directory is writable from WSL despite Codex Desktop reporting permission denied.

Mount info

/mnt/c is mounted as:

C: on /mnt/c type 9p (rw,relatime,aname=drvfs;path=C:;symlinkroot=/mnt/,cache=5,access=client,msize=65536,trans=fd,rfd=3,wfd=3)

Why this seems related to this issue

1. The app appears to inherit Windows CODEX_HOME into WSL
2. That resolves session/state paths under /mnt/c/Users/<user>/.codex
3. But the failure is not explained by simple filesystem write permissions, because manual WSL writes succeed
4. The user-facing remediation about sudo chown is misleading on /mnt/c/..., and in my case it does not address the problem at all

Likely implication

This looks like another case where Windows-side CODEX_HOME inside WSL is causing incorrect state/session handling, even when the underlying path is writable.

Useful direction

A Linux-native CODEX_HOME for WSL mode seems like the right model here as well, for example using a WSL-local path instead of /mnt/c/Users/<user>/.codex.

I found a workaround that made WSL mode stable for me on Windows.

1. Keep a separate Linux-side Codex home, for example:

/home/<user>/.codex-app

1. In WSL, override CODEX_HOME only when the shell is launched by Codex Desktop. I used this in ~/.profile:

if [ "${CODEX_INTERNAL_ORIGINATOR_OVERRIDE:-}" = "Codex Desktop" ]; then
  export CODEX_HOME="$HOME/.codex-app"
fi

1. If you use zsh, make sure login/non-interactive startup paths also see that:
2. ~/.zprofile:

. "$HOME/.profile"

1. ~/.zshenv can also source shared environment setup if needed.

1. Create the Linux-side directories up front:

mkdir -p ~/.codex-app/{sessions,tmp,worktrees}

1. Copy the basic Codex runtime files from the old WSL ~/.codex into ~/.codex-app:
2. config.toml
3. auth.json
4. AGENTS.md
5. agents/
6. skills/
7. rules/
8. prompts/

1. In the Windows app:
2. Agent environment = WSL
3. keep Integrated terminal shell = PowerShell

Using wsl there seemed to make the UNC-path side of this even more fragile.

1. Verify from WSL:

env CODEX_INTERNAL_ORIGINATOR_OVERRIDE='Codex Desktop' zsh -c 'echo $CODEX_HOME'

It should print:

/home/<user>/.codex-app

After this, worktrees started resolving under the Linux filesystem instead of /mnt/c/..., which fixed the main issue for me.

One extra note: the desktop app may still have stale cached references to old Windows-side worktree paths. In my case, the CODEX_HOME override fixed new worktrees, but I still had to clean up one old cached path separately.

So the workaround is real, but I still think the app should handle this automatically in WSL mode instead of propagating the Windows CODEX_HOME into the WSL runtime.

I’m surprised this hasn’t been fixed yet. WSL support is one of the few areas where Codex still feels significantly unreliable.

Codex has otherwise been very stable for me, even with the fast pace of new features, which is why this stands out. But the current CODEX_HOME / /mnt/c worktree behavior makes WSL feel only partially supported rather than a first-class environment.

A WSL-native default for worktrees/state, or a clearer separation between Windows desktop state and WSL runtime state, would make a big difference.

We need a native development experience similar to VS Code WSL Remote. All project file access should go through the native filesystem, while communication with the Windows Electron GUI happens over TCP.

I want to keep following this issue

I have solved this and a number of related issues by symlinking each repo directory from Windows to WSL, and referring to them by the WSL path only in my config.toml, not UNC. My CODEX_HOME lives on WSL and is also symlinked, that way I can run both the app and the CLI without issues.

@eschulma , can you explain more?
I tried doing the same but ran into database read error where the codex app on windows just does not like the sqlite locks in the codex_home in wsl

@Ramxnan I recommend having your agent help you, I did not have that particular issue. I put some notes on what I did in the Reddit r/codex group a day or two ago. Symlinking was the fundamental idea to fix the Got watcher bug. I want to be able to run both the CLI and the app, it was the simplest way.

I am struggling with a similar issue as well, although I can not fully tell if it's working correctly.

I keep having Windows tell me "Using a performance intensive operation like git on your windows drives will have poor performance. consider moving moving your project files to the linux file system..."

All of my code is checked out in linux. I am not even sure if I have git installed on the windows side, if I do it's unintentional. So something is misconfigured and not working correctly...

I can confirm this behavior on my setup as well.

Environment:

• Codex Desktop: 26.506.3741.0
• Windows: 10.0.26200.8246
• WSL: 2.6.3.0
• Distro: Ubuntu 24.04.4 LTS

In WSL mode, the running app-server inherited:

CODEX_HOME=/mnt/c/Users/<user>/.codex

and the app-server binary was launched from:

/mnt/c/Users/<user>/.codex/bin/wsl/codex app-server --analytics-default-enabled

Overriding CODEX_HOME inside WSL for Codex Desktop-launched sessions to:

/home/<user>/.codex-app

made startup noticeably better and keeps Codex runtime/worktree-related paths on the WSL ext4 filesystem instead of /mnt/c.

This matches the expected behavior described in the issue: WSL mode should default runtime/worktree state to a WSL-native location instead of using the Windows-side Codex home.

Additional current repro/evidence from Windows Desktop + WSL mode after a fresh reboot:

Environment:

• Codex Desktop package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• WSL: 2.7.3.0, kernel 6.6.114.1-1, Windows 10.0.26200.8457
• WSL app-server binary in session: /mnt/c/Users/<user>/.codex/bin/wsl/codex
• Codex CLI reported by that binary: codex-cli 0.130.0-alpha.5
• Desktop WSL mode enabled: runCodexInWindowsSubsystemForLinux=true
• Integrated terminal shell: wsl

Observed after reboot:

CODEX_HOME=/mnt/c/Users/<user>/.codex
cwd=/mnt/c/Users/<user>
PATH contains /mnt/c/Users/<user>/.codex/tmp/arg0/codex-arg0...
activeWorkspaceRoots=["C:\\Users\\<user>\\.codex"]
savedWorkspaceRoots include WSL UNC roots such as \\wsl.localhost\Ubuntu\home\<wsl-user>\...

The app shows the WSL filesystem performance warning on launch even when the actual repos are under /home/<wsl-user>/.... This appears to be because the WSL runtime itself is rooted through the Windows Codex home (/mnt/c/Users/<user>/.codex) before any project-specific work starts.

I tested the common workaround of forcing Codex Desktop-launched WSL shells to use a WSL-native CODEX_HOME, e.g. /home/<wsl-user>/.codex-app, by guarding on CODEX_INTERNAL_ORIGINATOR_OVERRIDE=Codex Desktop. It does move runtime state toward ext4 and is consistent with the workaround discussed above, but I reverted it because it creates risky split-brain behavior:

• Windows Desktop UI/settings still operate around C:\Users\<user>\.codex.
• WSL app-server runtime starts reading/writing /home/<wsl-user>/.codex-app.
• Auth/config/skills/plugins/session state can drift unless manually synced.
• Future Desktop updates may assume the Windows-managed Codex home layout and clobber or bypass the WSL-side home.

So I agree with the requested product fix: WSL mode needs first-class separation of Windows Desktop UI state from WSL-native runtime/worktree/cache state, not a user shell-profile override. At minimum, Desktop should expose an explicit WSL runtime/worktree root setting and show which config/home is authoritative.

I found a workaround that made WSL mode stable for me on Windows. 1. Keep a separate Linux-side Codex home, for example: /home/<user>/.codex-app 2. In WSL, override CODEX_HOME only when the shell is launched by Codex Desktop. I used this in ~/.profile: if [ "${CODEX_INTERNAL_ORIGINATOR_OVERRIDE:-}" = "Codex Desktop" ]; then export CODEX_HOME="$HOME/.codex-app" fi 3. If you use zsh, make sure login/non-interactive startup paths also see that: 1. ~/.zprofile: . "$HOME/.profile" 2. ~/.zshenv can also source shared environment setup if needed. 3. Create the Linux-side directories up front: mkdir -p ~/.codex-app/{sessions,tmp,worktrees} 5. Copy the basic Codex runtime files from the old WSL ~/.codex into ~/.codex-app: 1. config.toml 2. auth.json 3. AGENTS.md 4. agents/ 5. skills/ 6. rules/ 7. prompts/ 6. In the Windows app: 1. Agent environment = WSL 2. keep Integrated terminal shell = PowerShell Using wsl there seemed to make the UNC-path side of this even more fragile. 7. Verify from WSL: env CODEX_INTERNAL_ORIGINATOR_OVERRIDE='Codex Desktop' zsh -c 'echo $CODEX_HOME' It should print: /home/<user>/.codex-app After this, worktrees started resolving under the Linux filesystem instead of /mnt/c/..., which fixed the main issue for me. One extra note: the desktop app may still have stale cached references to old Windows-side worktree paths. In my case, the CODEX_HOME override fixed new worktrees, but I still had to clean up one old cached path separately. So the workaround is real, but I still think the app should handle this automatically in WSL mode instead of propagating the Windows CODEX_HOME into the WSL runtime.

@timurkhakhalev, thanks!

You helped me to solve terrible a performance of the Codex App.

For me it was not just about working trees. It was, that bad, that if you ask a simple question like what is your cwd, - it took 15 seconds, compared to 5 seconds in the Codex VS Code extension.

I have, however, made some different setup from yours.

1)

cp -r ~/.codex ~/codex-app && \
cat <<'EOF' >> ~/.profile

if [ "${CODEX_INTERNAL_ORIGINATOR_OVERRIDE:-}" = "Codex Desktop" ]; then
   export CODEX_HOME="$HOME/.codex-app"
fi
EOF

2) In Codex App Settings set: Agent environment = WSL && Integrated terminal shell = WSL

3) Restart Codex App and ask via chat: what is your CODEX_HOME?
3.1) (optional step, because I forgot, if I have done it) If it is not $HOME/.codex-app, but old (windows). Then exit from Codex App & open PowerShell and: wsl --shutdown, then wsl
3.2.) Try step 2 again.

Now Codex App is usable in terms of speed - same as VS Code Codex.

A big problem with using WSL instead of Windows Native for the desktop runtime, that came up after this issue was created: You lose access to the plugins for Browser and Chrome within the entire app. Those are very high value.

As a result, I've gone back to Windows Native. I could create the WSL repo project by pasting in the network path directly, and you also need to explain to the app how to interact with it using wsl.exe. I still can't use the browser plugins within that particular project, but at least it's available elsewhere.

A big problem with using WSL instead of Windows Native for the desktop runtime, that came up after this issue was created: You lose access to the plugins for Browser and Chrome within the entire app. Those are very high value. As a result, I've gone back to Windows Native. I could create the WSL repo project by pasting in the network path directly, and you also need to explain to the app how to interact with it using wsl.exe. I still can't use the browser plugins within that particular project, but at least it's available elsewhere.

No. You can call the relevant software directly by using pwsh.exe

pwsh.exe -Command "Start-Process 'C:\Program Files\Google\Chrome\Application\chrome.exe'"

OpenAI could definitely support this.

> A big problem with using WSL instead of Windows Native for the desktop runtime, that came up after this issue was created: You lose access to the plugins for Browser and Chrome within the entire app. Those are very high value. > As a result, I've gone back to Windows Native. I could create the WSL repo project by pasting in the network path directly, and you also need to explain to the app how to interact with it using wsl.exe. I still can't use the browser plugins within that particular project, but at least it's available elsewhere. No. You can call the relevant software directly by using pwsh.exe `` pwsh.exe -Command "Start-Process 'C:\Program Files\Google\Chrome\Application\chrome.exe'" `` OpenAI could definitely support this.

Oh, I can start it, sure. But that's not the same as high-level fast control. A few times I even had the agent install software and modify registry keys to get it working -- only to have it break with the next update.

Windows is already a second-class citizen for the app. WSL in Windows is even farther down.