›_ Codex Issues
Codex Issues / #29413

Windows Desktop + WSL workspace: node_repl rejects /mnt/c sandboxCwd before Chrome/browser bootstrap

Open 💬 12 comments Opened Jun 22, 2026 by linzyjx
💡 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)?

Version 26.616.51431 Build 2026.6.21 ( Observed related plugin/runtime versions: - openai-bundled Chrome plugin: 26.616.51431 - Chrome extension: 1.1.5_0)

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop on Windows fails to start node_repl for a WSL workspace before any JavaScript code executes.

The workspace is opened from WSL as:

/mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

The same path maps cleanly to Windows:

C:\\Users\\<user>\\Documents\\Codex\\2026-06-22\\chrome-codex

However, calling mcp__node_repl__js fails before the provided JS code runs:

tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

This blocks Chrome/browser plugin bootstrap in WSL workspaces because the Chrome skill depends on node_repl.

The Chrome native host static configuration appears valid after repair:

  • Chrome is running.
  • Codex Chrome Extension is installed and enabled in the selected Chrome profile.
  • Native messaging manifest exists.
  • HKCU registry default value points to the manifest.
  • extension-host.exe exists.
  • extension-host-config.json exists.
  • browserClientPath, nodePath, nodeReplPath, and codexCliPath all point to existing files.

Despite that, the browser/Chrome bootstrap cannot start because node_repl rejects the WSL-style sandboxCwd before browser code is reached.

This looks like a WSL path-to-Windows-file-URI conversion issue. The Windows-side node_repl appears to receive:

file:///mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

but likely expects a Windows-local URI such as:

file:///C:/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows.
  1. Open a WSL workspace whose path is under /mnt/c, for example:

/mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

  1. Confirm the WSL path maps cleanly to a Windows path:

wslpath -w /mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

Expected output:

C:\\Users\\<user>\\Documents\\Codex\\2026-06-22\\chrome-codex

  1. Confirm WSL interop works:

cmd.exe /c ver

This succeeds and prints the Windows version.

  1. In Codex, invoke the Chrome/browser skill, or run a minimal node_repl call such as:

nodeRepl.write("hello");

  1. The call fails before the JavaScript code executes:

tool call failed for node_repl/js

Caused by:
Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

  1. Verify that the Chrome native host configuration is not the failing layer:
  • Chrome is running.
  • Codex Chrome Extension is installed and enabled.
  • Native messaging manifest exists.
  • HKCU native messaging registry entry points to the manifest.
  • extension-host.exe exists.
  • extension-host-config.json exists.
  • browserClientPath, nodePath, nodeReplPath, and codexCliPath all point to existing files.
  1. Retry the browser/Chrome bootstrap.

Actual result: it still fails at node_repl startup with the same sandboxCwd error, before browser code runs.

Session id / token usage / context usage:

Not available from the UI at the time of filing.

Possibly related issues found before filing:

  • #19365
  • #21147
  • #25280
  • #25090

What is the expected behavior?

When a Codex Desktop thread uses a WSL workspace, node_repl should either receive a Windows-local file URI for /mnt/c/... paths, for example:

file:///C:/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

instead of:

file:///mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

or run in the WSL/Linux context and accept Linux-local workspace paths.
The Chrome/browser plugin should be able to bootstrap from WSL workspaces when the native host configuration is valid.

Additional information

WSL uname -mprs:
Linux 6.6.114.1-microsoft-standard-WSL2 x86_64 x86_64

I initially investigated this as a Chrome extension/native host problem.

There were native host setup issues on this machine, but after manually repairing them the static checks pass:

  • Manifest path:

C:\\Users\\<user>\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json

  • Registry key:

HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension

  • Registry default value:

C:\\Users\\<user>\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json

  • Host path:

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

  • extension-host-config.json exists and points to existing files.

After this repair, the failure remains exactly at node_repl startup with the sandboxCwd is not a local file URI error. This suggests the remaining problem is independent of Chrome native messaging and is instead caused by WSL workspace path metadata being passed to a Windows-side runtime without conversion.

