Codex App is Unusable Slow with WSL as Agent environment

Also seeing this. Why do they bother supporting Windows if they won't support Windows

I'll add: Opening an existing chat after app load: 134 seconds

Yep also seeing this. A simple task that usually would take a few minutes is taking upwards of half an hour. A simple request to add a picture to a UI took 1 hour 30 minutes. It is unbearably slow. GPT-5.5-high on regular speed. It was fine before I updated

Straight up unusable. The codex extension was broken in VScode +WSL setup. Now windows codex app is broken as well. What is left? It took me 55m to do a relatively simple single request refactor last night.

Also seeing this now, makes the codex app not useable. Disabling WSL makes it fast again, but that is not an option for me.

Same, tried deleting the cache and assigning more memory to WSL, nothing changed, I guess its something on their end..

Additional reproduction/evidence from a Windows + WSL setup after the June 2/3 update. Sanitized paths and no private logs attached.

Environment:

Codex Desktop Windows package: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
Bundled/active WSL CLI: codex-cli 0.136.0-alpha.2
Codex binary mtime: 2026-06-02 11:55 local time
OS: Windows 11 / WSL2 Ubuntu 24.04.4 LTS
Kernel: 6.6.114.1-microsoft-standard-WSL2
Mode: runCodexInWindowsSubsystemForLinux = true, integratedTerminalShell = "wsl"
Model config unchanged from prior fast behavior: model = "gpt-5.5", model_reasoning_effort = "xhigh", service_tier = "priority"
Workspace checked for this diagnostic: /mnt/c-backed empty/projectless workspace, file_count=0, dir_count=1

Observed regression:

• User reports same tasks/configuration were fast around May 30-31, then became much slower after today/recent update.
• Symptom is high first-token latency / long delay after prompt submission before output begins.
• Model/effort were already gpt-5.5 + xhigh before the regression, so this does not appear to be explained by a new reasoning-effort change.

Read-only diagnostics:

codex doctor --summary:
17 ok | 1 idle | 1 notes | 0 warn | 0 fail
install consistent
config loaded
auth configured
mcp: no MCP servers configured
state DBs healthy
websocket connected (HTTP 101) within 15s timeout
active provider endpoints reachable over HTTP
app-server not running (ephemeral mode)

Local command timings, no agent prompt/model turn:

codex --version       elapsed 0.15s
codex features list   elapsed 0.94s
codex plugin list     elapsed 1.65s
codex mcp list        elapsed 3.93s, output: no MCP servers configured

Network probe from WSL, unauthenticated curl only:

https://api.openai.com/v1/models: first_byte ~0.22-0.32s, total ~0.22-0.32s, HTTP 401 expected without auth
https://chatgpt.com/: first_byte ~0.07-0.12s, total ~0.07-0.13s, HTTP 403 expected for direct unauthenticated request

Other local observations:

• Current WSL Codex binary is the only local ~/.codex/bin/wsl/*/codex binary found; no older May 28-era binary is available locally for easy rollback.
• Current Windows package is 26.601.2237.0; stale/trusted config entries reference an older OpenAI.Codex_26.519.5221.0... path, but Get-AppxPackage *Codex* only shows the current package.
• ~/.codex is ~696 MB with 5,610 files; largest entries are the current 226 MB WSL Codex binary and older session JSONL files.
• Recent file mtimes show plugin/app directory caches refreshed around 2026-06-03 12:00-13:16 local time, including codex_app_directory, codex_apps_tools, and bundled/curated plugin marketplace cache.
• No external MCP servers are configured, so this specific repro is not caused by a user MCP tools/list hang.

Interpretation:

This looks like a Windows Desktop + WSL regression in 0.136.0-alpha.2 / 26.601.2237.0 or associated plugin/app-server/tool discovery path, not a large repo scan, not a user-defined MCP startup delay, and not obvious local network reachability. It may be related to the same pre-model fixed overhead described in this issue, but observed on a newer Windows package than the original report.

Confirming on the same setup (0.136.0-alpha.2 bundled by the VS Code extension, WSL2
kernel 6.6.87.2, gpt-5.5). It's a clean regression: 0.135.0 is the last good version;
0.136.x (incl. 0.136.0 stable, see #26121) is slow.

Same trivial-turn repro, same machine, back to back:
time codex exec --skip-git-repo-check --sandbox read-only "Reply with exactly: OK"

• 0.135.0: ~20-35s
• 0.136.0-alpha.2: ~2m20s

It's config-independent - supports_websockets=false makes no difference, consistent
with your finding that the cost is per-turn skill/tool rescan, not the socket.

Workaround until fixed:

• CLI: pin to 0.135.0 (npm i -g @openai/codex@0.135.0)
• VS Code extension: set chatgpt.cliExecutable to a 0.135.0 codex binary (~2m -> <10s).

Edit: see follow-up below for a better fix (no downgrade needed)

Follow-up: found a better fix than the version downgrade above, and it points at the root cause.

The per-turn cost is Codex rescanning the ~/.codex/.tmp plugin cache (thousands of small files) every turn. On my setup that cache sat on slow storage: a dev container with ~/.codex bind-mounted from the Windows host over 9p/drvfs. Moving ONLY ~/.codex/.tmp onto a native filesystem took a trivial turn from ~2m20s to ~3-5s on the LATEST engine, no downgrade needed (same engine/config/auth; only the cache filesystem changed). Detailed strace-level confirmation in #26149 -- looks like the same root cause.

Workaround that keeps you on the latest engine: put ~/.codex/.tmp on a native fs. In a docker-compose dev container that's a one-line named volume:

services:
app:
volumes:

• codex_cache:/root/.codex/.tmp # cache on fast native fs

volumes:
codex_cache:

(config.toml/auth.json stay on the host bind mount, so login still persists.)

The real fix is probably to not rebuild/rescan that cache every turn, but moving it off slow storage is effective in the meantime.

Follow-up: found a better fix than the version downgrade above, and it points at the root cause. The per-turn cost is Codex rescanning the ~/.codex/.tmp plugin cache (thousands of small files) every turn. On my setup that cache sat on slow storage: a dev container with ~/.codex bind-mounted from the Windows host over 9p/drvfs. Moving ONLY ~/.codex/.tmp onto a native filesystem took a trivial turn from ~2m20s to ~3-5s on the LATEST engine, no downgrade needed (same engine/config/auth; only the cache filesystem changed). Detailed strace-level confirmation in #26149 -- looks like the same root cause. Workaround that keeps you on the latest engine: put ~/.codex/.tmp on a native fs. In a docker-compose dev container that's a one-line named volume: `` services: app: volumes: - codex_cache:/root/.codex/.tmp # cache on fast native fs volumes: codex_cache: `` (config.toml/auth.json stay on the host bind mount, so login still persists.) The real fix is probably to not rebuild/rescan that cache every turn, but moving it off slow storage is effective in the meantime.

This can't explain my experience as I have no slow storage on my machine (2x M.2 drives, though WSL is on one and Windows is on the other)

Working on 0.136.0 via the TUI behaves normally for me as well.

Deleting the .tmp plugin cache seemed to make some improvement for a chat but then back to being unusably slow

Fix the cli to 0.135.0 works for me

renaming the .tmp plugins folder made the first turn start much faster but overall performance remains very poor compared to vs code or codex TUI

Not fixed with CLI 0.117.0

Changing to 0.135.0 doesn't help me.

Also tried doing a broader deslop of the %USERPROFILE%\.codex folder which didn't seem to help

There been 4 or 5 updates since this been broken and still its not fixed. OpenAI doesnt not care about their app or WSL support?

Maybe @ambrosino-oai will acknowledge they're working on it

If you are seeing this issue, please use /feedback to upload your logs, then post the session ID here. This will help us with the investigation.

019e9590-cd12-7003-a8f6-11dd2d888ac1

019e9589-b080-77a0-bb7c-6e70e3b1ad75

I saw improvements with using bind mount. I have two M2 drives similar to what was mentioned before and am still seeing improvements in speed by moving the .tmp/plugins folder to WSL and then pointing the Windows folder to this. The solution below seems to survive new threads and Codex restarts, although it may not survive wsl shutdown/reboot (you can probably use systemd to automate the process when starting WSL):

mkdir -p /home/[WSL username]/.codex/desktop-tmp-plugins-bind
rsync -a --delete /mnt/c/Users/[Windows username]/.codex/.tmp/plugins/ /home/[WSL username]/.codex/desktop-tmp-plugins-bind/
sudo mount --bind /home/[WSL username]/.codex/desktop-tmp-plugins-bind /mnt/c/Users/[Windows username]/.codex/.tmp/plugins

To clarify, even with this the performance is still slower than CLI as @GregPeden mentioned.

019e942c-f029-7e63-9671-a9baa2c23afa

If you are seeing this issue, please use /feedback to upload your logs, then post the session ID here. This will help us with the investigation.

019e5add-9c47-7c92-ac5e-013e4eaf94d2

019e923c-dd45-7441-876d-adc9c16fe750

019e9128-ce6b-7f62-a5b6-fdc48488349d

Assuming this is a regression, https://github.com/openai/codex/pull/26669 may help mitigate it. Should go out with next release.

I got further performance improvements by using bind mount for the .codex/plugins/cache/openai-curated folder also. This seems to be an issue in general with the plugins on the Windows side as further supported by the info posted in these issues: #20967 and #26149

Temporary workaround for Codex Desktop + WSL slowdown

If Codex Desktop/CLI in WSL suddenly takes minutes to answer trivial prompts, check whether CODEX_HOME points to a Windows-backed path such as:

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

In my case, the slowdown came from repeated apps/plugins discovery and .codex/.tmp/plugins scans under /mnt/c.

Non-destructive workaround:

1. Back up your config:

cp /mnt/c/Users/<WindowsUser>/.codex/config.toml \
   /mnt/c/Users/<WindowsUser>/.codex/config.toml.bak

1. Add or merge this into config.toml:

[features]
apps = false
plugins = false

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

1. Restart Codex Desktop.

Rollback:

cp /mnt/c/Users/<WindowsUser>/.codex/config.toml.bak \
   /mnt/c/Users/<WindowsUser>/.codex/config.toml

This does not delete auth/session/cache files. It just disables apps/plugins discovery temporarily until the upstream issue is fixed.

Thanks so much @xl-openai. I will try it out when I'm back at my computer. Keep the WSL performance improvements going!

@xl-openai still not fixed. I installed 0.138.0-alpha.6. Tried a "test" chat and it timed out before returning anything (no-active-thread-019e9bc4-5611-73e1-8af4-a3774e630368) then tried again and it was still very slow (no apparent improvement vs the previous version). Session id 019e9bc5-7ddc-7e61-8bf9-f9873b14ccf6

### Temporary workaround for Codex Desktop + WSL slowdown If Codex Desktop/CLI in WSL suddenly takes minutes to answer trivial prompts, check whether CODEX_HOME points to a Windows-backed path such as: /mnt/c/Users/<WindowsUser>/.codex In my case, the slowdown came from repeated apps/plugins discovery and .codex/.tmp/plugins scans under /mnt/c. Non-destructive workaround: 1. Back up your config: cp /mnt/c/Users/<WindowsUser>/.codex/config.toml \ /mnt/c/Users/<WindowsUser>/.codex/config.toml.bak 2. Add or merge this into config.toml: [features] apps = false plugins = false [plugins."chrome@openai-bundled"] enabled = false 3. Restart Codex Desktop. Rollback: cp /mnt/c/Users/<WindowsUser>/.codex/config.toml.bak \ /mnt/c/Users/<WindowsUser>/.codex/config.toml This does not delete auth/session/cache files. It just disables apps/plugins discovery temporarily until the upstream issue is fixed.

This workaround fixed the slowdown for me, but disabling apps/plugins is not the only option.

In my case CODEX_HOME was:

/mnt/c/Users/xxxx/.codex

So .codex/.tmp/plugins was being scanned from a Windows-backed /mnt/c path. Setting this made Codex immediately fast again:
[features]
apps = false
plugins = false

Then I re-enabled apps/plugins and used a bind mount so only the plugin temp cache lives on native WSL/ext4 storage:
CODEX_WIN=/mnt/c/Users/<WindowsUser>/.codex
NATIVE=/root/.codex/desktop-tmp-plugins-bind

mkdir -p "$NATIVE" "$CODEX_WIN/.tmp/plugins"
rsync -a "$CODEX_WIN/.tmp/plugins/" "$NATIVE/"
sudo mount --bind "$NATIVE" "$CODEX_WIN/.tmp/plugins"

After that I set apps/plugins back to true:

[features]
apps = true
plugins = true

Check:
findmnt /mnt/c/Users/<WindowsUser>/.codex/.tmp/plugins

You want to see the source pointing to the native WSL path, e.g. /root/.codex/desktop-tmp-plugins-bind on ext4.

Important: this bind mount is not permanent. If you run wsl --shutdown or reboot Windows, you may need to run the sudo mount --bind ... command again.

I can reproduce a related Windows + WSL performance failure on a newer Codex App build, with a clear memory/cache signature.

Environment:

• Windows 11
• Codex App: OpenAI.Codex 26.602.4764.0
• Codex CLI: 0.135.0
• WSL: 2.6.3.0
• Distro: Ubuntu, WSL2
• Desktop config: runCodexInWindowsSubsystemForLinux = true

Observed behavior:

• Opening Codex App restored a WSL workspace:

\\wsl$\Ubuntu\home\leo\ai-config-hub

• The app became slow and vmmemWSL grew aggressively.
• During one reproduction:
• Codex desktop main process briefly reached roughly 600-700 MB.
• A renderer reached roughly 200 MB.
• Codex launched wsl.exe ... codex app-server --analytics-default-enabled.
• vmmemWSL grew from roughly 2.6 GB to 3.9 GB, and after closing the app it later showed roughly 10.9 GB.
• Inside WSL at that point, process RSS was not the issue:
• free -m showed roughly 1.35 GB used but about 9.07 GB buff/cache.
• Top RSS processes were modest (dockerd, tailscaled, gunicorn, etc.); no Codex app-server process remained after closing the app.

Relevant Codex desktop logs:

• Repeated startup lines:

[spawn-async] Spawning process inside WSL

• Git/review activity against:

/home/leo/ai-config-hub

• The log showed a very large git add ... / review-summary style command whose argument list included generated/dependency paths such as:

skills/pdf2md/deps/.venv/lib/python3.12/site-packages/...

• I also saw repeated git watcher warnings for the same workspace, e.g. failed watches under:

/home/leo/ai-config-hub/.git

This looks like Codex App startup/review prewarm is too aggressive in WSL mode:

• It restores a heavy active workspace on launch.
• It runs many WSL spawns and Git/review-summary operations before the user asks for anything.
• It appears to include dependency/generated trees such as .venv under skill deps.
• WSL then retains the file reads as Linux page cache, which Windows reports as high vmmemWSL memory even after the app closes.

Local workarounds that helped:

• Removed the heavy workspace from Codex App active-workspace-roots.
• Added .gitignore entries for dependency/generated paths:
• skills/**/deps/.venv/
• skills/**/deps/packages/
• skills/**/node_modules/
• skills/**/dist/
• skills/**/build/
• skills/**/.cache/
• Added WSL memory reclaim:

