Codex Desktop Windows + WSL: apps/plugins path bridge causes 20s first-token delay and image path failures

Summary

I am seeing a major regression in Codex Desktop on Windows + WSL after a recent update.

There are two symptoms that appear related to the Windows/WSL desktop bridge:

1. Codex Desktop became much slower than the VS Code extension in the same WSL project.
2. Pasted local images from Windows screenshot tools sometimes fail or require manual Windows-path-to-WSL-path handling.

The VS Code extension is fast in the same WSL environment, while Codex Desktop has a much heavier desktop path.

Environment

• OS: Windows + WSL
• WSL distro: Ubuntu 22.04
• Codex Desktop app: OpenAI.Codex_26.513.4821.0
• Codex CLI used by Codex App: 0.131.0-alpha.9
• VS Code extension path/version family: openai.chatgpt-26.506.x / openai.chatgpt-26.513.x
• Project is opened from WSL
• Same machine, same WSL, same project:
• VS Code extension: fast
• Codex Desktop app: slow / path bridge issues

Main performance issue

After the recent Codex Desktop update, even a trivial prompt like:

你好

could take around 20 seconds before the first token.

One captured rollout showed:

duration_ms=21312
time_to_first_token_ms=19506
input_tokens=22482
output_tokens=36
tools/MCP/skills/compact: none

So the delay was not caused by model generation, tools, MCP, skills, or context compaction. It looked like a fixed pre-turn / first-token delay in the desktop app request path.

The second simple prompt, such as:

你可以干嘛

also took about 23 seconds, with similar input token count.

What I already ruled out

At first I suspected local session history size, but this does not appear to be the main cause.

I archived/restored the local sessions and verified that:

• .codex/sessions was previously about 1.6GB
• after reducing it, thread/list became faster
• but the 20s first-token delay was not explained by sessions size
• after restoring the 1.6GB session history, normal response speed stayed around 2-3s once the real fix below was applied

So large session history can slow sidebar/thread scanning, but it does not seem to be the root cause of the 20s response delay.

Important log evidence

In Codex Desktop logs, I saw the following types of problems:

1. Global state had once been written with BOM / bad JSON

Example log:

Failed to load global state
Unexpected token ''

This happened around .codex-global-state.json.

That state file had previously been rewritten by PowerShell 5.x with UTF-8 BOM. I later rewrote it using PowerShell 7 with UTF-8 no BOM.

2. Runtime install failed before manual replacement

Logs showed:

primary_runtime_install_started
primary_runtime_install_failed
Failed to list primary runtime archive

The installed runtime was older:

bundleVersion=26.423.10653

I manually replaced it with:

bundleVersion=26.515.10909

The latest manifest I checked was:

https://persistent.oaistatic.com/codex-primary-runtime/latest/win32-x64/LATEST.json
latest=26.515.10909

3. Desktop app/plugin path bridge looked broken

The biggest clue was a slow app/list:

app/list durationMs=18628

At the same time, bundled Chrome plugin validation appeared to use an invalid Windows/WSL mixed path similar to:

C:\mnt\c\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\0.1.7

This path shape looks wrong. It appears that a WSL path like:

/mnt/c/Users/<user>/...

was incorrectly converted into:

C:\mnt\c\Users\<user>\...

Workaround that made response speed normal again

The biggest improvement came from disabling apps/plugins and the bundled Chrome plugin in:

C:\Users\<user>\.codex\config.toml

Current workaround:

[features]
memories = true
apps = false
plugins = false

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

After this, the same trivial prompts went from about 20s to around 2-3s.

Examples after workaround:

duration_ms=2682
time_to_first_token_ms=1774

and after restoring projects/session history:

duration_ms=3452
time_to_first_token_ms=2620

This strongly suggests the slow path is related to Codex Desktop's apps/plugins/Chrome bundled plugin initialization or Windows/WSL path bridge, not the model itself.

Pasted image path issue

There is also a separate but likely related Windows/WSL path issue when pasting screenshots/images into Codex Desktop.

Typical screenshot image paths come from Windows tools, for example:

C:\Users\<user>\AppData\Local\Temp\...
C:\Users\<user>\Documents\PixPin\Temp\...

When the agent is running in WSL, the usable path should be converted to:

/mnt/c/Users/<user>/...

The VS Code extension seems to handle this more reliably, but Codex Desktop often struggles with this path bridge. Sometimes the model has to manually reason about converting the Windows path to a WSL path before it can read the image.

This seems like it happens before or around the desktop-to-WSL handoff, so local project instructions can only partially work around it after the model starts. The desktop app itself should probably normalize pasted image paths for the WSL runtime.

Expected behavior

• Codex Desktop on Windows + WSL should have similar first-token latency to the VS Code extension when using the same project and WSL environment.
• A trivial prompt should not spend around 20s before first token when no tools/MCP/skills/compact are involved.
• Windows local pasted image paths should be correctly mapped for WSL runtimes.
• Bundled plugin paths should not become malformed paths like C:\mnt\c\....

Actual behavior

• Codex Desktop had repeated 20s+ first-token delays for trivial prompts.
• Logs showed slow app/list and bundled plugin path issues.
• Disabling apps/plugins/Chrome bundled plugin made the app fast again.
• Pasted Windows images still expose Windows/WSL path bridge issues.

Related public issues

These look related to the same Windows/WSL desktop bridge area:

• https://github.com/openai/codex/issues/14576
• https://github.com/openai/codex/issues/18506
• https://github.com/openai/codex/issues/20858
• https://github.com/openai/codex/issues/21147
• https://github.com/openai/codex/issues/21693
• https://github.com/openai/codex/issues/3939

Request

Could the Codex team please check the Windows + WSL desktop bridge path normalization and the apps/plugins/Chrome bundled plugin initialization path?

The most suspicious behavior is:

app/list durationMs=18628

combined with malformed mixed paths like:

C:\mnt\c\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\0.1.7

Disabling apps/plugins is only a workaround. Ideally Codex Desktop should stay fast without requiring users to disable these features.