Also note: the bundled Chrome plugin package on this installation only contains the Windows host binary:

extension-host/windows/x64/extension-host.exe

No Linux/WSL native host binary was present, so installing Chrome inside WSL does not appear to be a practical workaround for this plugin.

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29348

Powered by Codex Action

Nicolas0315 · 2 months ago

I put up a branch for the WSL-to-Windows sandboxCwd path mismatch described here:

https://github.com/openai/codex/compare/main...Nicolas0315:codex/wsl-windows-mcp-sandbox-cwd?expand=1

Commit: 187047147bcf16a2f6a8fe302b8e7263482f9f90

What it changes:

  • Keeps each MCP server's stdio command in server metadata.
  • When Codex is running under WSL and the stdio MCP command is a Windows .exe launched through interop, rewrites only the codex/sandbox-state-meta.sandboxCwd value for that MCP call.
  • Maps /mnt/c/... to a Windows drive file URI such as file:///C:/....
  • Maps native WSL paths such as /home/... to file://wsl.localhost/<distro>/home/....
  • Leaves native Linux/WSL MCP commands and non-WSL hosts unchanged.

Verification:

  • rtx4090 local Windows: just fmt, git diff --check, focused codex-core tests, existing mcp_sandbox_cwd tests, codex-mcp metadata test, and cargo check -p codex-core -p codex-mcp all passed.
  • cyberagent-mac-m5max: fetched the commit over SSH, git diff --check, focused tests, and cargo check -p codex-core -p codex-mcp passed.
  • nicolas2025: fetched over SSH, git diff --check, focused tests, and cargo check -p codex-core -p codex-mcp passed; no lingering cargo/rustc/link processes.
  • nicolas-macbook-pro: fetched over SSH and git diff --check passed; cargo is not installed there.
  • rtx5060ti: fetched over SSH and git diff --check passed; Rust build is blocked by the machine's known link.exe setup issue (link: extra operand ...), with no lingering cargo/rustc/link processes.
  • git merge-tree --write-tree origin/main HEAD is clean against current origin/main (69596f0e4).
qwertz92 · 1 month ago

I can still reproduce this on 2026-07-02 after restarting Codex Desktop.

Environment:

  • Windows with the Codex agent and integrated terminal configured for WSL
  • Workspace stored on the Windows drive and exposed to WSL as:

/mnt/c/Users/<user>/Documents/Codex/<workspace>

  • Bundled Chrome and Computer Use plugin version: 26.623.81905

A minimal node_repl/js invocation fails before any JavaScript executes:

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

The same failure blocks both:

  • Computer Use before sky.list_apps() can run
  • Chrome/browser control before browser-client setup can run

Both plugin client files are installed. This appears to remain a WSL-to-Windows sandboxCwd URI translation issue rather than a Chrome, OpenAI login, or website issue.

bouze · 1 month ago

I can still reproduce this on 2026-07-03 after several Codex Desktop updates and a full Browser plugin reinstall/re-enable cycle.

Environment:

  • Windows Codex App with the agent environment set to WSL
  • Codex CLI in WSL: codex-cli 0.142.3
  • BROWSER_USE_CODEX_APP_VERSION="26.623.81905"
  • BROWSER_USE_AVAILABLE_BACKENDS="chrome"
  • Browser plugin: enabled
  • node_repl: enabled
  • WSL workspace:
  • Linux path: /home/<user>/projects/<repo>
  • Windows UNC form: \\wsl.localhost\Ubuntu\home\<user>\projects\<repo>
  • WSL CODEX_HOME points to the Windows Codex home: /mnt/c/Users/<user>/.codex

Minimal smoke test:

nodeRepl.write('ok')

Observed result in the WSL filesystem workspace:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///home/<user>/projects/<repo>

I also tested a Windows-filesystem workspace while the Codex App agent environment was still set to WSL:

