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

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.

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

Windows Desktop + WSL workspace: node_repl rejects /mnt/c sandboxCwd before Chrome/browser bootstrap #29413
Computer Use fails to initialize in Codex App on Windows + WSL #29482

Powered by Codex Action

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.

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

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.

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.

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

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.

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 Windows Desktop WSL workspace: node_repl/Browser/Chrome fail during sandbox ACL setup on \\wsl.localhost UNC path #24101.

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.

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?

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.

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.

Fresh reproduction on 2026-08-30.

Environment:

Codex Desktop for Windows: 26.825.5331.0
Agent and workspace running in WSL
Native WSL workspace: /home/<user>/aisenler
Browser Use with the iab backend

The required mcp__node_repl__js bootstrap still fails before any JavaScript executes:

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

This completely blocks agent-driven inspection of local web applications. The target page is not involved—the request is rejected before Browser Use initializes. The issue therefore remains reproducible on the current 26.825 Desktop build.

Still reproducible in Codex Desktop on Windows with a WSL2-backed task.

Environment:

WSL2, Ubuntu 22.04
Linux kernel 6.6.114.1-microsoft-standard-WSL2
codex-cli 0.130.0-alpha.5
bundled Browser Use plugin 0.1.0-alpha1
workspace located on the native WSL filesystem under /home/<user>/<workspace>

Following the bundled Browser Use instructions, the first mcp__node_repl__js call fails before any 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>/<workspace>

The same pre-execution failure also blocks the bundled Computer Use bootstrap, which confirms that the problem is in the shared Node REPL / Windows–WSL bridge rather than the target page or Browser client code.

Impact: local frontend services are reachable and can be tested through HTTP and ordinary shell tools, but the Codex in-app browser cannot be controlled for visual QA from the WSL-backed task.

Fresh reproduction on 2026-09-01 with a newer Windows Desktop build. The issue remains present, and this setup exposes both the WSL availability/provisioning gate and the Windows Node REPL path rejection.

Environment

Windows Codex Desktop AppX: OpenAI.Codex_26.831.1445.0_x64
Desktop/browser runtime: 26.831.20005
Desktop-bundled WSL Codex CLI: 0.152.0
Agent: WSL2 / Ubuntu
Main workspace: native WSL storage under /home/<user>/<repo>
Also reproduced from a projectless task under /mnt/c/Users/<windows-user>/Documents/Codex/...
runCodexInWindowsSubsystemForLinux = true
Integrated terminal: WSL

Current observations

The official Browser and Chrome bundles are physically present in the installed Windows app package. The browser host also starts and its named pipe is present. However, the active WSL agent's generated configuration contains:

BROWSER_USE_AVAILABLE_BACKENDS=""
BROWSER_USE_TINYSKY_ENABLED="0"

The active WSL bundled-plugin marketplace snapshot omits both browser@openai-bundled and chrome@openai-bundled, even though those bundles are present in the Windows application package. This makes Browser unavailable in fresh WSL tasks.

Independently of that availability gate, directly exercising the installed Windows node_repl.exe still fails before JavaScript execution. From a projectless WSL-backed task on a Windows-mounted path:

codex/sandbox-state-meta: sandboxCwd is not a local file URI:
file:///mnt/c/Users/<windows-user>/Documents/Codex/...

The same runtime previously failed from the native WSL workspace with:

codex/sandbox-state-meta: sandboxCwd is not a local file URI:
file:///home/<user>/<repo>

The installed node_repl.exe hash matches the executable packaged with this Desktop build, so this is not a stale-runtime mismatch. The Desktop-bundled WSL CLI is also already 0.152.0.

Impact

The official in-app Browser cannot be used while keeping the agent and primary repositories in WSL. Switching the whole agent back to Windows-native would reintroduce a Windows-to-WSL command/path boundary and is not a viable product fix for WSL-native repositories.

No plugins were force-installed, no Browser backend was manually enabled, and no application, repository, sandbox, or system configuration was modified during this reproduction.

This current-build evidence suggests both layers still need to be addressed:

expose/provision the bundled Browser integration for WSL-backed tasks; and
translate sandboxCwd into the target Windows runtime's path namespace (or run the browser-control runtime inside WSL).

I'm experiencing the same issue as well.

Feedback ID: no-active-thread-01a07263-2ad9-7170-94c9-9305c822c821

Confirmed this is still reproducible in Codex Desktop for Windows version 26.901.5280.0 with a workspace stored in the native WSL filesystem.

