Browser Use Node REPL fails in Windows Desktop app with WSL workspace due to unmapped sandboxCwd

Open 💬 15 comments Opened Jun 23, 2026 by atlantho

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Browser Use / Node REPL does not work in the Codex Windows Desktop app when the agent is configured to run in WSL and the project lives on the WSL filesystem. The Desktop app auto-generates a node_repl MCP server that runs a Windows node_repl.exe, but tool calls send a Linux/WSL sandboxCwd URI (file:///home/...). The Windows-side Node REPL rejects that path as not being a local file URI.

All paths below are anonymized.

Environment

Codex Desktop app on Windows
Agent configured to run in WSL2
Integrated terminal configured as WSL
WSL distro: Ubuntu 22.04
Project path inside WSL: /home/<user>/projects/<repo>
Windows view of same project: \\wsl.localhost\Ubuntu-22.04\home\<user>\projects\<repo>
CODEX_HOME inside the WSL agent session: /mnt/c/Users/<windows-user>/.codex
Codex CLI from codex doctor: Codex Doctor v0.142.0 · linux-x86_64
Desktop/browser runtime version visible in generated MCP env: BROWSER_USE_CODEX_APP_VERSION=26.616.71553
Browser Use plugin enabled

Relevant config state:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

[plugins."browser-use@openai-bundled"]
enabled = true

Reproduction Steps

On Windows, configure Codex Desktop to run the agent in WSL.
Open a project located on the WSL filesystem, e.g. /home/<user>/projects/<repo>.
Enable the Browser Use plugin.
Start/restart Codex Desktop.
Inspect MCP configuration from the WSL agent session:

codex mcp get node_repl

Codex Desktop auto-generates a user-level MCP server similar to:

[mcp_servers.node_repl]
command = "/mnt/c/Users/<windows-user>/AppData/Local/OpenAI/Codex/runtimes/cua_node/<runtime-id>/bin/node_repl.exe"
startup_timeout_sec = 120

[mcp_servers.node_repl.env]
BROWSER_USE_AVAILABLE_BACKENDS = "chrome"
CODEX_HOME = "C:\\Users\\<windows-user>\\.codex"
CODEX_CLI_PATH = "/usr/local/bin/codex"
WSLENV = "..."

Trigger a Node REPL JS call, for example through Browser Use setup or directly via the exposed node_repl/js tool.

Actual Behavior

The Node REPL tool is visible, but every JS execution fails immediately:

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>

This blocks Browser Use entirely. The in-app browser cannot be automated from Codex in this setup.

Expected Behavior

When the Desktop app is configured to run the agent in WSL, Browser Use should work for WSL-hosted projects. Either:

the node_repl MCP process should run in the matching WSL/Linux environment, or
Codex should map the WSL sandbox cwd to a Windows-local/UNC path before passing it to a Windows-side node_repl.exe, e.g. \\wsl.localhost\Ubuntu-22.04\home\<user>\projects\<repo>, or
Browser Use should provision its internal Node REPL / backend in a way that does not mix Windows runtime expectations with Linux file:///home/... sandbox metadata.

Additional Diagnostics

codex doctor --summary from the WSL agent session confirms the agent/runtime is Linux/WSL:

Codex Doctor v0.142.0 · linux-x86_64
Environment: Ubuntu 22.04, WSL_DISTRO_NAME present
Configuration: config loaded from /mnt/c/Users/<windows-user>/.codex/config.toml
MCP: 1 server (1 stdio)
Sandbox: restricted fs + restricted network

codex mcp get node_repl confirms the generated MCP server uses a Windows executable:

command: /mnt/c/Users/<windows-user>/AppData/Local/OpenAI/Codex/runtimes/cua_node/<runtime-id>/bin/node_repl.exe
cwd: -

I also tested adding an explicit UNC cwd to the generated MCP block:

cwd = '\\wsl.localhost\Ubuntu-22.04\home\<user>\projects\<repo>'

Codex accepted and displayed that cwd via codex mcp get node_repl, but the tool still failed with the same sandboxCwd is not a local file URI: file:///home/... error. After restarting Codex Desktop, the generated MCP block was overwritten again and the explicit cwd was removed.

I also tested disabling the Chrome and Computer Use plugins while keeping Browser Use enabled. Codex Desktop still regenerated the same Windows node_repl.exe MCP block with BROWSER_USE_AVAILABLE_BACKENDS = "chrome".

I did not use --disable-sandbox; this report is about the default sandboxed path.

View original on GitHub ↗

15 Comments

github-actions[bot] contributor · 2 months ago

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

#29413
#29482

Powered by Codex Action

atlantho · 2 months ago

This is related to #29413 and likely shares the same root cause, but this report covers a distinct reproduction variant: the project is stored on the native WSL filesystem under /home/..., not on a Windows-mounted /mnt/c/... path. It also specifically blocks Browser Use / in-app browser automation, not only Chrome extension bootstrap.\n\nI tested adding an explicit Windows UNC cwd for the generated node_repl MCP server, e.g. \\wsl.localhost\Ubuntu-22.04\home\<user>\projects\<repo>. Codex accepted and displayed that cwd, but the tool call still failed because the internally sent sandbox metadata remained sandboxCwd=file:///home/.... After restarting Codex Desktop, the generated MCP block was overwritten again.\n\nSo this may be the same underlying sandboxCwd mapping issue as #29413, but it confirms the failure also affects native WSL filesystem projects and Browser Use / IAB.

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

atlantho · 1 month ago

Version and severity update: this still matters on the current Codex 0.143.0 setup.

The original report was filed with 0.142.0, but Browser Use / Node REPL remains blocked in the Windows Desktop + WSL-backed runtime/workspace configuration. This should be treated as critical for this setup because Browser Use / in-app browser automation is a core Codex Desktop capability, not an optional diagnostic feature.

Current relevant setup:

Windows Codex Desktop
WSL-backed agent/runtime
Browser Use enabled
Codex CLI 0.143.0

The user-visible impact is that Browser Use cannot be used reliably in this Windows Desktop + WSL-backed configuration.

tompw89 · 1 month ago

Current-build update from a fresh Windows Desktop + WSL reproduction.

Current state

MSIX package: 26.707.3748.0
Desktop/browser release: 26.707.31428
WSL Codex CLI: 0.144.1
Project on native WSL storage: /home/<wsl-user>/projects/<repo>
generated Windows node_repl.exe MCP is present and enabled
generated MCP env correctly points at the WSL-specific home: CODEX_HOME=C:\Users\<windows-user>\.codex_wsl
BROWSER_USE_AVAILABLE_BACKENDS="chrome"

A no-op JS call still fails before execution with the exact error tracked here:

tool call failed for node_repl/js

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

The failure persists after fully quitting and relaunching Codex Desktop.

Separate Desktop eligibility gate

The same fresh launch also logs:

browser_use_availability_resolved available=false browserPane=true platform=Windows reason=wsl-disabled release=26.707.31428

Settings correspondingly shows:

In-app browser plugin unavailable

Both browser_use and in_app_browser are enabled.

Runtime health isolation

The primary Workspace Dependencies runtime is now healthy and Settings reports 26.709.11516; its bundled Node v24.14.0 and Python 3.12.13 execute successfully. This rules out the previously missing workspace dependency bundle as the cause of the Node REPL sandboxCwd failure.

This suggests there are currently two distinct gates for WSL Browser Use:

the sandboxCwd URI sent to a Windows-side stdio MCP process is not translated from WSL semantics; and
Desktop explicitly resolves Browser availability to reason=wsl-disabled.

A sandboxCwd translation fix appears necessary, but may not by itself enable the in-app Browser unless the Desktop availability gate and IAB backend provisioning are also changed.

satyalyadav · 1 month ago

Fresh reproduction on 2026-07-13 with a newer Windows Desktop build.\n\nEnvironment:\n- Codex Desktop MSIX: 26.707.8479.0\n- Browser runtime/plugin reported in generated node_repl env: 26.707.62119\n- WSL Codex CLI: 0.144.1\n- Agent environment: WSL\n- Integrated terminal: WSL\n- Workspace: native WSL path under /home/<user>/writer\n- Generated node_repl command: Windows node_repl.exe under the Codex cua_node runtime\n\nA minimal call that does not initialize Chrome or browser-client:\n\n nodeRepl.write(nodeRepl.cwd)\n\nstill fails before JavaScript execution:\n\n Mcp error: -32602: js: codex/sandbox-state-meta:\n sandboxCwd is not a local file URI: file:///home/<user>/writer\n\nThe Windows bridge process is present and running, BROWSER_USE_AVAILABLE_BACKENDS is set to chrome, and WSL can map the workspace to:\n\n \\wsl.localhost\Ubuntu\home\<user>\writer\n\nThis remains a pre-browser WSL-to-Windows sandboxCwd translation failure on the current build.

tanjaduro · 1 month ago

Confirming this exact issue on a later Windows build.

Product shown in About: Powered by Codex & OWL
Version: 26.707.72221
Release date: 14 July 2026
Platform: Windows, with the agent configured to run in WSL2 / Ubuntu
Project location: WSL filesystem (/home/...), not /mnt/c/...

The built-in browser-control tool fails before executing any requested JavaScript:

node_repl/js: Mcp error: -32602
codex/sandbox-state-meta: sandboxCwd is not a local file URI:
file:///home/<user>/code/personal/<project>

The same error occurs for a minimal, harmless JavaScript request that does not attempt navigation or page interaction.

Local Codex session logs record the failure before the supplied JavaScript runs. The Desktop application logs also show that browser control uses a native Windows runtime:

C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe

The logged runtime reports:

Node v24.14.0
platform win32

The observed flow is therefore:

WSL workspace
→ sandboxCwd represented as file:///home/...
→ native Windows node_repl.exe browser runtime
→ URI rejected before JavaScript execution

Ordinary repository operations through Codex CLI inside WSL work correctly. This confirms that the repository and normal WSL execution are functional, although the CLI does not expose an equivalent Desktop in-app browser-control bridge.

Windows can access the same repository through its UNC path:

\\wsl.localhost\Ubuntu\home\<user>\code\personal\<project>

However, I could not complete an equivalent node_repl/js comparison from a UNC-backed Codex task. The UNC-backed sessions inspected encountered a separate Windows sandbox/CMD UNC-path error before reaching browser control. Therefore, opening the project through UNC remains an inconclusive workaround rather than a verified fix or failure.

I inspected the available Windows and WSL Codex configuration and found no supported user-level setting for translating sandboxCwd from a WSL path into a Windows-accessible representation.

No repository files, Codex binaries, bundled runtimes, application configuration, browser-security settings, sandbox settings, or system settings were modified.

Expected behavior: before a WSL-backed task invokes a native Windows MCP or browser-control runtime, Codex should normalize sandboxCwd to a Windows-accessible path or valid file URI derived from the equivalent Windows or UNC path.

The failure appears independent of the repository and website content because it occurs before the requested JavaScript executes.

I can provide sanitized excerpts from the Codex session log and Desktop application log if useful.

tanjaduro · 1 month ago

Additional current-build check from 26.707.72221:

Local WSL CLI: codex-cli 0.144.4.
Latest stable release checked: 0.144.5; release notes do not include the WSL sandboxCwd fix.
Proposed commit 187047147bcf16a2f6a8fe302b8e7263482f9f90 exists but is not on current main, rust-v0.144.5, or rust-v0.145.0-alpha.16; GitHub

shows no associated PR.

Local installed binaries do not contain the expected file://wsl.localhost mapping string.
node_repl/js still fails before JS execution with:

codex/sandbox-state-meta: sandboxCwd is not a local file URI: file:///home/tdurova/code/personal/wiso-steuer-front-forms

Local Desktop logs also show browser_use_availability_resolved ... reason=wsl-disabled, so even after sandboxCwd mapping lands, Browser Use may

still need the WSL availability gate addressed.

Opening the same repo through UNC is not a verified workaround; it appears to hit the separate sandbox ACL/setup class tracked in #24101.

oteme · 1 month ago

Still reproducible on 2026-07-22 with a newer build.

Environment (paths anonymized):

Codex Desktop AppX: 26.715.2305.0
WSL agent: codex-cli 0.145.0-alpha.18
WSL distro: Ubuntu 24.04 / WSL2 kernel 6.6.87.2
Windows CUA Node runtime: node_repl 20260713.2, Node 24.14.0, windows-x64
Chrome plugin: 26.715.21425

A minimal read-only call such as nodeRepl.write("hello") fails before JavaScript execution:

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

I also ran a controlled comparison against the same bundled Windows node_repl.exe process:

sandboxCwd: file:///C:/Users/<user> -> succeeds; reported cwd is C:\\Users\\<user>
same request with sandboxCwd: file:///home/<user>/<project> -> reproduces the exact -32602 error

Changing only an exec command's workdir to /mnt/c/... does not affect the MCP metadata; the thread's WSL workspace cwd is still sent. Full access also does not avoid the failure: the permission profile is unrestricted/disabled, but sandboxCwd is still attached and validated.

This further isolates the failure to WSL-to-Windows sandboxCwd URI conversion before browser/Chrome bootstrap, rather than the Chrome extension or native host. No Codex binaries, configuration, browser settings, or repository files were modified.

atlantho · 1 month ago

Confirming the same failure on the current stable setup here as well.

Environment:

Codex CLI: 0.145.0
Codex Desktop/browser runtime signal in generated node_repl env: 26.715.72028
Windows Desktop app with WSL-backed runtime/agent
Workspace: native WSL path under /home/<user>/<project>
Generated node_repl command: Windows node_repl.exe under the Codex cua_node runtime

The official Browser Use / in-app browser path still fails before browser-client or Chrome initialization. A direct attempt to run setupAtlasRuntime with backend iab and open a tab fails at node_repl/js before JavaScript execution:

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

This matches oteme’s controlled comparison: the failure is still in the WSL-to-Windows sandboxCwd URI translation before browser/bootstrap code runs, not in Chrome, Browser Use UI, or the target web app.

xinvxueyuan · 1 month ago

Adding another confirmation from a Debian WSL setup — I’m hitting the same failure with a project on the native WSL filesystem:

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/xinvdev/lingchu-bot

My Codex Desktop agent is running in WSL, while the generated Node REPL runtime is the native Windows node_repl.exe. The call fails during sandboxCwd validation, before any JavaScript is executed.

One detail that may help rule out a configuration workaround: the js_repl feature flag does not affect this behavior. Disabling or enabling that feature does not change the path validation failure, because the invalid file:///home/... value is still sent to the Windows-side Node REPL and rejected there.

So this looks consistent with the path-namespace mismatch already discussed here, rather than a feature-flag issue. For a Windows .exe MCP launched from a WSL-backed task, the metadata needs to be translated into the MCP process’s path namespace — for example /home/... to a Windows-accessible WSL URI/UNC representation, and /mnt/c/... to file:///C:/....

The proposed targeted rewrite in the community branch sounds like the right direction. I’d definitely like to see this supported officially, since the current failure blocks Node REPL and the browser integrations entirely for WSL-native projects.

diegoxfx · 27 days ago

Confirming that this is still reproducible on a newer build as of 2026-08-01.

Environment:

Codex Desktop / bundled Browser plugin: 26.727.51351
Bundled Codex CLI: 0.146.0-alpha.9.2
Windows Desktop app with the agent configured to run in WSL
WSL2 Ubuntu 24.04
Workspace stored on the native WSL filesystem under /home/<user>/<project>
Generated MCP command points to the native Windows node_repl.exe
runCodexInWindowsSubsystemForLinux = true

A minimal node_repl/js call still fails before any supplied JavaScript executes:

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

The normal WSL sandbox is otherwise operational: the exact Codex-bundled bubblewrap binary is installed and ordinary sandboxed command execution succeeds. This isolates the remaining failure to the WSL-to-Windows sandboxCwd bridge used by the Windows Node REPL, rather than to bubblewrap, the repository, or the target web application.

There does not appear to be a user-facing setting that maps this URI. The Browser integration remains blocked for WSL-native workspaces on this build.

medking82 · 26 days ago

Fresh reproduction and current-main code check (2026-08-01).

Environment

Codex Desktop MSIX: 26.727.6591.0
Desktop-bundled Codex CLI: 0.146.0-alpha.9.2
Bundled Chrome plugin: 26.727.51351
Windows Desktop with the agent running in WSL2
Workspace on native WSL storage: /home/<user>/github/codex
Generated node_repl command: native Windows node_repl.exe reached through /mnt/c/...

A minimal Chrome runtime setup call still fails before any supplied JavaScript, browser discovery, or extension communication:

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

Chrome is running and the extension-installed/enabled checks pass, but those states are downstream of this specific rejection.

Current-main check

At current main commit ee0247f95a6f, augment_mcp_tool_request_meta_with_sandbox_state still selects the server environment's PathUri and serializes it unchanged. It does not translate that URI into the target stdio server process's path namespace.

I also fetched the community prototype 187047147bcf16a2f6a8fe302b8e7263482f9f90. Its intended behavior still matches the failure, but it no longer applies cleanly to current main because the MCP call path has moved to the newer PreparedMcpCall / captured McpConfig architecture.

A focused repair boundary appears to be: when a WSL session calls a Windows stdio MCP server, translate only codex/sandbox-state-meta.sandboxCwd for that target runtime:

/mnt/c/... -> file:///C:/...
/home/...  -> file://wsl.localhost/<distro>/home/...

Native Linux servers and non-WSL hosts should remain unchanged. Regression coverage should include both mappings, URI encoding, and unchanged native-server behavior.

This is a separate, earlier blocker from #30265: this issue fails before JavaScript; #30265 concerns subsequent Desktop plugin/native-host reconciliation.

I understand external contributions are invitation-only. Could a maintainer confirm the preferred ownership layer for this conversion and, if appropriate, invite a focused PR adapting the regression tests and repair to current PreparedMcpCall?

StreamVi · 24 days ago

Fresh reproduction on 2026-08-04 with Codex Desktop on Windows and an Ubuntu 22.04 WSL workspace. Codex CLI: 0.144.6. A minimal node_repl/js request still fails before JavaScript execution with:

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

The issue has persisted across multiple Codex Desktop updates and completely blocks in-app browser verification for WSL-hosted projects. Please prioritize WSL-to-Windows path normalization or run the browser-control runtime inside WSL.

StreamVi · 15 days ago

Additional reproduction on 2026-08-12. This remains reproducible in Codex Desktop on Windows with the agent and workspace running in WSL.

Environment (sanitized):

Windows 10 x64
WSL workspace: /home/<user>/<repo>
Codex CLI in WSL: 0.146.0
Windows-side bundled Codex CLI: 0.146.0-alpha.9.2
Browser Use skill using the iab backend

A minimal node_repl/js bootstrap fails before any supplied JavaScript 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:///home/<user>/<repo>

Reproduction:

Open a project under /home/<user>/<repo> in Codex Desktop on Windows with Codex configured to run in WSL.
Open/select an in-app browser tab.
Invoke any harmless Browser Use operation, which bootstraps through mcp__node_repl__js.
The tool rejects sandboxCwd before the JavaScript is evaluated.

Filesystem, Git, shell commands, frontend tests, and the in-app browser itself continue to work; only the agent-to-browser control bridge is blocked. This has occurred repeatedly across unrelated WSL projects, so it is not project-specific.

Expected behavior: translate the WSL workspace path to a Windows-accessible local/UNC URI before invoking the Windows-side runtime, or run node_repl inside WSL so file:///home/... is local to that process.