›_ Codex Issues
Codex Issues / #26149

Codex Desktop on Windows + WSL repeatedly scans .codex/.tmp/plugins over /mnt/c, causing severe per-command latency

Open 💬 10 comments Opened Jun 3, 2026 by fcrhu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop on Windows with a WSL project is extremely slow for every command/tool invocation.

This does not appear to be caused by WSL itself, the repository, Git, Node, .NET, or shell startup. The same project is fast when using Codex CLI directly inside WSL.

Using strace on the WSL codex app-server process shows that a large share of file/process syscalls repeatedly touch the Desktop plugin cache under:

/mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins

This suggests that Codex Desktop WSL mode repeatedly scans plugin/cache files over /mnt/c, causing severe latency.

Environment

  • Codex Desktop version: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
  • Codex CLI version: codex-cli 0.136.0
  • OS: Windows + WSL
  • WSL distro: Ubuntu 26.04
  • Project opened from WSL path:

\\wsl$\Ubuntu\home\<WslUser>\repos\<RepoName>

  • Repository path inside WSL:

/home/<WslUser>/repos/<RepoName>

Observed behavior

Codex Desktop in WSL mode is extremely slow for every command/tool invocation, not only during initial startup.

Even simple read-only prompts take a long time before or between shell commands. The same repository is fast when using Codex CLI directly inside WSL.

The WSL codex app-server process runs as:

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

Its process environment includes Windows-backed paths:

CODEX_HOME=/mnt/c/Users/<WindowsUser>/.codex
TEMP=/mnt/c/Users/<WindowsUser>/AppData/Local/Temp
TMP=/mnt/c/Users/<WindowsUser>/AppData/Local/Temp
PWD=/mnt/c/Program Files/WindowsApps/OpenAI.Codex_<version>/app/resources

What was ruled out

WSL itself is fast:

wsl.exe --exec /bin/true: ~0.1s

Interactive Bash startup is fast after fixing unrelated shell initialization:

bash -i -c "exit": ~0.35s

Git is fast:

git status -sb: ~0.2s

Repository traversal is fast when excluding known heavy/generated folders:

find excluding node_modules, .angular/cache, bin, obj, etc.: ~0.35s

Backend and frontend builds complete successfully inside WSL.

Codex CLI directly inside WSL is fast on the same project.

Plugin cache details

The Desktop plugin cache under /mnt/c contains thousands of files/directories:

Path: /mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins
Size: ~38 MB
Files: ~4,646
Directories: ~2,400

Previously the cache was approximately:

Size: ~55 MB
Files: ~4,675
Directories: ~2,411

Temporarily renaming this directory made Codex Desktop faster, but after restart/re-scan the latency returned.

strace evidence

While Codex Desktop was slow, I attached strace to the WSL codex app-server process:

sudo timeout 20 strace -f -tt -T \
  -e trace=file,process \
  -p <codex-app-server-pid> \
  -o /tmp/codex-strace-plugins.log

Summary from a 20-second sample:

total file/process syscall lines: 17,481
lines touching /mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins: 7,426
lines touching actual repo under /home/<WslUser>/repos/<RepoName>: 569

So around 42% of logged file/process syscalls touched the Codex plugin cache, while only around 3% touched the actual repository.

Example paths observed in strace:

/mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins/plugins/life-science-research/skills/gtex-eqtl-skill/SKILL.md
/mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins/plugins/life-science-research/skills/gwas-catalog-skill/SKILL.md
/mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins/plugins/life-science-research/.codex-plugin/plugin.json
/mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins/plugins/life-science-research/.claude-plugin/plugin.json

The trace showed many repeated calls such as:

readlink(...)
stat(...)
lstat(...)
open(...)

against files and directories under /mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins.

Expected behavior

Codex Desktop WSL mode should not repeatedly scan thousands of plugin/cache files from /mnt/c for every command/tool invocation.

High-churn cache/temp/plugin data should either live inside the Linux filesystem or be cached efficiently so that simple commands do not repeatedly incur /mnt/c traversal overhead.

Actual behavior

Codex Desktop WSL mode repeatedly performs many filesystem operations against:

/mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins

