Browser control rejects file:///mnt/c/... sandboxCwd in WSL agent mode for Windows-hosted folders

What version of the Codex App are you using (From “About Codex” dialog)?

Powered by Codex & OWL Version 26.707.72221 Released 14 July 2026

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

The Codex App built-in browser-control tool fails before executing any requested JavaScript when the agent environment is WSL2 / Ubuntu.

The existing issue #29639 reports this for WSL projects represented by file:///home/.... I also observed the same failure class for a working directory physically stored on the Windows filesystem but accessed by the WSL agent through /mnt/c/....

The error was:

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

This occurs even for a minimal, read-only JavaScript request. The requested JavaScript is not executed.

Local Codex application logs show that browser control uses a native Windows runtime similar to:

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

The runtime reports:

Node v24.14.0
platform win32

The observable failure path is:

Windows-hosted folder
→ accessed by the WSL agent as /mnt/c/...
→ sandboxCwd represented as file:///mnt/c/...
→ native Windows node_repl.exe
→ URI rejected before JavaScript execution

This suggests that placing a project on the Windows filesystem is not sufficient when the Codex App agent remains configured to run in WSL. The WSL-form workspace path still needs to be translated before it is passed to the native Windows browser-control runtime.

What steps can reproduce the bug?

Open the Codex App on Windows.
Configure the agent environment as WSL2 / Ubuntu.
Create a folder on the native Windows filesystem, for example:
```
C:\Users\<windows-user>\Documents\Codex\browser-test
```

Access the same folder from WSL as:

/mnt/c/Users/<windows-user>/Documents/Codex/browser-test

Start a new Codex task rooted in that folder while the agent remains configured to run in WSL.
Open any page in the Codex in-app browser.

Ask Codex to perform a harmless read-only browser operation, for example:

Use the current in-app browser tab. Execute a harmless read-only JavaScript
expression such as document.title. Do not navigate or modify the page.

Observe that the JavaScript does not execute and node_repl/js fails with:

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

The failure occurs before browser JavaScript executes and does not depend on the page content.

Session ID: <paste the affected Codex session ID if available>

Token/context usage: not relevant to reproduction; the failure occurs during sandbox metadata validation before JavaScript execution.

What is the expected behavior?

When a Codex task runs through a WSL agent but invokes a native Windows MCP or browser-control runtime, Codex should translate the WSL representation of the workspace into a path or file URI that is valid for the Windows process.

For example:

/mnt/c/Users/<windows-user>/Documents/Codex/browser-test

should be normalized to a Windows representation derived from:

C:\Users\<windows-user>\Documents\Codex\browser-test

before it is supplied as sandboxCwd.

Likewise, paths under /home/... should be normalized using their Windows-accessible WSL or UNC representation when passed to a native Windows process.

After normalization, the requested node_repl/js operation should execute normally.

Additional information

Ordinary filesystem, Git, and command-execution operations inside WSL work correctly. The problem is specific to the Codex App built-in browser-control bridge.

A separate instance of the same failure was observed for a WSL filesystem workspace represented as:

file:///home/<user>/code/personal/<project>

Windows can access that project through:

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

However, a browser-control comparison from a UNC-backed Codex task remains inconclusive. The inspected UNC-backed sessions encountered a separate Windows sandbox/CMD UNC-path error before reaching any node_repl/js call.

I inspected the available Windows and WSL Codex configuration and found no supported user-level setting for translating sandboxCwd.

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

Sanitized Codex session-log and Desktop application-log excerpts can be provided if useful.

Related exact /home/... report: #29639
Broader WSL path-handling report: #30565

Reproduced on a newer build with the same exact failure.

Environment

Codex Desktop for Windows: 26.715.9868.0
Codex CLI running in WSL: 0.145.0
Browser bundled plugin observed: 26.707.61608
[desktop] runCodexInWindowsSubsystemForLinux = true
Task cwd: /mnt/c/Users/<user>/Documents/Codex/2026-07-22/new-chat
Target URL: http://localhost:8000/tasks

Result

Invoking @Browser fails before any navigation:

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

The same failure class was also reproduced from a WSL-native cwd under /home/<user>/code/....

This task was running with the permission profile disabled and an unrestricted filesystem, so increasing sandbox permissions / enabling Full Access does not resolve it. The request is rejected during sandboxCwd URI validation before Browser attempts to reach the localhost port.