This reproduction uses the bundled Browser Use plugin with the in-app browser backend (iab), not the external Chrome backend and not Computer Use. The standard bootstrap fails on the first node_repl/js call, before setupAtlasRuntime can execute or any browser tab can be inspected:

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>/<workspace>

The workspace itself is usable in the same task: terminal commands and file reads/writes work normally. Only the Node REPL/browser-control path is blocked. This suggests the WSL-to-Windows path translation issue still affects the current bundled iab Browser Use flow.

Update (2026-09-10): Restricted-profile testing is now documented in #29639 (comment) . Basic C-drive write restrictions matched the Windows baseline; native WSL UNC operations failed under restricted mode, and the read-restricted policy could not start without the elevated sandbox backend. The local bridge is not validated as a general restricted-mode solution.

2026-09-09 update: package 26.901.6511.0, both path forms, and a working local bridge diagnostic

Confirming the Windows Node REPL / WSL metadata mismatch on a newer package, with a direct runtime comparison. Related: #29413 for /mnt/c/... tasks and #31049 for desktop integration availability.

Environment: Windows x64 desktop app, local agent on WSL2 / Fedora Linux 44. AppX package 26.901.6511.0; earlier end-to-end browser checks used a privately patched 26.901.5003.0 copy. These are package versions, not About-dialog versions.

Runtime-level evidence

Invoking the original bundled Windows node_repl.exe with a WSL codex/sandbox-state-meta.sandboxCwd still rejects the request before JavaScript runs:

sandboxCwd is not a local file URI: file:///mnt/c/Users/<user>/Documents/<workspace>

A diagnostic stdio bridge translates the metadata path to the Windows runtime's namespace, using wslpath -w followed by Windows-aware file-URI encoding:

file:///mnt/c/Users/<user>/Documents/<workspace>
  -> file:///C:/Users/<user>/Documents/<workspace>

file:///home/<user>/<workspace>
  -> file://wsl.localhost/<distro>/home/<user>/<workspace>

With this bridge and the 26.901.6511.0 runtime/environment, JavaScript successfully evaluated 1+1 and used fs.stat(nodeRepl.cwd) on both a C-drive workspace and a native WSL workspace. The unwrapped runtime reproduced the original rejection in the same diagnostic run.

The integration diagnostic used the task's existing unrestricted permission profile. It does not establish end-to-end correctness under every restricted sandbox profile. Separate unit checks verify that translation preserves submitted code, permission/access decisions, network settings, unrelated metadata, and MCP callback responses; path values are the parts translated.

Separate desktop availability gate

As earlier comments noted, correcting sandboxCwd is not sufficient by itself: the stock desktop renderer also marks browser integrations unavailable for local WSL execution. The relevant guard is still present in the 26.901.6511.0 bundle.

A private 26.901.5003.0 diagnostic copy combined the path bridge with an availability exception limited to the local WSL host when the bridge is installed. On 2026-09-07, the existing Edge extension backend and the in-app browser both passed an actual localhost-page check: page reading, Chinese/ASCII input, button click, and screenshot. Temporary tabs/server were then closed. Native-host registration had also recovered, so this is a combined working configuration, not proof that changing only the availability guard fixes all browser failures.

The local correction retained account rollout/configuration permission checks and remote-host exclusions. For 26.901.6511.0, bundled-code tests and the Node REPL integration check pass; complete desktop/browser UI testing on that newer private copy has not yet been repeated.

Please address both runtime metadata translation and supported desktop provisioning/availability for local WSL tasks. All paths here are anonymized. This report does not attribute a separate WSL executable-registration failure to Codex, and the original Store package was left unchanged.

the UNC remap you tried (option 2) can't really win here: \wsl.localhost... is a network path, so the same 'local file URI' check rejects it, which is exactly what you saw. and even if it passed, the sandbox fs restrictions were computed by the linux agent against /home/..., so remapping just the cwd string hands the windows node_repl.exe a root its sandbox metadata was never scoped to. you'd swap a hard failure for one that runs but restricts the wrong tree, which is the worse of the two. running node_repl in the matching wsl env (option 1) is the only one that keeps the sandbox honest instead of papering over the boundary.

@m13v

@m13v Regarding your comment, the distinction between restoring functionality and preserving sandbox enforcement is important. A clarification about the diagnostic in my preceding comment:

