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

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

• #29348

Powered by Codex Action

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).

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.

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.

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.

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.

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.