This confirms the problem remains present in the 26.715 desktop build and affects both /mnt/c/... and /home/... task roots when the agent runs in WSL.

Still reproducible on a newer/current setup after a clean Windows + WSL reinstall.

Environment:

Codex App: 26.721.11231.0
Codex CLI in WSL: 0.146.0-alpha.3.1
Windows 11 Pro 25H2: 10.0.26200.8973 x64
WSL: 2.7.11.0
WSL kernel: 6.18.33.2-2
Ubuntu: 26.04 LTS
Agent environment: WSL2
Workspace is physically on the Windows filesystem and exposed to the WSL agent as /mnt/c/Users/<user>/Documents/Codex/<workspace>

The app-generated node_repl MCP server uses a native Windows executable under:

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

A fresh minimal call:

nodeRepl.write({ ok: true, cwd: nodeRepl.cwd });

still fails before the supplied JavaScript runs:

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

Normal WSL interop, Git/SSH/GitHub CLI, Docker Desktop, systemd, WSLg, DNS, and Windows native developer tooling all work. Reinstalling/configuring the recommended native Windows toolchain (Git, Node LTS, Python, .NET SDK, GitHub CLI, PowerShell 7) does not change this failure. This continues to look isolated to WSL-to-Windows sandboxCwd URI normalization for the native Node REPL/browser-control bridge.

Reproduced on a newer Windows desktop build on 2026-09-10, including in a newly created task with a verified correct project directory.

Environment:

Windows MSIX package: 26.903.8094.0
Embedded app package version: 26.903.61454
app-server version reported by desktop logs: 0.153.4, launched via wsl.exe
Bundled node_repl runtime: 0.0.11/20260902191201-81d486bd9181, windows-x64
Bundled Node version: 24.20.0
Chrome plugin: 26.901.51231
Project is physically on the Windows drive and accessed as /mnt/c/Users/<user>/Documents/<workspace>

The formal mcp__node_repl__js tool is exposed, and desktop logs record its MCP startup as ready. The prescribed Chrome bootstrap request fails before executing any JavaScript:

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

The newly created task's shell cwd exactly matches its saved project path. This reproduces independently of a separate malformed-directory problem in an older task. Ordinary shell commands work in the new task.

An explicit, existing MCP startup cwd allowed the server to initialize, but did not fix request-level sandboxCwd validation. The running node_repl processes use the Windows executable selected by the desktop application. The failure occurs before Chrome selection, extension discovery, or any page operation.

No sandbox checks were disabled, no metadata was rewritten, and no alternative browser automation service was used. No application binaries or global agent environment settings were changed during this reproduction.

Could a maintainer confirm the supported fix or tracking issue for the WSL-agent / Windows-node_repl path boundary? In particular, is there a supported way to use the formal Chrome tool while preserving the existing WSL agent environment, and which released version provides it?

I am also experiencing this in the Codex desktop app on Windows with a task running through WSL and a workspace under /mnt/c/Users/<user>/Documents/Codex/<workspace> (path anonymized).

This happens with every page I try in the built-in browser, not a particular website. The browser opens and displays pages, and I can attach a tab to the task. The assistant receives the tab title and URL but cannot inspect the page contents. Restarting Codex did not resolve it. There is no visible error in the browser; the failure is only reported through the assistant's internal tool result.

In the affected session, the assistant reported no available built-in browser reading tool. Its fallback Computer Use initialization through node_repl/js failed with:

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

The fallback failed before it could inspect any window. Native Windows agent mode has not yet been tested in this reproduction.

A separate shell invocation in the same session also failed with the following error; its relationship to the browser failure is unconfirmed:

bubblewrap is unavailable: no system bwrap was found on PATH and no bundled codex-resources/bwrap binary was found next to the Codex executable

Expected: attaching a built-in browser tab should allow the assistant to read and interact with it. If this is unsupported in WSL mode, the app should clearly display that limitation instead of presenting a usable browser and failing only when the assistant tries to access it.

Please clarify whether Windows-native agent mode is currently required and whether a fix for the WSL workspace URI handling is planned. Exact app version and subscription details were not captured for this report.

Still reproducible on September 29, 2026, following my earlier report in #33560 (comment).

Current verified environment

Codex desktop app: 26.928.20755, build 12246, production channel.
The app's update check reports up_to_date for its configured channel.
Agent execution environment: WSL2.
Linux kernel: 6.18.33.2-microsoft-standard-WSL2.
Current workspace: native WSL filesystem, /home/<user>/workspace/<workspace> (anonymized).
Ordinary Linux shell execution and file access work in the same chat.
The affected chat uses an unrestricted/disabled filesystem permission profile.