With the Windows runtime bundled in package 26.901.6511.0, the converted URI file://wsl.localhost/<distro>/home/<user>/<workspace> was accepted in our integration test. JavaScript executed and fs.stat(nodeRepl.cwd) succeeded for the native WSL workspace. The /mnt/c/... workspace also passed after conversion to file:///C:/.... The rejection reproduced in the unwrapped comparison was for the original Linux-style URI. This is evidence for this runtime/configuration, not a claim that UNC works with every version or sandbox profile.
The bridge does more than rewrite sandboxCwd: it also translates path values in the filesystem permission metadata. Unit tests check preservation of access decisions, network settings, submitted code, and MCP callbacks. However, preserving those fields does not prove that the Windows runtime enforces an equivalent policy over the resulting filesystem paths.

As disclosed in the original comment, the live integration test used the task's existing permissionProfile: { type: "disabled" }. We have not verified restricted-profile enforcement end to end, including allowed/denied reads and writes or path-alias behavior. Your concern about incorrect scoping therefore remains a valid requirement for any production solution; the successful functionality test does not settle it.

Running the runtime in WSL may be an appropriate upstream design. The evidence here establishes a working local compatibility fix under the tested configuration, not that this bridge is ready for all users, nor that a Windows-side implementation can never preserve the required restrictions. Both the metadata boundary and the separate desktop browser-availability gate still need an upstream solution.

worth naming what the disabled profile does to your own test: with enforcement off, the runtime never walks the allow/deny path over the translated URIs, so a passing fs.stat proves reachability, not scoping. that turns the fail-closed -32602 into a green run that structurally can't surface the wrong-tree exposure it was guarding against. the restricted-profile run is the only one that can.

@m13v

@m13v Following your latest comment, I have now run separate restricted-profile tests against the Windows runtime from package 26.901.6511.0 (2026-09-10). Your distinction between reachability and enforcement is valid; these results narrow what I can claim about the local bridge.

The test harness itself ran outside the tested sandbox, but each tested Node REPL request explicitly used permissionProfile.type = "managed", file_system.type = "restricted", and network = "restricted". No tested request used the disabled profile. Only disposable fixture files were used.

Two policy variants were tested:

Write-limited: root readable, only one fixture subdirectory writable; the other fixture directories have no write grant. This intentionally permits reads and does not test denied reads.
Read-restricted: read access scoped to the fixture tree, one writable subdirectory, and one subdirectory with explicit access = "none".

For each applicable case I compared direct Windows-runtime invocation using Windows paths with invocation through the actual WSL bridge using Linux metadata paths.

Case	Direct Windows runtime	Through WSL bridge
C-drive fixture: allowed read/write	Succeeds	Succeeds
C-drive fixture: read-only directory read	Succeeds	Succeeds
C-drive fixture: write without a write grant	Rejected with `EPERM`	Rejected with `EPERM`
C-drive read-restricted policy	Fails before JS execution	Fails before JS execution
Native WSL fixture via UNC, write-limited policy	All attempted file operations rejected with `EPERM`	All attempted file operations rejected with `EPERM`

The read-restricted startup failure reports:

Restricted read-only access requires the elevated Windows sandbox backend

I did not enable an elevated backend or count the startup failure as a successful denied-read test. The UNC fixture directory was independently confirmed to exist and be readable by the outer Windows process; the restricted runtime still refused even explicitly granted operations.

So the bridge matches the Windows baseline for the tested C-drive write restrictions, but the native WSL filesystem case is not a working restricted-mode solution in this setup. Successful unrestricted UNC access from my earlier test does not change that conclusion. I found no out-of-scope writes in these cases, but denied-read enforcement remains unverified, and this is not an exhaustive alias/symlink or sandbox-equivalence audit.

Separately, the earlier functional smoke test has since been repeated on the private 26.901.6511.0 desktop copy after restoring its matching bundled Browser plugin cache: Chrome and the in-app browser both passed local-page reading, input, clicking, and screenshots. That functional result is separate from the restricted-profile results above.

That UNC row is the tell: even explicitly granted writes come back EPERM through \wsl.localhost, both direct and through the bridge. So the remap doesn't just scope the wrong tree, the Windows backend can't hang any grant off a UNC root, so it fails closed on everything. You'd swap a clean pre-exec 'not a local file URI' reject for a runtime where allowed ops EPERM too, and now it reads as the user's policy being wrong rather than a path-mapping bug.

Review of the proposed WSL → Windows `sandboxCwd` fix

I reviewed the community proposal linked earlier in this issue, commit 187047147bcf16a2f6a8fe302b8e7263482f9f90, against current upstream 4ad985e2caaf877b96dafd8138dae2def467e01e.