This causes severe latency for each command/tool invocation.

Workaround

Using Codex CLI directly inside WSL is fast and does not show the same slowdown.

Temporarily renaming the Desktop plugin cache directory improves performance briefly:

mv /mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins \
   /mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins.bak

However, Codex Desktop recreates/re-scans the plugin cache later, and the slowdown returns.

Privacy note

All usernames, repository names, hostnames, and company-specific paths in this report have been anonymized.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25715

Powered by Codex Action

ckorherr · 1 month ago

Thanks for the workaround. I can actually use Codex again now.
You can create a file called "plugins" so the folder does not get recreated.

w1peee · 1 month ago

Thanks for the suggestion.
For me, the solution was to clear the contents of C:\Users\User\.codex\.tmp\plugins\plugins\
After that, Codex became fast again, and new plugins are no longer being added automatically.

stankitsis · 1 month ago

Confirmed on a VS Code dev container (WSL2/Docker, /root/.codex bind-mounted from C:\ over 9p/drvfs). Plugin cache /root/.codex/.tmp = ~40MB / ~4,734 files.

Moving ONLY that dir onto a native overlay fs took the bundled 0.136.0-alpha.2 engine from 2m21s to ~5s. Same engine, same config, same auth; only the cache filesystem changed (it even rebuilt bigger, 77MB / ~4,791 files, and still ~5s). So the regression is per-turn cache rescanning, amplified by the slow 9p mount.

Workaround: put ~/.codex/.tmp on a native filesystem like a Docker volume mounted at /root/.codex/.tmp (keep config.toml/auth.json on the host mount for persistence).

garfieldmax · 1 month ago
Workaround: put ~/.codex/.tmp on a native filesystem like a Docker volume mounted at /root/.codex/.tmp (keep config.toml/auth.json on the host mount for persistence).

hmm but codex app still lives in windows. How can you move it there?

i have same setup. windows +wsl (where repo is)

stankitsis · 1 month ago
> Workaround: put ~/.codex/.tmp on a native filesystem like a Docker volume mounted at /root/.codex/.tmp (keep config.toml/auth.json on the host mount for persistence). > hmm but codex app still lives in windows. How can you move it there? i have same setup. windows +wsl (where repo is)

The Docker volume bit is specific to my setup (a docker-compose dev container). If you have Windows + WSL and no container, you need a different mechanism, but the same idea: get ~/.codex/.tmp off /mnt/c and onto the WSL-native ext4 disk. You're not moving the Codex app, just the cache folder that the WSL-side app-server scans every turn.

You need to find out where CODEX_HOME resolves. In your WSL shell:
echo $CODEX_HOME
mount | grep -i codex # or check if ~/.codex is under /mnt/c
If .codex lives under /mnt/c, that's the slow path.

Fix:
1 (simpler). Point CODEX_HOME at a WSL-native path so the agent stops reading the Windows .codex over /mnt/c (e.g. export CODEX_HOME=$HOME/.codex with $HOME on the WSL ext4 disk). The trade-off here is login won't be shared with the Windows Desktop app, so you'd sign in once inside WSL.

  1. The OP already noted running the Codex CLI directly inside WSL avoids the slowdown, which is the same thing: a WSL-native CODEX_HOME instead of one on /mnt/c.

If you must keep .codex on the Windows side for the desktop app, you can instead symlink just the .tmp cache to a WSL-native path, but that's much messier.

shoui520 · 1 month ago

Can confirm this is a real issue for me too.

VaniaMi · 1 month ago

Confirmed.

My plugin cache was:

/mnt/c/Users/<user>/.codex/.tmp/plugins
46M
7418 entries

After stopping Codex Desktop and renaming that folder, a simple ping went from >60 seconds to under 5 seconds after restart.

So the root cause is very likely the Desktop app-server repeatedly touching/scanning the plugin cache under /mnt/c/... in Windows + WSL mode.

marceloangelopita1 · 1 month ago

I hit a very similar issue on Windows + WSL with Codex Desktop.