This confirms the same failure class now also occurs from a native WSL workspace, in addition to the Windows-hosted /mnt/c/... workspace in my earlier comment.

Minimal reproduction

A fresh call through the exposed node_repl/js tool:

nodeRepl.write({ ok: true, cwd: nodeRepl.cwd });

fails before the 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:///home/<user>/workspace/<workspace>

The normal bundled Chrome/browser-client bootstrap also failed with the same error before browser connection or selection. No browser page could be read or interacted with in this test. Full Access does not avoid the metadata rejection in this configuration.

Related community progress and request

#29639 includes a community path-mapping prototype and reports of successful browser actions with privately modified desktop copies. It also documents a separate WSL browser-availability gate and restricted-sandbox limitations for native WSL UNC paths. These are community diagnostics, not a released fix, and no such patches were applied in this reproduction.

Could a maintainer confirm:

The owning issue for the WSL-agent / Windows-runtime sandboxCwd boundary, covering both /mnt/<drive>/... and native /home/... workspaces.
Whether browser control while preserving WSL as the agent environment is supported, and the released version or supported recovery that enables it.
Whether the separately reported reason=wsl-disabled availability gate is tracked together with the metadata problem. I did not independently inspect that gate in today's reproduction.

Switching the whole agent to Windows native and using WSL only as a terminal changes the required execution environment. The requested outcome is an actual end-to-end browser action from a WSL-backed chat.

No application binaries, configuration, browser settings, or repository files were modified during this test. Paths above are anonymized; no credentials, screenshots, or raw conversation logs are attached.

Additional diagnostic data from September 30, 2026: we recovered shell execution in a WSL-backed Codex Desktop chat, but the node_repl/js URI error in this issue still reproduces. Sharing the distinction and recovery steps in case both failures occur together.

Environment observed: WSL agent, native Linux workspace under /home/<user>/projects/<project>, bundled Linux Codex executable reporting codex-cli 0.159.2. Desktop app version was not captured.

Two separate failures

node_repl/js fails before executing even nodeRepl.write('read-only probe');:

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

Ordinary shell calls initially failed with a generic Failed to create unified exec process: No such file or directory (os error 2). A PTY invocation exposed the specific missing executable:

Unable to spawn /mnt/c/Users/<windows-user>/.codex/tmp/arg0/codex-arg0<session>/codex-linux-sandbox
because it doesn't exist on the filesystem (ENOENT: No such file or directory)

What restored shell execution

From an external WSL terminal / approved diagnostic shell:

Inspect the exact launcher path from the error. In our case, its entire codex-arg0<session> directory was absent.
Identify the executable used by the running Linux Codex process, using its /proc/<pid>/exe link. Ours was under /mnt/c/Users/<windows-user>/.codex/bin/wsl/<runtime-id>/codex. Verify the target is executable and is the matching running runtime.
Recreate only that missing session directory. WSL's attempt unexpectedly returned FileExistsError while the directory remained unlisted. Creating the exact directory from Windows PowerShell succeeded:

# Replace the placeholders with the directory from YOUR error.
$launcherDir = 'C:\Users\<windows-user>\.codex\tmp\arg0\codex-arg0<session>'
[System.IO.Directory]::CreateDirectory($launcherDir)

In WSL, restore the missing helper symlink to the verified Linux Codex executable. Do not overwrite an existing launcher:

set -eu
runtime='/mnt/c/Users/<windows-user>/.codex/bin/wsl/<runtime-id>/codex'
helper='/mnt/c/Users/<windows-user>/.codex/tmp/arg0/codex-arg0<session>/codex-linux-sandbox'

test -x "$runtime"
test ! -e "$helper"
test ! -L "$helper"
ln -s -- "$runtime" "$helper"
"$helper" --help

The installed executable supports the codex-linux-sandbox entry point when launched under that name.

Verified afterward: normal sandboxed shell commands, PTY commands, skill-file reads, and temporary-file write/read/cleanup all passed. No app restart was needed, and no sandbox configuration or application binary contents were changed.

Scope: this is a temporary recovery for the missing shell launcher, not a fix for this issue's Windows/WSL browser-runtime URI validation. A fresh node_repl/js call after the repair still produced the same URI error. We have not established why the launcher directory disappeared or why WSL recreation returned EEXIST.

