›_ Codex Issues
Codex Issues / #27240

Codex Desktop on Windows 11: WSL Agent Environment has extreme per-turn latency, including trivial prompts

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

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

26.602.71036 • Released 8 Jun 2026

What subscription do you have?

Plus

What platform is your computer?

W11 (fully updated) + WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64)

What issue are you seeing?

Summary

Codex Desktop on Windows 11 is responsive when not using WSL, and WSL itself is also responsive in normal use. However, when using WSL Agent Environment, Codex becomes extremely slow, including for trivial prompts such as OK.

This is not limited to initial WSL startup. The same issue occurs on the 2nd and later prompts in an already-open thread, where WSL cold start is no longer a credible explanation.

What I observe

  • Windows 11 agent path: fast
  • Normal WSL usage outside Codex: fast
  • Codex Desktop with WSL Agent Environment: extremely slow
  • Even trivial prompts like OK can take minutes
  • This happens repeatedly and is easy to reproduce

Why this seems like a Codex WSL integration bug

The delay does not appear to be caused by model reasoning or repository analysis:

  • The prompt is trivial
  • The same trivial prompt is fast outside WSL agent mode
  • Normal WSL work on this machine does not show comparable latency
  • The issue persists after the first prompt in the thread

This suggests a problem in the Codex Desktop <-> WSL integration path, such as:

  • per-turn context hydration
  • repeated state/history access under .codex
  • locking/contention on Codex state
  • Windows/WSL IPC stalls
  • unnecessary repeated scanning or bookkeeping on each turn

Reproduction

  1. Open Codex Desktop on Windows 11
  2. Start a new thread with WSL Agent Environment
  3. Send a trivial prompt such as OK
  4. Observe very long latency
  5. Send another trivial prompt in the same thread
  6. Observe that latency remains very high

Expected behavior

  • First prompt in a new WSL thread may have some startup cost, but should still be on the order of seconds, not minutes
  • 2nd and later trivial prompts in the same WSL-backed thread should return quickly

Actual behavior

  • New-thread trivial prompts can take minutes
  • Repeated trivial prompts in the same thread can also take minutes

Comparison notes

  • Same machine
  • Same user
  • Same kind of trivial prompt
  • Fast in Windows agent mode
  • Fast in ordinary WSL use outside Codex
  • Slow only in Codex Desktop with WSL Agent Environment

Related public reports

These may be related, though my issue is specifically about severe per-turn latency:

  • #14468
  • #13762
  • #13549
  • #13785

Environment

  • OS: Windows 11
  • Agent environment: WSL
  • Codex Desktop app
  • WSL itself performs normally outside Codex

What steps can reproduce the bug?

Reproduction

  1. Open Codex Desktop on Windows 11
  2. Start a new thread with WSL Agent Environment
  3. Send a trivial prompt such as OK
  4. Observe very long latency
  5. Send another trivial prompt in the same thread
  6. Observe that latency remains very high

What is the expected behavior?

Expected behavior

  • First prompt in a new WSL thread may have some startup cost, but should still be on the order of seconds, not minutes
  • 2nd and later trivial prompts in the same WSL-backed thread should return quickly

Additional information

Related public reports

These may be related, though my issue is specifically about severe per-turn latency:

  • #14468
  • #13762
  • #13549
  • #13785

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26162
  • #26766
  • #26149
  • #26985

Powered by Codex Action

simfor99 · 2 months ago

Confirming this exact class of issue: severe per-turn latency in a WSL-backed Codex environment, including simple requests.

Environment observed:

  • codex-cli 0.139.0
  • Ubuntu 24.04.3 LTS on WSL2
  • Kernel 6.6.87.2-microsoft-standard-WSL2
  • High-tier / 20x Codex subscription
  • Observed on 2026-06-11

Symptoms:

  • Simple assistant responses sometimes took around 9-10 minutes.
  • It was not just a large task or heavy tool run; even simple turns were painfully slow.
  • Local shell commands returned normally, so this looked like Codex turn responsiveness rather than WSL itself being generally slow.
  • I abandoned the previous session and started a fresh one because the latency became unusable.

This matches the per-turn latency shape described here very closely.

wbdb · 2 months ago

I can confirm this with Ubuntu 24.04, and the same applies after a fresh install with Ubuntu 26.04 (WSL). Reinstalling Codex completely, including the .codex folder, doesn't help either.

xuzhiqiang0038 · 2 months ago

Cross-linking a related report I just filed: #28935.

Same structural class, but observed from the native Windows agent environment — I migrated off WSL specifically to escape this latency, and it persists. That issue isolates two concrete mechanisms:

  1. Every Codex update re-injects an [mcp_servers.node_repl] block into ~/.codex/config.toml even when the related features (browser_use / computer_use / plugins) are explicitly disabled.
  2. Codex eagerly/synchronously spins up that browser/computer-use runtime + app/plugin/marketplace enumeration at thread/start, blocking the composer before send — even for a plain chat that never touches those tools.

Proposed fix there: lazy/async init so optional subsystems load on first actual use instead of taxing every new thread. The per-turn latency described in this issue and the pre-send "spinner" in #28935 look like the same eager-init / bridge cost surfacing in different places.

Enferlain · 2 months ago

doesn't even work for me at all. it's impressive how shit apps can still be in the day of llms

2026-06-20 01:18:03.001 [info] [Window] [remote-connection][ExtensionHost][f08f3…][reconnect] reconnected!
2026-06-20 01:18:23.013 [info] [Window] [remote-connection][ExtensionHost][f08f3…][reconnect] received socket timeout event (reason: unacknowledgedMessage, unacknowledgedMsgCount: 177, timeSinceOldestUnacknowledgedMsg: 20012, timeSinceLastReceivedSomeData: 20013).
2026-06-20 01:18:23.013 [info] [Window] [remote-connection][ExtensionHost][f08f3…][reconnect] starting reconnecting loop. You can get more information with the trace log level.
2026-06-20 01:18:23.014 [info] [Window] [remote-connection][ExtensionHost][f08f3…][reconnect] starting reconnection with grace time: 10800000ms (10800s)
2026-06-20 01:18:23.014 [info] [Window] [remote-connection][ExtensionHost][f08f3…][reconnect] resolving connection...
2026-06-20 01:18:23.014 [info] [Window] [remote-connection][ExtensionHost][f08f3…][reconnect] connecting to WebSocket(127.0.0.1:62192)...
2026-06-20 01:18:23.014 [info] [Window] Creating a socket (renderer-ExtensionHost-f)...
2026-06-20 01:18:23.207 [info] [Window] Creating a socket (renderer-ExtensionHost-f) was successful after 193 ms.
2026-06-20 01:18:23.224 [info] [Window] [remote-connection][ExtensionHost][f08f3…][reconnect] reconnected!