Codex App is Unusable Slow with WSL as Agent environment

[AndreTeixeira1998]

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

Codex 26.527.60818

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows with Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

Routine turns in Codex Desktop take minutes despite trivial work. A ls -la (workspace command wall time 0.049 s) produced an 11m35s turn. Profiling the local app DBs (~/.codex/sqlite/logs_2.sqlite, state_5.sqlite) shows ~50 s of fixed overhead before the model is even called, then long model generation.

Session under review

Field	Value
Thread ID	019e8555-6214-7b42-932e-a376a90d71ab
CLI version	0.136.0-alpha.2
Model	gpt-5.5, reasoning effort low
Context window	258,400
Tokens used	~125k
Wall span	2026-06-01 22:37:06 → 22:57:43 UTC (~20.6 min, 3 turns)

Per-turn latency (user message → final answer)

Turn	Prompt	Latency
1	hello	134 s (2m14s)
2	list the files	695 s (11m35s)
3	what command did you ran	253 s (4m13s)

Where the time goes (one turn reconstructed from logs)

Phase	Time	Detail
Submission → first work	~22 s	dispatch/startup stall (no logs emitted)
Models manager + MCP tool list	~0.2 s	rebuilds codex_apps tool list — 89 tools every turn
MCP → skills loaded	~28 s	codex_core_skills::loader re-scans skills every turn
Skills done → first model token	~120–220 s	gpt-5.5 generation

What steps can reproduce the bug?

In settings set in General the agent environment to WSL

1. Open a workspace and start a Codex Desktop session.
2. Send a trivial prompt such as hello, then list the files.
3. Observe each turn takes minutes

What is the expected behavior?

A trivial ls-style turn completes in seconds, not minutes

Additional information

No response

[kendonB]

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

[kendonB]

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

[AndrewEllen]

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

[garfieldmax]

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.

[ckorherr]

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

[DjordjeFilipovic21]

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

[teardeforest-maker]

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.

[stankitsis]

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)