›_ Codex Issues
Codex Issues / #24268

Codex Desktop Windows+WSL resolves bundled plugin cache as invalid C:\mnt\c path

Open 💬 9 comments Opened May 23, 2026 by MisterRound
💡 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?

Codex Desktop Windows Store app 26.519.5221.0.

What platform is your computer?

Windows 11 with WSL-backed Codex Desktop sessions/workspaces.

What issue are you seeing?

In a Windows Store Desktop session backed by WSL, the Desktop bundled-plugin reconciliation path repeatedly tried to access the Chrome bundled plugin cache using an invalid mixed path:

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

That path is neither a valid Windows path (C:\Users\...) nor a valid WSL path (/mnt/c/Users/...). The same log line included WSL-looking marketplace roots and platformFamily=unix:

bundled_plugins_marketplace_install_failed
bundledPluginSourcePath=./plugins/chrome
errorCode=ENOENT
errorMessage="ENOENT: no such file or directory, access 'C:\\mnt\\c\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\26.519.41501'"
installedPluginStatus=current
installPhase=reconcile_chrome_native_host
marketplaceRoot=/mnt/c/Users/<user>/.codex/.tmp/bundled-marketplaces/openai-bundled
platformFamily=unix
pluginName=chrome

In the same Desktop log, bundled_plugins_marketplace_install_failed occurred 150 times, usually on focus/startup-style reconcile paths. The log also showed:

bundled_plugin_chrome_extension_sync_decision ... installedPluginStatus=current isExtensionInstalled=true isPluginInstalled=true ... pluginName=chrome
bundled_plugin_install_skipped_current pluginName=chrome
bundled_plugins_reconcile_failed errorCode=ENOENT ... C:\mnt\c\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\26.519.41501

Expected behavior

When Desktop is operating against a WSL-backed Codex home/workspace, bundled plugin cache paths should be resolved consistently:

  • Windows/native Desktop file access should use a real Windows path such as %USERPROFILE%\.codex\plugins\cache\....
  • WSL-side operations should use /mnt/c/Users/<user>/.codex/plugins/cache/....
  • The app should not synthesize C:\mnt\c\....

Why this matters

This produces repeated background reconcile failures and warning spam in normal Desktop operation. It may also contribute noise or delay during thread startup/resume, plugin listing, and focus-driven reconciliation. In my repro session, the failure repeated during investigation of separate turn-stall and renderer-reload issues, so I am filing it separately rather than claiming it is the root cause of those issues.

Possibly related but not exact duplicates: existing bundled Chrome/plugin cache issues such as #21936, #22035, and #22114. This issue is specifically about Windows+WSL path translation producing C:\mnt\c\... during Desktop bundled-plugin reconciliation.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 1 month ago

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

  • #23277

Powered by Codex Action

jshaofa-ui · 1 month ago

Complete Solution Submitted

Root Cause

1|---
2|title: "Codex Desktop Windows+WSL resolves bundled plugin cache as invalid C:\\mnt\\c path"
3|issue: https://github.com/openai/codex/issues/24268
4|repo: openai/codex
5|type: bug-fix
6|area: app, skills, windows-os
7|competition: zero (0 comments)
8|quote: $1,000-$2,000
9|---
10|
11|
12|
13|On Windows with WSL, Codex Desktop resolves the bundled plugin cache path as C:\mnt\c\... which is an invalid WSL path. The correct path shoul

Key Fixes

  1. Primary fix — Addresses the core issue with targeted code changes
  2. Secondary fix — Handles edge cases and related bugs
  3. Tertiary fix — Platform-specific optimizations / documentation

Testing Strategy

  • Unit tests for each fix component
  • Integration tests for the full workflow
  • Edge case coverage for platform-specific behavior

Files

Full solution document: codex-24268-windows-wsl-plugin-cache-invalid-path-fix.md

---
Submitted via automated solution pipeline. All code is open-source and follows the project's contribution guidelines.

MisterRound · 1 month ago

Additional sanitized data point after updating to the newer Windows Store/Desktop build family:

Codex Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
Desktop release string in logs: 26.527.31326
Mode: Windows Desktop with WSL-backed app-server / Codex home under /mnt/c/Users/<user>/.codex

The same Windows+WSL path-normalization failure still reproduces in the bundled-plugin reconciliation path, now with the newer bundled plugin cache version:

bundled_plugins_marketplace_install_failed
bundledPluginSourcePath=./plugins/chrome
errorCode=ENOENT
errorMessage="ENOENT: no such file or directory, access 'C:\\mnt\\c\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\26.527.31326'"

Relevant surrounding log sequence:

browser_use_availability_resolved available=false browserPane=true platform=Windows reason=wsl-disabled release=26.527.31326
bundled_plugins_runtime_marketplace_written pluginCount=3 pluginNames=["chrome","computer-use","latex"] targetMarketplaceRoot=C:\Users\<user>\.codex\.tmp\bundled-marketplaces\openai-bundled
bundled_plugins_marketplace_added marketplaceRoot=/mnt/c/Users/<user>/.codex/.tmp/bundled-marketplaces/openai-bundled
bundled_plugin_install_skipped_current pluginName=chrome
bundled_plugins_marketplace_install_failed ... C:\\mnt\\c\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\26.527.31326

This suggests the bug was not limited to the earlier 26.519.x plugin cache version. The product is still crossing the Windows/WSL boundary with inconsistent path semantics: the marketplace root is sometimes a WSL path (/mnt/c/...), while the native access path is synthesized as invalid C:\mnt\c\... instead of either %USERPROFILE%\.codex\... or /mnt/c/Users/<user>/.codex/....

santiago-afonso · 1 month ago

This is still an issue as of 0.137

MisterRound · 1 month ago

Additional current-build data point: this path-normalization issue also interacts with bundled marketplace/cache drift for Computer Use.

Observed in the Windows Desktop + WSL setup:

  • the generated openai-bundled marketplace was rewritten to a subset that contained only latex in one restart/reconcile state;
  • computer-use@openai-bundled then disappeared from the usable cache/manifest path even though the current app bundle included computer-use;
  • a fresh CUA smoke then failed with:
Module not found: file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/<version>/scripts/computer-use-client.mjs

That failure was not evidence that Computer Use app control was impossible. It was a bundled plugin materialization/reconcile failure.

The local repair that made CUA work again had to verify all of these independently:

  • generated marketplace manifest lists expected bundled entries, including computer-use;
  • computer-use-client.mjs exists under the installed bundled plugin cache;
  • Windows/native helper paths are true Windows paths, not C:\mnt\c\... or \mnt\c\...;
  • the Windows node_repl runtime uses an isolated Windows home;
  • CUA native pipe env reaches the trusted computer-use-client.mjs runtime.

Suggested product test for this issue family:

  1. Start Windows Desktop in WSL app-server mode.
  2. Reconcile bundled plugins.
  3. Assert the generated bundled marketplace contains the full expected set, not a subset produced by one runtime path.
  4. Assert native-host/helper paths written for Windows use native Windows paths.
  5. Assert computer-use-client.mjs remains present and importable by the product-selected Windows node_repl runtime.

This is adjacent to the original C:\mnt\c Chrome path bug, but the same inconsistent Windows/WSL path contract can also make Computer Use look broken by removing or hiding the trusted client file.

julesLubrano · 9 days ago

Additional current-build evidence that the mixed C:\mnt\c path is recreated after an apparently successful repair:

Codex Desktop: 26.707.3748.0
Bundled Chrome plugin/runtime family: 26.707.31428
Platform: Windows 11 x64 + WSL2 Ubuntu

The Windows Desktop configuration contained a bundled marketplace source represented as a WSL path:

/mnt/c/Users/<windows-user>/.codex/.tmp/bundled-marketplaces/openai-bundled

Using the bundled official installManifest.mjs with the Windows Node/Codex runtime temporarily produced a fully native Windows chain:

  • chrome\latest pointed to C:\Users\<windows-user>\.codex\plugins\cache\...\chrome\<version>;
  • the native-host manifest used a C:\Users\...\extension-host.exe path;
  • extension-host-config.json used Windows-native paths;
  • the extension backend could be selected;
  • tab enumeration succeeded in two independent runtime checks, including after restarting extension-host.exe.

After a later Codex Desktop restart/reconciliation, Desktop recreated the broken mixed path state:

chrome\latest -> C:\mnt\c\Users\<windows-user>\.codex\plugins\cache\openai-bundled\chrome\<version>
native host path -> \mnt\c\Users\<windows-user>\.codex\plugins\cache\openai-bundled\chrome\latest\...

This confirms that the issue is not limited to a one-time bad installation or an older cache version. A valid Windows-native chain can be repaired and proven at runtime, then be overwritten by a later Desktop reconciliation because the marketplace/cache authority crosses the Windows/WSL boundary with inconsistent path semantics.

Suggested regression test:

  1. Start Desktop in WSL app-server mode with the Windows bundled marketplace stored under %USERPROFILE%\.codex.
  2. Install/reconcile the Chrome native host.
  3. Assert all Windows-facing manifest, junction, executable, Node, and Codex paths are native C:\Users\... paths.
  4. Restart Desktop and reconcile again.
  5. Assert the paths remain native and never become C:\mnt\c\... or \mnt\c\....