``ini
[experimental]
autoMemoryReclaim=dropCache
``

• Ran wsl --shutdown to recover the cached memory.

After those changes, reopening Codex App no longer triggered the heavy workspace scan in logs, the main app process stayed around 164 MB, and vmmemWSL stayed around 1.9 GB during the short retest.

Expected behavior:

• Codex App should bound startup prewarm/review scans in Windows + WSL mode.
• It should respect .gitignore and avoid generated/dependency directories such as .venv, node_modules, package caches, build outputs, and similar large dependency payloads.
• It should not trigger huge Git/review-summary commands on app launch for restored workspaces.
• Ideally there should be a setting to disable startup workspace prewarm/review-summary scans entirely for WSL projects.

A workaround is to switch back to Windows Native agents and point the agent at the wsl folder. It kind of works; still a bit slow but not unusable. It runs things like wsl.exe -d Ubuntu --cd /home/kendonb/projects/project_blurbs -- python3 -c "import openpyxl
from pathlib import Path ...

This looks related to #26149.

I had the same kind of slowdown with Codex Desktop on Windows in WSL mode, while Codex TUI inside WSL was fast on the same project.

The workaround from #26149 helped: I fully exited Codex Desktop, moved Desktop’s CODEX_HOME from the Windows filesystem to a WSL/Linux path, and restarted Desktop.

After that, Codex Desktop became fast again. In my case, the bottleneck was likely Windows-backed .codex state/cache access through /mnt/c, not the project location or model latency.