The proposal addresses the boundary mismatch reported in this issue, but needs the following corrections before it can be treated as a supported fix. This is a code-review and reproduction report, following the current contribution policy; it is not a claim that the proposal has landed or that browser support has been restored.

1. Convert or construct a complete target-runtime sandbox context

The proposed metadata construction changes sandboxCwd, then serializes turn_context.permission_profile() unchanged. At that revision, SandboxState.permission_profile uses PermissionProfile<AbsolutePathBuf> by default. Explicit filesystem entries therefore retain Linux-native strings such as /mnt/c/work and /mnt/c/work/private, while the cwd becomes file:///C:/work.

The receiving runtime needs both cwd and the path-bearing permission entries in its own namespace, with the same read/write/deny decisions. A successful unrestricted fs.stat cannot establish that a restricted profile works. Glob rules, project roots, temporary paths, and native-WSL/UNC support also need an explicit contract, rather than a cwd-only rewrite.

Current upstream already captures per-environment cwd and permission profiles, and the public executor validates explicit permission paths for the receiving host. The fix should preserve these checks and construct the context for the actual receiver. This finding concerns inconsistent metadata in the unmerged proposal; I did not demonstrate a sandbox escape in the shipped browser runtime.

2. Use the MCP server's execution environment, not the orchestrator's WSL distro

The proposed sandbox_cwd_for_mcp_server first selects a cwd by environment_id, but then uses the current process's is_wsl() and WSL_DISTRO_NAME to transform it. Non-local stdio MCP servers are launched on their selected executor.

For example, with a remote Windows executable such as /mnt/c/bin/node_repl.exe, a local Ubuntu orchestrator must not rewrite a remote Debian WSL server's /home/user/work as file://wsl.localhost/Ubuntu/home/user/work. At minimum, local WSL mapping must be restricted to a verified local interop process. Other environments need mapping information obtained from their own execution context.

3. Preserve path identity; do not use a lossy legacy path renderer for execution

The proposal calls cwd.inferred_native_path_string(). That passes through LegacyAppPathString, whose documented behavior is lossy UTF-8 rendering.

For file:///home/user/%FF, the mapper produces a different filename containing U+FFFD. An input that cannot be represented for the target runtime should be rejected as unsupported, not silently redirected to another name. Ordinary space/percent/hash/question-mark escaping is handled by the existing URL segment builder and is not the defect here.

4. Resolve the launched program and mount layout before classifying interop

The proposed Windows executable detector only accepts a .exe spelled under /mnt/<drive>/... or with a Windows drive prefix. It misses node_repl.exe resolved through PATH, and /c/bin/node_repl.exe with WSL's documented automount.root=/ setting. WSL supports configurable automount roots and importing Windows PATH entries.

The classification should use the actual execution/launch context and a verified target platform. Path conversion should use that environment's mount mapping, not assume every /mnt/c/... is C: or that every drive is mounted under /mnt.

5. Keep a drive root absolute

The proposed drive-path builder maps both file:///mnt/c and file:///mnt/c/ to file:///C:. A drive root should be emitted as file:///C:/.

As a separate consumer check, Node v24.19.0's fileURLToPath(uri, { windows: true }) returns C: for the first spelling, and path.win32.isAbsolute returns false; the trailing-slash spelling produces an absolute Windows drive root. This checks Windows path syntax on a Linux host, not the proprietary Windows Node REPL receiver.

Validation and remaining integration work

I compiled an isolated Rust workspace with the original PathUri and AbsolutePathBuf utility crates, an unchanged extraction of the proposal's pure conversion helpers, and its four original helper tests. The direct dependency versions match the original lockfile; the isolated workspace has its own lockfile. Host: Linux x86_64; Rust 1.95.0.

Original tests: 4 passed. Mounted-drive conversion, native WSL-to-UNC conversion, non-Windows commands, and non-WSL hosts retain the original tested behavior.
Observation tests: 2 passed. Ordinary URI escaping is preserved, and the drive-root output is exactly file:///C:. Passing an observation test does not mean the observed root output is correct.
Desired-behavior tests: 3 failed against the original implementation (test-process exit 101). They expose the following gaps:

Fixture	Actual result from the original helper	Required correction
Distinct inputs `file:///home/alice/project-%FF` and `file:///home/alice/project-%EF%BF%BD`	Both become `file://wsl.localhost/Ubuntu/home/alice/project-%EF%BF%BD`	Preserve distinct identities, or explicitly reject the unrepresentable input
Configured command `node_repl.exe`, assuming PATH resolves it to a Windows executable	Cwd remains `file:///home/alice/project`	Classify the resolved launch target
Configured command `/c/tools/node_repl.exe`, assuming `automount.root=/`	Cwd remains `file:///home/alice/project`	Use the selected environment's mount/launch information

These fixtures supply the helper's existing is_wsl=true and distro-name parameters. They do not mount drives, configure PATH, or launch Windows executables. Permission-profile consistency and non-local environment handling above are source-review findings, outside this small harness.

For a minimal independent check, call sandbox_cwd_for_stdio_server_runtime_with_wsl_context from the original test module with the table's inputs, Some("/mnt/c/tools/node_repl.exe") for the two filename inputs, true, and Some("Ubuntu"). Assert that the two filename outputs differ. For each executable fixture, use that command and the common cwd file:///home/alice/project; assert the output is file://wsl.localhost/Ubuntu/home/alice/project. All three assertions fail on the proposal revision.

The original five-file patch also fails git apply --check against the upstream revision above; it needs adaptation to the current per-environment metadata design.

This review does not establish Windows/WSL end-to-end browser success, and I did not build all of Codex. The separate desktop wsl-disabled availability gate reported in #44253 still needs a supported solution; a metadata-path change does not itself address that gate.

Suggested regression coverage: restricted read/write/deny preservation on a Windows-drive workspace and a native WSL workspace; correct behavior for non-local executors; lossless path handling or explicit rejection; resolved PATH executables and alternate mount roots; and actual browser discovery plus page read/input/click under the supported desktop configuration.

Navigation Menu

Repository navigation

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

Summary

Environment

Reproduction Steps

Actual Behavior

Expected Behavior

Additional Diagnostics

Current state

Separate Desktop eligibility gate

Runtime health isolation

3 remaining items

Environment

Current-main check

Environment

Current observations

Impact

2026-09-09 update: package 26.901.6511.0, both path forms, and a working local bridge diagnostic

Runtime-level evidence

Separate desktop availability gate

Review of the proposed WSL → Windows `sandboxCwd` fix

1. Convert or construct a complete target-runtime sandbox context

2. Use the MCP server's execution environment, not the orchestrator's WSL distro

3. Preserve path identity; do not use a lossy legacy path renderer for execution

4. Resolve the launched program and mount layout before classifying interop

5. Keep a drive root absolute

Validation and remaining integration work

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Reproduction Steps

Actual Behavior

Expected Behavior

Additional Diagnostics

Activity

github-actions commented on Jun 23, 2026

atlantho commented on Jun 23, 2026

Nicolas0315 commented on Jun 26, 2026

atlantho commented on Jul 8, 2026

tompw89 commented on Jul 11, 2026

Current state

Separate Desktop eligibility gate

Runtime health isolation

satyalyadav commented on Jul 13, 2026

tanjaduro commented on Jul 16, 2026

tanjaduro commented on Jul 16, 2026

oteme commented on Jul 22, 2026

3 remaining items

medking82 commented on Aug 1, 2026

Environment

Current-main check

StreamVi commented on Aug 3, 2026

StreamVi commented on Aug 12, 2026

SenlerBot commented on Aug 30, 2026

SenlerBot commented on Aug 31, 2026

JoshiCx commented on Sep 1, 2026

Environment

Current observations

Impact

rodrigo-itao commented on Sep 5, 2026

StreamVi commented on Sep 5, 2026

Lili679280 commented on Sep 9, 2026

2026-09-09 update: package 26.901.6511.0, both path forms, and a working local bridge diagnostic

Runtime-level evidence

Separate desktop availability gate

m13v commented on Sep 9, 2026

Lili679280 commented on Sep 9, 2026

m13v commented on Sep 9, 2026

Lili679280 commented on Sep 10, 2026

m13v commented on Sep 11, 2026

ojungo69 commented on Oct 4, 2026

Review of the proposed WSL → Windows sandboxCwd fix

1. Convert or construct a complete target-runtime sandbox context

2. Use the MCP server's execution environment, not the orchestrator's WSL distro

3. Preserve path identity; do not use a lossy legacy path renderer for execution

4. Resolve the launched program and mount layout before classifying interop

5. Keep a drive root absolute

Validation and remaining integration work

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Review of the proposed WSL → Windows `sandboxCwd` fix