Codex App on Windows WSL responding very slow compared to CLI

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

• #20754
• #19466

Powered by Codex Action

This request took 5 full minutes to be sent for me

<img width="766" height="107" alt="Image" src="https://github.com/user-attachments/assets/51f1bb4a-0205-4850-8324-b1cc1f7fa570" />

also taking a very long time to send messages for me in codex app when in wsl

Additional reproduction: Desktop WSL is 60-106s to first token while WSL CLI is ~10s, even when proxy is active

I am seeing the same class of issue on a newer Codex Desktop build, with a more controlled ping/pong reproduction.

Environment

• Codex Desktop Windows app: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
• Codex CLI used by Desktop WSL app-server: 0.136.0-alpha.2
• Platform: Windows + WSL
• Codex Desktop setting: runCodexInWindowsSubsystemForLinux = true
• Desktop WSL agent command observed from the packaged app code path:
• Windows launches wsl.exe
• WSL launches codex app-server --analytics-default-enabled
• Proxy:
• HTTP_PROXY=http://127.0.0.1:18081
• HTTPS_PROXY=http://127.0.0.1:18081
• NO_PROXY=localhost,127.0.0.1,::1,100.64.0.0/10,.ts.net,...

Expected behavior

For a trivial ping prompt with medium reasoning and no tool work, Codex Desktop WSL should respond in roughly the same range as pure WSL Codex CLI. In this environment, pure WSL Codex CLI is about 10s for the same ping/pong style test.

Actual behavior

Codex Desktop WSL consistently spends around 60-106s before the first assistant token, even for a trivial ping -> pong turn.

Captured Desktop WSL examples:

1. Projectless ping-16, medium

• session: 019e8d06-9e1a-7cb2-810a-2fa1f326b163
• user ping: 2026-06-03T10:28:18.775Z
• assistant pong: 2026-06-03T10:29:36.617Z
• duration: 92956ms
• time_to_first_token: 92676ms
• input tokens: 26801
• cached tokens: 6016
• output tokens: 5
• reasoning tokens: 0

1. Projectless ping-17, same thread, medium

• session: 019e8d35-0610-78a0-b4a7-5a4db6d499c8
• user ping: 2026-06-03T11:54:01.258Z
• assistant pong: 2026-06-03T11:55:08.945Z
• duration: 68789ms
• time_to_first_token: 68569ms
• user_ping_to_agent_response: 67687ms
• input tokens: 14072
• cached tokens: 9600
• output tokens: 5
• reasoning tokens: 0

1. Projectless ping-17, later clean sample, medium

• user ping: 2026-06-03T11:59:03.096Z
• assistant pong: 2026-06-03T12:00:46.112Z
• duration: 106056ms
• time_to_first_token: 105613ms
• user_ping_to_agent_response: 103016ms
• input tokens: 14085
• cached tokens: 13696
• output tokens: 5
• reasoning tokens: 0
• no title generation timeout, no unknown conversation warning, no git watcher error, and no obvious concurrent Desktop turn in the relevant Desktop logs

1. After setting Windows user-level proxy env vars and restarting/retesting

• user ping: 2026-06-03T12:48:52.020Z
• assistant pong: 2026-06-03T12:49:45.295Z
• duration: 60038ms
• time_to_first_token: 59946ms
• user_ping_to_agent_response: 53275ms
• input tokens: 15248
• cached tokens: 11648
• output tokens: 5
• reasoning tokens: 0

Important diagnostic: proxy is not missing

This does not look like a simple missing-proxy problem.

The WSL app-server logs show that the Desktop WSL agent is using the proxy and that the local proxy connection/HTTP handshake completes quickly:

proxy(http://127.0.0.1:18081/) intercepts 'https://chatgpt.com/'
tunneling HTTPS over proxy
connecting to 127.0.0.1:18081
connected to 127.0.0.1:18081
http1 handshake complete
pooling idle connection for ("https", chatgpt.com)

The packaged Desktop app code path also appears to include HTTP_PROXY, HTTPS_PROXY, and NO_PROXY in the WSL environment allowlist. It does not include ALL_PROXY or lowercase proxy env vars, but the logs above show that the HTTPS proxy path is active.

Things ruled out in this reproduction

• Not reasoning work: reasoning_tokens=0
• Not output generation: output is only pong / 5 tokens
• Not only large context: the slower samples have around 14k input tokens with most tokens cached
• Not only title generation: same-thread pings without title generation are still 60-106s
• Not only "unknown conversation" startup noise: the clean later same-thread sample did not show that warning
• Not only git watcher ENOENT/path noise: the clean later sample did not show that in the relevant turn window
• Not missing proxy: WSL app-server logs show proxy interception, connection, and HTTP handshake

Suspicious area

The delay appears to happen after Desktop accepts/sends the turn and after the WSL app-server can reach the proxy/chatgpt.com path, but before the first assistant token is delivered.

In the app-server SQLite logs, there is a long quiet gap during the actual wait. The logs show proxy setup, plugin/remote-control activity, and HTTP handshake, but not enough detail around the model request/stream stage to identify where the 50-100s are being spent.

There is also background plugin/browser noise:

• remote plugin sync starts during app-server activity
• GitHub plugin sync can hit 403 Forbidden / API rate limit
• Browser/plugin app-server clients initialize

However, these do not seem to be the sole root cause, because a later clean same-thread ping still took over 100s.

Related issues

• This seems closest to #20967: Codex App on Windows WSL responding very slow compared to CLI.
• It may also be adjacent to #23277, which found first-token delay around Desktop WSL apps/plugins path bridge, but in this reproduction the latency is much higher and did not disappear after proxy env changes.
• It is distinct from #25117 / #15447 because here the WSL app-server logs prove the proxy is active.

Request

Could the Codex team please inspect the Desktop Windows + WSL codex app-server model-turn path, especially the interval between:

1. Desktop turn/start
2. WSL app-server proxy/chatgpt.com HTTP handshake completion
3. first assistant token returned to Desktop

It would also help if app-server logs exposed timing for the actual model request/stream stage, because the current logs show a long uninstrumented wait.

seeing the same thing. App is much slower when WSL backend is enabled than cli

Same problem here, running Codex app on Windows with WSL enabled. It was working fine since last week, this week the windows app is extremely slow.
I run a simple question "What's your name?" and it took almost 2 minutes in the Windows app to get an answer. I run the same command on wsl cli and answer took a couple of seconds only.

I also have a mac laptop side-by-side with the windows machine and it also answer way faster than the windows app.

I hit the same symptom recently: Codex Desktop on Windows with WSL backend took ~1-2 minutes to answer even a trivial ping.

The direct cause is that codex (haven't verify if it's WSL backend specific) is triggering some non-critical app/plugin traffic to remote just before starting a turn. Those traffic are BLOCKING and will retry several times automatically, so if you have problem connecting to any of those service, your codex will sit on “Thinking...” until timeouts/retries completed, around 90 seconds in my case, and finally give up and send your REAL prompt, looking like thinking very slow. What's worse, this process seems repeating on EVERY turn if last turn fails, rendering codex nearly useless as it sits there waiting for a 90 seconds timeout before doing any real things on every single turn.

This could be verified by applying following patch:

1. switching backend setting from WSL to windows in settings UI and restart codex. In my case, issue solved immediately
2. staying on WSL backend but disable all non-essential services by adding these settings in %USERPROFILE%/.codex/config.toml under [features] section, then restart codex. This may be redundant but got my issue solved with backend setting staying at WSL

[features]
apps = false
plugins = false
browser_use = false
computer_use = false

If after applying any of these fix you can get a 'pong1' in seconds after starting a new thread with 'ping1', then the issue can be narrowed to startup/plugin network calls. In my case, the root cause is a very specific proxy issue affecting HTTP/2+WS connection and is solved by forcing "domainStrategy": "UseIPv4" on my Xray proxy server, which may sounds alien to you, but the debugging path should be generic and you've got a fast codex back working for you. Ask it to check those and find the root cause plus a fix:

• Codex rollout/session logs at %USERPROFILE%/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
• Look for time_to_first_token_ms and timestamps between user_message and first assistant output.
• Codex SQLite logs at %USERPROFILE%/.codex/logs_*.sqlite
• copy the DB to /tmp first, then queried it with sqlite3 because codex will keep it open.
• Search around the slow turn for chatgpt.com, ab.chatgpt.com, plugins, remote installed plugin, websocket, timeout, etc.
• Proxy software logs:
• Check whether the slow window shows repeated or stalled connections to chatgpt.com, ab.chatgpt.com, GitHub, or plugin/app endpoints.

Very glad to got my fast codex back!

-----------UPDATE-------------

The issue appears for absolutely no reason again and I'm sticking with the following destructive patch for now until this issue got fixed

[features]
apps = false
browser_use = false
computer_use = false

Seems to be fixed in 26.707.61608, closing. Thanks Codex team!