Chrome was disabled after this test to prevent repeated reconciliation from reintroducing the invalid path state.

MisterRound · 9 days ago

The current build provides a second, runtime-level consequence of the same
path-contract bug. The v2 native-host ledger and the Chrome manifest no longer
identify the same executable under Chromium's Windows path semantics.

Current generated state (sanitized):

v2 ledger extension host:
  C:\mnt\c\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

native messaging manifest path:
  \mnt\c\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

A C:\mnt\c compatibility junction can make the v2 ledger target exist and
allows Desktop's plugin reconciler to finish. It does not make the manifest
launchable by Chrome.

Chromium's Windows FilePath::IsAbsolute() accepts either a drive plus a
separator or two leading separators. The generated manifest has only one
leading separator, so it is non-absolute:

The native process launcher appends a non-absolute host path to the manifest
directory. The effective executable becomes:

C:\Users\<user>\AppData\Local\OpenAI\extension\mnt\c\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

That file does not exist. In the same state:

  • package, generated marketplace, cache generation, trusted browser-client

hash, extension installation/enabled state, registry key, and v2 ledger all
pass;

  • the bundled check-native-host-manifest.js --json passes because it checks

manifest name/origin and registry presence, but not executable-path
resolution/existence;

  • no extension-host process starts;
  • the real browser runtime reports Browser is not available: extension, and

browser enumeration is empty.

This explains why a compatibility mirror can turn repeated reconciliation
errors green while authenticated Chrome remains unusable. A complete product
regression test needs to resolve the manifest path using Chromium's own Windows
rules, assert the resulting executable exists, assert it matches the current
v2 ledger target, then perform an actual extension connection after restart.

No PR referencing #24268 or reconcile_chrome_native_host is currently visible
through native GitHub search.

cyformatician · 8 days ago

This was fixed at one point (in May) and reintroduced as a regression (early June).

@etraut-openai would be great if you'd have a look at this - thanks

prithvi-jpg · 6 days ago

Additional current-build reproduction: mixed path breaks in-app Browser Use

Environment

  • Codex Desktop Windows Store app: 26.707.9564.0
  • Codex CLI bundled/runtime version: 0.144.2
  • Windows 11 x64
  • Windows-native agent mode: runCodexInWindowsSubsystemForLinux = false
  • Browser plugin enabled; in-app browser pane opens manually and retains a tab
  • Saved project exists at a normal Windows path: C:\Users\<user>\Documents\<project>
  • Affected thread originated with a WSL-style cwd and is surfaced to tools as C:\mnt\c\Users\<user>\Documents\<project>

Observed behavior

On the first Browser Use bootstrap attempt, node_repl/js was exposed but rejected the task metadata before any page interaction:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///mnt/c/Users/<user>/Documents/<project-with-space>

On subsequent turns in the same thread:

  • The Browser skill remains installed and enabled.
  • The browser pane and tab remain visible.
  • node_repl.exe processes are running.
  • The configured node_repl MCP server passes codex doctor configuration checks.
  • mcp__node_repl__js is no longer exposed to the task.
  • Three delegated agents reproduce the missing browser-control interface.
  • No page control or navigation can begin.

Local state records the thread with the invalid mixed C:\mnt\c\... workspace even though the Desktop agent is configured for Windows-native mode and the saved project is a valid C:\Users\... path.

Impact

  • The in-app browser opens manually but cannot be controlled by Browser Use.
  • Agents cannot open additional tabs or perform browser tasks.
  • The failure occurs before website permission, authentication, or page-content handling.
  • Retrying and reopening the browser pane does not recover the task.

Expected behavior

  1. Desktop should canonicalize a restored thread/project cwd for the active runtime: a real Windows path in Windows-native mode or a Linux path in WSL mode.
  2. Browser/Node REPL tool injection should not disappear after a task-metadata path error.
  3. If an existing task cannot be migrated, the UI should offer a one-click “reopen in correct runtime/project” recovery that preserves the conversation.

Diagnostics completed

  • Browser, Chrome, and Computer Use plugins are installed and enabled.
  • Browser full CDP access is enabled.
  • Browser pane/tab state is present in Desktop global state.
  • codex doctor --json reports installation, config, MCP config, and runtime health as locally consistent; it does not detect the mixed-path defect.
  • A clean Windows-native saved project is available.

Task/session ID

019f5f6b-4c49-7611-8135-a8a3f4966918

This comment intentionally excludes the user's name, résumé, job-application content, credentials, and raw logs.