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:

Codex Desktop became much slower than the VS Code extension in the same WSL project.
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:

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.

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

Chrome plugin Node REPL bootstrap fails from WSL due to Windows path/trust mismatch #21971
Windows Codex + WSL project: older threads lose cwd and terminal tries to cd into malformed WindowsApps/app/resources/\\wsl$ path #23189

Powered by Codex Action

Additional finding after further local debugging:

The strongest performance correlation is not session history size. The 20s first-token delay lines up with Codex Desktop's apps/plugins initialization path.

Evidence:

```text
app/list durationMs=18628

This is very close to the observed first-token delay:

time_to_first_token_ms=19506

Disabling the apps/plugins path in config.toml immediately made trivial prompts return to around 2-3 seconds:

[features]
apps = false
plugins = false

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

So the likely root cause is not the model, not context compaction, not .codex/sessions size, and not normal skills. It appears to be the Codex Desktop Windows + WSL apps/plugins bridge, especially around the bundled Chrome plugin / marketplace path handling.

This also seems related to the pasted-image issue, because both involve Windows paths being passed into a WSL runtime and needing correct /mnt/c/... normalization.

same

Additional finding after further local debugging:

The strongest performance correlation is not session history size. The 20s first-token delay lines up with Codex Desktop's apps/plugins initialization path.

Evidence:

app/list durationMs=18628
这与观察到的首令牌延迟非常接近：

time_to_first_token_ms=19506


禁用 apps/plugins 路径后，`config.toml`原本简单的提示信息立即恢复到 2-3 秒左右：

[features]
apps = false
plugins = false

[plugins."chrome@openai-bundled"]
enabled = false
因此，根本原因可能并非模型本身、上下文压缩、`.codex/sessions`大小或常规技能。问题似乎出在 Codex Desktop Windows + WSL 应用/插件桥接上，特别是捆绑的 Chrome 插件/应用市场路径处理方面。

这似乎也与粘贴图像问题有关，因为两者都涉及将 Windows 路径传递到 WSL 运行时，并且需要进行正确的`/mnt/c/...`规范化。

真的有用，太感谢了，这显然是chodex更新了他的插件商店导致的，关了马上变飞快

还真是，我禁用了之后秒回

The WSL bridge should log path translation and plugin/app initialization as separate timings.

For first-token delay, emit spans for app list, plugin discovery, Windows-to-WSL path normalization, image copy/import, and prompt dispatch. For image failures, store original Windows path, translated WSL path, existence check result, byte count, and error class.

Generated with ax.

Disclosure: I maintain WinBridge Recovery, an independent Windows recovery/diagnostic utility for Codex Desktop local Browser/Chrome/Computer Use state.

The app/list delay and the malformed C:\mnt\c\... bundled-plugin path in this report are useful because they suggest two separate things can coexist: an upstream Windows/WSL bridge performance bug, and a locally inconsistent bundled marketplace/cache state that makes plugin discovery/reconciliation much more expensive than it should be.

WinBridge is relevant only to the second part. It can compare the currently installed official Codex package with the user-owned openai-bundled marketplace/cache/runtime state, check versioned Browser/Chrome/Computer Use materialization and latest pointers, validate Windows-native helper/native-host paths, and rebuild supported user-side state with verification/rollback where it finds stale or malformed local state. It does not modify WindowsApps and it does not try to bypass product policy.

A useful A/B test for this issue would be:

keep the current “plugins disabled” workaround as the known-fast baseline;
verify/repair the local bundled-plugin state;
re-enable plugins and measure app/list plus first-token latency again.

If the paths/state are healthy but app/list still takes ~18–20s, that strongly points back to the Desktop WSL bridge/plugin initialization path upstream rather than something a local recovery tool should keep rewriting.

If anyone tests WinBridge on this exact Windows+WSL plugin-delay class, Worked / Partial / Failed reports are welcome here: zemeng5208/winbridge-recovery#4

Additional reproduction on current Codex Desktop Windows + WSL:

Environment:

Windows Codex Desktop package/runtime: 26.903.9818.0
WSL mode enabled; integrated terminal shell is WSL
Follow-up behavior: Queue
Local project opened through the WSL workspace path

Clipboard images are captured as %TEMP%\\codex-clipboard-<uuid>.png. The file is present and readable from WSL as /mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-<uuid>.png (verified with the same file that produced the error).

Observed behavior:

Sending directly from the main composer sometimes succeeds.
When the message is queued behind an active turn, the image can leave the message stuck in the queue; removing the image is required to continue.
The UI then reports: Error al crear el chat — local queued attachment is invalid: No such file or directory (os error 2).
If the queued message is edited, the UI can report: Error al crear el chat — App-server queued follow-up no longer exists.
A full application restart does not eliminate the intermittent behavior.
The queued item is not persisted with an attachment record, even though the temporary PNG exists and can be opened from WSL.

This looks like a queue/app-server attachment lifecycle or Windows-to-WSL path-normalization race, not a missing file and not project instructions. The direct-send path and queued-follow-up path behave differently.

Please correlate this with the Windows/WSL image-path issue in #23277 and the queued/attachment synchronization issue in #38055. It may also overlap with the queue lifecycle behavior discussed in #31874.

Additional occurrence of the exact queued-image error described in the September 11 comment, still present on a newer Windows Desktop build.

Environment, checked September 13, 2026

Windows desktop package: 26.908.4834.0, identified by the running app's package paths in its startup log.
Bundled app-server reports 0.154.0-alpha.6.2.
Agent runs through WSL2, Ubuntu 24.04.3 LTS. The desktop log confirms spawnCommand=wsl.exe.
A local Windows-drive project is opened through its WSL /mnt/c/... path.

Observed failure

Submitting an image attachment as a local follow-up fails with:

Error submitting message
local queued attachment is invalid: No such file or directory (os error 2)

The desktop log confirms two rejected thread/queue/add requests on September 13, 2026. Relevant fields below are abbreviated, with task IDs, request IDs and private paths omitted:

2026-09-13T07:54:43.619Z Request failed
  method=thread/queue/add durationMs=5
  error={"code":-32600,"message":"local queued attachment is invalid: No such file or directory (os error 2)"}

2026-09-13T07:55:08.436Z Request failed
  method=thread/queue/add durationMs=6
  error={"code":-32600,"message":"local queued attachment is invalid: No such file or directory (os error 2)"}

Each is immediately followed by a Composer submission failure with followUp=local mode=local. This locates the observed rejection in the queue-add request, before the follow-up can be accepted.

The same exact error was also recorded locally on September 12 with desktop package 26.903.9818.0 and app-server 0.153.4.

Attachment checks and evidence limits

The two most recent codex-clipboard-*.png files, written at 07:53:03 and 07:55:06 UTC, remain present under Windows Temp and can be read from this WSL environment using:

/mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-<uuid>.png

Both are 292,950 bytes with PNG headers reporting 1046 x 1145 pixels. A literal Windows C:\Users\<user>\... path does not resolve through Linux filesystem APIs.

The rejected RPC payloads are not recorded in the inspected logs, so I cannot establish the exact attachment pathname submitted in either failure. Windows-to-WSL path normalization or attachment staging is a plausible cause, not a confirmed root cause. This report is based on the user-observed failure and read-only inspection of existing logs/files, not a fresh automated UI reproduction.

Please include thread/queue/add in the Windows-to-WSL attachment handling investigation and regression coverage, in addition to initial sends and steering. A useful regression case is pasting an image into a WSL-backed task while a turn is active and submitting it as a queued follow-up, verifying that the attachment is readable and the message is accepted.

Related attachment-ingestion discussion: #27552.

Additional confirmation on Windows Desktop 26.917.8451.0 (package version observed in the desktop log), with the agent running in WSL2 Ubuntu and the project stored under /home/<user>/... in the WSL filesystem.

While a turn was active, I pasted a Windows clipboard screenshot into the composer and tried to Queue the follow-up. The UI immediately showed:

local queued attachment is invalid: No such file or directory (os error 2)

The desktop log recorded four rejected thread/queue/add requests on 2026-09-23 at 18:47:22, 18:47:34, 18:47:42, and 18:47:46 UTC. Each returned error code -32600 within 2–24 ms, followed by a Composer submission failure with followUp=local mode=local. Other thread/queue/add requests on the same day succeeded, so the queue itself was working.

A Windows clipboard PNG captured in the same desktop session was present and readable from WSL through /mnt/c/.... The rejected RPC payload was not recorded in the inspected logs, so I cannot identify the exact file submitted or confirm whether path normalization or attachment staging caused the failure.

Expected behavior: I can paste a screenshot and queue the message in a WSL-backed task without manually saving or relocating the image. Please include projects stored directly under /home in regression coverage for queued attachments.

Private paths, task IDs, prompts, and image contents are omitted.

Does this issue also cover historical image rendering in the Windows desktop app, or should that be tracked separately?

Earlier image messages in my conversation history show literal placeholder text instead of the image:

[Image]
<image_files>
The following images were provided by the user and saved to disk for future use:

The original image files were checked locally and still exist. This does not establish that the source files were deleted. I have not established that WSL is involved in this particular symptom.

My main concern is keeping images visible inline in the original conversation over time, rather than just keeping separate backup copies.

Is this a known attachment-reference/rendering problem? Is there a supported way to restore inline image display in existing messages, and any setting or recommended workflow to keep future images visible long-term? If this is unrelated to #23277, please point me to the appropriate issue.

The screenshot of the symptom contains only the placeholder text quoted above; it is not attached to this comment.

Navigation Menu

Repository navigation

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

Summary

Environment

Main performance issue

What I already ruled out

Important log evidence

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

2. Runtime install failed before manual replacement

3. Desktop app/plugin path bridge looked broken

Workaround that made response speed normal again

Pasted image path issue

Expected behavior

Actual behavior

Related public issues

Request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Main performance issue

What I already ruled out

Important log evidence

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

2. Runtime install failed before manual replacement

3. Desktop app/plugin path bridge looked broken

Workaround that made response speed normal again

Pasted image path issue

Expected behavior

Actual behavior

Related public issues

Request

Activity

github-actions commented on May 18, 2026

xuzhiqiang0038 commented on May 18, 2026

winter1215 commented on Jun 5, 2026

chienchenchen commented on Jun 5, 2026

lllllllllqm commented on Jun 5, 2026

Necmttn commented on Jun 21, 2026

zemeng5208 commented on Aug 16, 2026

omar-ramon commented on Sep 11, 2026

MartinMouritzen commented on Sep 13, 2026

4rkDev commented on Sep 23, 2026

cxk3014 commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions