›_ Codex Issues
Codex Issues / #29639

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

Open 💬 8 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

  1. On Windows, configure Codex Desktop to run the agent in WSL.
  2. Open a project located on the WSL filesystem, e.g. /home/<user>/projects/<repo>.
  3. Enable the Browser Use plugin.
  4. Start/restart Codex Desktop.
  5. 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 = "..."
  1. 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 ↗

8 Comments

github-actions[bot] contributor · 27 days ago

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

  • #29413
  • #29482

Powered by Codex Action

atlantho · 27 days 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 · 24 days 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 · 12 days 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 · 9 days 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:

  1. the sandboxCwd URI sent to a Windows-side stdio MCP process is not translated from WSL semantics; and
  2. 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 · 7 days 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 · 4 days 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 · 4 days 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.