Still reproduces on Codex desktop 26.930.2377.0 (Microsoft Store), engine codex-cli 0.159.0-alpha.12.1 in WSL2 Ubuntu, Node runtime cua_node/81ea4d5168ddd0a3, with runCodexInWindowsSubsystemForLinux = true.

Two additions to the reports above:

1. It isn't limited to the browser. In the same task, a plain Node call with no browser involved fails the same way:

codex/sandbox-state-meta: sandboxCwd is not a local file URI: file:///mnt/c/Users/<user>/Documents/Codex/2026-10-02/<task>

So every feature that goes through the Windows node_repl.exe is unavailable in WSL mode, not only browser control.

2. Why the address is rejected. node_repl.exe has three separate checks, and these are their error messages:

sandboxCwd must use the file URI scheme
sandboxCwd must be an absolute file URI:
sandboxCwd is not a local file URI:

file:///mnt/c/... passes the first two checks and fails the third. That fits a Windows file-address-to-path conversion (such as Rust's Url::to_file_path), which on Windows needs a drive letter or a network host. A Linux path from WSL has neither, so it can never pass on Windows.

Suggested fix: when the app passes sandboxCwd from the WSL engine to a Windows tool, translate it at that boundary, the same way wslpath -w does:

file:///mnt/<drive>/rest → file:///<DRIVE>:/rest, for example file:///C:/Users/<user>/Documents/Codex/<task>
any other Linux path → file://wsl.localhost/<distribution>/<path>

The first rule covers the most common setup, a WSL task working in a Windows folder. The second covers the file:///home/... case from #29639.

Separately, the exec_command "os error 2" failure that often appears alongside this one is a different defect. Its root cause is in #49731.

Reproduced on 8 October 2026 in a Windows desktop session with the agent running in WSL. This blocks read-only Windows Computer Use as well as browser initialization.

Observed locally:

runCodexInWindowsSubsystemForLinux = true.
The bundled cua_node manifest specifies Windows x64; runtime directory identifier 3dd31cfff853001c.
Bundled @oai/sky version 0.7.6; Computer Use plugin 26.1002.52244.
Ordinary sandboxed Linux command execution works. The Node MCP command points to the existing native Windows node_repl.exe.
Desktop application version was not captured; plugin/runtime identifiers above are not presented as the desktop app version.

Minimal official node_repl/js call, without importing sky or accessing any application:

nodeRepl.write({ready:true});

Fails before JavaScript execution:

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

The workspace resides on C: and is accessed through the WSL mount. Paths are anonymized. No credentials, raw transcripts, screenshots, or business data are attached.

We need a supported way to use the official Windows Computer Use runtime from the WSL-backed agent while preserving the sandbox and other ongoing WSL projects. A global switch to native Windows is not acceptable as an unverified workaround. The documented MCP server cwd setting describes the server process working directory, not an override for the app-generated sandboxCwd request metadata, so we have not patched that setting speculatively.

Could maintainers identify the supported recovery route or the fixed desktop/runtime version? Acceptance requires both a successful minimal official Node call and a read-only sky window enumeration, with the sandbox retained. No sandbox bypass, binary patch, or custom Computer Use transport was attempted.

@khoi-oai

Anybody of openai even saw this issue until yet?
@khoi-oai @bz-oai @cd-oai ( just randomly picked some oai devs to make this visible and finaly get a fix for this. seems like there is a third party fix already, but i dont trust them ;) )

Navigation Menu

Repository navigation

Browser control rejects file:///mnt/c/... sandboxCwd in WSL agent mode for Windows-hosted folders #33560

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Result

Current verified environment

Minimal reproduction

Related community progress and request

Two separate failures

What restored shell execution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Browser control rejects file:///mnt/c/... sandboxCwd in WSL agent mode for Windows-hosted folders #33560

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

Ayoro commented on Jul 22, 2026

Environment

Result

jfacevedo80 commented on Jul 30, 2026

TainWaang commented on Sep 10, 2026

cjbarth commented on Sep 19, 2026

jfacevedo80 commented on Sep 29, 2026

Current verified environment

Minimal reproduction

Related community progress and request

zwingsstudio commented on Sep 30, 2026

Two separate failures

What restored shell execution

LesleyMurfin commented on Oct 2, 2026

canefield commented on Oct 8, 2026

Dwza commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions