›_ Codex Issues
Codex Issues / #33560

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

Open 💬 0 comments Opened Jul 16, 2026 by tanjaduro

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?

  1. Open the Codex App on Windows.
  1. Configure the agent environment as WSL2 / Ubuntu.
  1. Create a folder on the native Windows filesystem, for example:

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

  1. Access the same folder from WSL as:

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

  1. Start a new Codex task rooted in that folder while the agent remains configured to run in WSL.
  1. Open any page in the Codex in-app browser.
  1. Ask Codex to perform a harmless read-only browser operation, for example:

``text
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.
``

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

``text
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

View original on GitHub ↗