Environment:

  • Codex Desktop: 26.602.4764.0
  • Windows + Ubuntu WSL2
  • Project opened from WSL path: /home/<wsl-user>/projetos/sudoku
  • Codex Desktop WSL app-server path: /mnt/c/Users/<windows-user>/.codex/bin/wsl/<hash>/codex app-server
  • CODEX_HOME in the Desktop WSL app-server environment: /mnt/c/Users/<windows-user>/.codex
  • TEMP/TMP also pointed to /mnt/c/Users/<windows-user>/AppData/Local/Temp
  • VS Code Codex extension on the same WSL/project was fast.

Symptoms:

  • Codex Desktop stayed in “Thinking” for minutes on trivial prompts.
  • Example prompt: “respond only ok” / “run pwd and nothing else”.
  • The same project worked normally in the VS Code extension.
  • GitHub CLI being missing on Windows was fixed separately, but did not fix the slowness.

Local observations:

  • Windows-side Codex .codex directory was about 381 MB.
  • /mnt/c/Users/<windows-user>/.codex/.tmp/plugins was about 65 MB.
  • Desktop WSL app-server was running with CODEX_HOME=/mnt/c/Users/<windows-user>/.codex.
  • After disabling apps/plugins and renaming the plugin cache, trivial prompts became fast again.

Workaround that fixed it:

  1. Backed up C:\Users\<windows-user>\.codex\config.toml
  2. Added/changed:

```toml
[features]
apps = false
plugins = false

[plugins."chrome@openai-bundled"]
enabled = false
```

  1. Renamed:

C:\Users\<windows-user>\.codex\.tmp\plugins
to:
C:\Users\<windows-user>\.codex\.tmp\plugins.disabled-<timestamp>

  1. Restarted Codex Desktop.

Result:

  • Prompt latency dropped from minutes to around 1s for a simple pwd test.
  • This strongly suggests the slowdown was related to Desktop WSL mode reading/scanning Windows-side apps/plugins/cache over /mnt/c, not the model, WSL itself, Git, GitHub CLI, or the repository.
artemrizhov · 1 month ago

This may also be related to #25715

I can confirm that moving the Codex Desktop CODEX_HOME from the Windows filesystem to the WSL/Linux filesystem fixed the severe slowdown for me.

Observed behavior before the workaround:

  • Project was already located inside the Linux filesystem, not under /mnt/c.
  • Codex TUI inside WSL was fast: asking it to inspect the project took about 30 seconds.
  • Codex Desktop on Windows in WSL mode was much slower on the same kind of task:
  • about 1 minute on “Setting up workspace”
  • about 1 minute on “Thinking”
  • then file scanning
  • then another long “Thinking” pause
  • total around 7 minutes
  • The slowdown happened repeatedly between steps, especially during “Thinking”, so it did not look like normal model latency.

The workaround that helped:

  1. Fully exit Codex Desktop via Exit, not just close the window.
  1. I created a separate Linux-native Codex home for Desktop:
mkdir -p ~/.codex-desktop
  1. I copied the existing Windows Codex home into WSL with rsync:
rsync -a --info=progress2 \
  /mnt/c/Users/artem/.codex/ \
  /home/artem/.codex-desktop/
  1. I added this to ~/.profile inside WSL:
if [ "${CODEX_INTERNAL_ORIGINATOR_OVERRIDE:-}" = "Codex Desktop" ]; then
  export CODEX_HOME="$HOME/.codex-desktop"
fi
  1. I restarted Codex Desktop and verified that the WSL codex app-server process picked it up:
pgrep -af "codex.*app-server|app-server"

PID=<pid>
tr '\0' '\n' < /proc/$PID/environ | grep -E 'CODEX_HOME|CODEX_INTERNAL'

Expected result:

CODEX_INTERNAL_ORIGINATOR_OVERRIDE=Codex Desktop
CODEX_HOME=/home/artem/.codex-desktop

After this, Codex Desktop became fast again.

My conclusion: in this case the bottleneck was not the project location, WSL itself, Git, or model speed. The problem appears to be Codex Desktop using Windows-backed .codex state/cache from inside WSL, especially paths under /mnt/c/Users/.../.codex. Moving Desktop’s CODEX_HOME to the Linux filesystem removed the repeated Windows↔WSL filesystem overhead.