{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifubyurzzfkbqnab4fxczwyf4ullstrxsnmsptem5wtwsn42fog6e",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mnjy3hd776t2"
  },
  "path": "/t/codex-desktop-app-on-windows-10-wsl-takes-60s-to-answer-simple-prompt-while-vscode-agent-responds-in-seconds/1382691#post_2",
  "publishedAt": "2026-06-05T10:51:51.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "OpenAI Codex",
    "github.com/openai/codex",
    "Codex Desktop on Windows + WSL repeatedly scans .codex/.tmp/plugins over /mnt/c, causing severe per-command latency",
    "fcrhu"
  ],
  "textContent": "Welcome to the forum!\n\nYou are welcome to discuss Codex issues on the forum, however the official place to report and track them is the GitHub issue tracker for OpenAI Codex.\n\nI had ChatGPT look for the closest related issue and it identified:\n\ngithub.com/openai/codex\n\n####  Codex Desktop on Windows + WSL repeatedly scans .codex/.tmp/plugins over /mnt/c, causing severe per-command latency\n\nopened 11:36AM - 03 Jun 26 UTC\n\n\n\n          fcrhu\n        \n\nbug  windows-os  app  skills  app-server  performance\n\n## Summary Codex Desktop on Windows with a WSL project is extremely slow for ev…ery 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: ```text 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: ```text wsl.exe --exec /bin/true: ~0.1s ``` Interactive Bash startup is fast after fixing unrelated shell initialization: ```text bash -i -c \"exit\": ~0.35s ``` Git is fast: ```text git status -sb: ~0.2s ``` Repository traversal is fast when excluding known heavy/generated folders: ```text 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: ```text Path: /mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins Size: ~38 MB Files: ~4,646 Directories: ~2,400 ``` Previously the cache was approximately: ```text 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: ```bash 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: ```text 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`: ```text /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: ```text 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: ```bash 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.\n\nIf that issue matches your problem, consider adding a  reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work.\n\nIf it is not the same issue, try searching the existing GitHub issues for a closer match. If you cannot find one, then open a new issue with as much detail as possible.",
  "title": "Codex Desktop App on Windows 10 + WSL takes >60s to answer simple prompt, while VSCode agent responds in seconds"
}