Windows path: C:\Users\<user>\Documents\BrowserUseTest
WSL path: /mnt/c/Users/<user>/Documents/BrowserUseTest

That fails before JavaScript execution as well:

tool call error: tool call failed for `node_repl/js`

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

Control case:

With the Codex App agent environment switched to Windows native, a Windows-filesystem test project succeeds:

C:\tmp\codex-browser-repro

Results in that control case:

  • nodeRepl.write('ok'): succeeds
  • Browser Use initialization: succeeds
  • Opening http://127.0.0.1:8768/index.html: succeeds
  • DOM snapshot: succeeds
  • Screenshot: succeeds
  • Click verification: succeeds

Result matrix:

| Agent environment | Workspace | Result |
| --- | --- | --- |
| Windows native | C:\tmp\codex-browser-repro | Success |
| WSL | /home/<user>/projects/<repo> | Fails before JS execution |
| WSL | /mnt/c/Users/<user>/Documents/BrowserUseTest | Fails before JS execution |

This makes the failure look broader than just a WSL-filesystem path issue. As long as the agent environment is WSL, sandboxCwd is generated as a Linux file URI (file:///home/... or file:///mnt/c/...) and the Windows-side node_repl.exe rejects it before Browser Use, Chrome setup, or any JavaScript can initialize.

The current best diagnosis is still a WSL-agent-to-Windows-node_repl sandbox metadata path/URI namespace mismatch.

masonpetrosky · 1 month ago

Adding another data point from Windows + WSL mode, with one extra bit of instrumentation that may help locate the failing layer.

Environment / setup:

  • Codex Desktop on Windows with agent environment and integrated terminal set to WSL.
  • WSL CLI: codex-cli 0.142.4.
  • Workspace is a native WSL path: /home/<user>/projects/economics.
  • Chrome plugin is installed/enabled, but the failure occurs before any Chrome/browser-client code can run.

Minimal live tool call still fails:

nodeRepl.write("ok")

Observed result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///home/<user>/projects/economics

Additional proxy/bypass evidence:

I configured [mcp_servers.node_repl] to point at a small WSL Python proxy instead of directly at the Windows node_repl.exe. codex mcp get node_repl reports the expected proxy command:

command: /usr/bin/python3
args: /mnt/c/Users/<user>/.codex/bin/node_repl_wsl_proxy.py

That proxy logs incoming tools/call metadata and rewrites WSL sandboxCwd file URIs before forwarding to the Windows runtime. Manual/synthetic proxy tests show it does rewrite the path, for example:

file:///home/<user>/projects/economics
=> file://wsl.localhost/Ubuntu-24.04/home/<user>/projects/economics

However, after a full Codex Desktop restart and a fresh thread, the actual mcp__node_repl.js tool call above still fails with the original file:///home/... value, and the proxy trace receives no new entry from that live call.

At the same time, the process tree shows both:

codex app-server -> node_repl.exe                  # direct Windows runtime child
codex app-server -> node_repl_wsl_proxy.py -> node_repl.exe

So the visible config says node_repl is proxied, and the proxy works in isolation, but the live exposed mcp__node_repl.js tool appears to be bound to a Desktop/app-server-owned direct node_repl.exe route instead of the configured [mcp_servers.node_repl] command.

That seems consistent with this being a Desktop Windows+WSL app-server/runtime bridge issue rather than a Chrome plugin install issue. It may also explain why config-level MCP workarounds do not fully resolve the problem: the Desktop-managed Node REPL bridge can still bypass the configured MCP server entry.

masonpetrosky · 1 month ago

Follow-up: Computer Use is affected by the same bridge failure in this WSL session.

The Computer Use plugin files are installed, including:

/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/26.623.101652/scripts/computer-use-client.mjs

But the prescribed lightweight Computer Use bootstrap/list-apps call fails before Computer Use can initialize:

if (!globalThis.sky) {
  const { setupComputerUseRuntime } = await import("/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/26.623.101652/scripts/computer-use-client.mjs");
  await setupComputerUseRuntime({ globals: globalThis });
}
globalThis.apps = await sky.list_apps();
nodeRepl.write(JSON.stringify(apps, null, 2));

Observed result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///home/<user>/projects/economics

So the issue is not Chrome-specific on this machine. In WSL agent mode, both Chrome and Computer Use are blocked at the shared node_repl/js bridge layer before either plugin's own client code can run.

gilmarvitor · 1 month ago

Another occurrence of this same bug (Feedback ID: 019f68a0-acfa-7be3-af89-9082ba15d05c):

Chrome fails to connect from a WSL2 workspace before reaching the extension. node_repl/js rejects the codex/sandbox-state-meta before any JS runs:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///mnt/c/Users/<user>/Documents/Codex/<date>/chrome-integration-validation

Expected behavior: the desktop integration should translate the WSL path into a Windows-local URI (e.g. file:///C:/Users/<user>/Documents/Codex/<date>/chrome-integration-validation) or run the Chrome bridge inside the WSL context, consistent with what's already reported in this issue.

AbdelhamidQ · 1 month ago

Still reproducible on 2026-07-21 with a newer Codex Windows/Computer Use build. This reproduction is specifically through the bundled Computer Use plugin, not only Chrome/browser use.

Environment

  • Codex Windows package: 26.715.7063.0
  • Bundled Computer Use plugin: 26.715.52143
  • Platform: Microsoft Windows NT 10.0.26200.0 x64
  • Codex agent environment: WSL
  • Integrated terminal: WSL
  • Workspace stored on the Windows drive and exposed to the agent as:

/mnt/c/Users/<user>/Documents/Codex/2026-07-21/<workspace>

  • Corresponding Windows location:

C:\Users\<user>\Documents\Codex\2026-07-21\<workspace>

  • runCodexInWindowsSubsystemForLinux = true
  • The configured Node REPL runtime is the bundled Windows node_repl.exe
  • Target app: Zen Browser, installed at C:\Program Files\Zen Browser\zen.exe and already running
  • Computer Use plugin: installed and enabled
  • Codex task/thread ID: 019f8465-cade-7882-9274-5f709a5d8faa

Minimal reproduction

Following the bundled Computer Use skill's prescribed initialization:

if (!globalThis.sky) {
  const { setupComputerUseRuntime } = await import(
    "/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/26.715.52143/scripts/computer-use-client.mjs"
  );
  await setupComputerUseRuntime({ globals: globalThis });
}

var guidanceDoc = await sky.documentation("guidance");

The mcp__node_repl__js call fails before any supplied JavaScript executes:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///mnt/c/Users/<user>/Documents/Codex/2026-07-21/<workspace>

Because validation fails before execution, Computer Use cannot initialize, read its runtime documentation, call sky.list_apps(), request app approval, capture a window, or interact with Zen. Zen itself is installed and running, and the Computer Use plugin files are present, so this is not a missing-app, missing-plugin, or browser-permission failure.

This appears to be the same WSL-agent-to-Windows-node_repl.exe URI namespace mismatch already identified here. The Windows-side runtime receives:

file:///mnt/c/Users/<user>/Documents/Codex/2026-07-21/<workspace>

where it likely requires:

file:///C:/Users/<user>/Documents/Codex/2026-07-21/<workspace>

This confirms that the issue remains present in the 26.715 app/plugin release and affects the bundled Computer Use plugin before its own client code can run.

Leandroglez39 · 1 month ago

Additional reproduction: still present in 26.721 and affects both Chrome and the in-app browser

Observed on 2026-07-25 with a newer Codex Desktop build than the previously reported 26.715 reproduction.

Environment
  • Codex Windows package: 26.721.4979.0
  • Bundled Chrome plugin/runtime: 26.721.41059
  • Platform: Microsoft Windows NT 10.0.26200.8894 x64
  • Agent environment: WSL2
  • Distribution: Ubuntu 24.04
  • WSL kernel: 6.18.33.1-microsoft-standard-WSL2
  • Workspace: native WSL path /home/<user>/UNAV/Master
  • WSL interop is working: cmd.exe /c ver succeeds
  • wslpath -w /home/<user>/UNAV/Master resolves to \\wsl.localhost\Ubuntu-24.04\home\<user>\UNAV\Master
  • The configured node_repl command is the bundled Windows node_repl.exe; its Node runtime and trusted paths are also Windows paths.
Minimal reproduction

A minimal Node REPL call fails before the supplied JavaScript executes:

nodeRepl.write("ok");

Result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///home/<user>/UNAV/Master

The same pre-execution validation failure occurs when attempting to initialize:

  1. The bundled Chrome plugin through an explicit @Chrome request.
  2. The in-app browser through an explicit integrated-browser request.
  3. The bundled Computer Use runtime.

In every case, the failure happens at the shared node_repl/js boundary before browser-client.mjs or computer-use-client.mjs can execute. This means the browser backend, current page, Chrome profile, website allowlist, and Chrome native messaging layer are never reached.

As a control check, launching the installed Windows Chrome executable directly from WSL with Windows interop succeeds and opens the requested URL. What remains unavailable is browser automation and inspection through the Codex bridge.

This further supports the diagnosis that the Desktop-managed Windows node_repl.exe is receiving a Linux-local sandboxCwd URI without namespace conversion. For a native WSL path, it likely needs a UNC-style Windows URI such as:

file://wsl.localhost/Ubuntu-24.04/home/<user>/UNAV/Master

Alternatively, the Node REPL runtime needs to execute in WSL and accept file:///home/... as local.

The issue therefore remains reproducible in the 26.721 release and is not limited to /mnt/c/... workspaces or to the Chrome extension specifically.

khukhunaishvili · 29 days ago

Still reproducible on 2026-07-30 in a newer Windows Codex Desktop build, using a native WSL filesystem workspace.

Environment:

  • Codex Desktop app/runtime: 26.721.81911
  • Bundled WSL Codex CLI: codex-cli 0.146.0-alpha.3.1
  • Separately installed WSL CLI: codex-cli 0.146.0
  • Agent environment: WSL
  • Workspace shape: /home/<user>/dev/<worktree>
  • Configured Node REPL remains the bundled Windows node_repl.exe

The built-in Browser call fails before navigation or browser client initialization:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///home/<user>/dev/<worktree>

Launching the installed Windows Chrome executable directly from WSL with headless screenshot flags succeeds against the same local application in about 7.6 seconds. This confirms the local app, host alias, WSL interop, and Chrome itself are healthy; the failure remains at the Desktop-managed WSL-to-Windows Node REPL metadata boundary.

This build therefore still needs either a translated UNC-style URI for native WSL paths or a Node REPL runtime that accepts Linux-local file URIs.

jotalillo · 23 days ago

This issue is still reproducible on 2026-08-05 in my WSL environment.

Codex reports the following error:

sandboxCwd is not a local file URI:
file:///mnt/c/Users/jlill/Documents/Codex/

The workspace is located on the Windows filesystem and accessed through /mnt/c from WSL. Codex remains configured to run under WSL.

libaiyun · 22 days ago

I can reproduce the same practical limitation with Codex Desktop on Windows while using WSL as the agent environment.

In my case, the Integrations UI reports that the in-app browser plugin is unavailable. Updating the Codex App did not change this. I intentionally removed the Chrome integration because it is not usable from my WSL workflow, and reinstalling the whole App is not an acceptable workaround because I need to preserve existing local conversations.

The relevant runtime configuration exposes no usable browser backend in the WSL agent environment (BROWSER_USE_AVAILABLE_BACKENDS is empty). This makes the report's conclusion especially useful: Chrome/native-host repair is not a workaround for WSL, since the bootstrap path fails before browser code runs and the bundled Chrome host is Windows-only.

A supported WSL browser backend, or correct WSL-path handling by the Windows-side runtime, would be needed. Thanks for the detailed diagnosis.