Windows Desktop + WSL agent: Browser, Chrome control, and Computer Use all fail through the shared bridge

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

26.715.52143 (Desktop Browser/Computer Use release); Windows MSIX package 26.715.7063.0

What subscription do you have?

ChatGPT subscription; the exact tier is not exposed in the affected WSL thread diagnostics.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64
WSL 2.6.3.0
Ubuntu 24.04
Linux 6.6.87.2-microsoft-standard-WSL2 x86_64

What issue are you seeing?

On Codex Desktop for Windows, running the agent in WSL makes all three Windows-control surfaces unusable at the same time:

1. Codex in-app Browser control
2. Chrome control
3. Computer Use / desktop app control

This is a shared Desktop/WSL bridge failure, not three independent website or plugin failures.

The bundled browser, chrome, and computer-use packages are installed. The generated node_repl MCP server is enabled and the node_repl/js tool is visible. However, every JavaScript call is rejected 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:///mnt/c/Users/<user>/Documents/Codex/<workspace>

The generated MCP server runs a native Windows executable:

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

Its environment reports:

Node: v24.14.0
platform: win32
BROWSER_USE_AVAILABLE_BACKENDS: chrome
SKY_CUA_NATIVE_PIPE: 1

The WSL-backed Codex thread sends a Linux/WSL URI (file:///mnt/c/...) to this Windows runtime. The Windows runtime rejects it during sandbox metadata validation, before Browser, Chrome, or Computer Use client code can initialize.

Desktop logs from the same current process also show a separate capability gate and a ready Computer Use native pipe:

browser_use_availability_resolved available=false browserPane=true platform=Windows reason=wsl-disabled release=26.715.52143
computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-<redacted> platform=win32
browser_use_runtime_paths_selected ... node_repl.exe ... nodeVersionValue=v24.14.0 platform=win32

The resulting failure differs by surface, but the WSL bridge is the common blocker:

• In-app Browser: the browser pane can be present, but the WSL-backed task is resolved as reason=wsl-disabled, so the agent cannot control it.
• Chrome control: it cannot reach Chrome-extension or native-host discovery because the shared JavaScript bridge fails first.
• Computer Use: the Windows native pipe starts and the plugin client exists, but the Computer Use skill is not exposed to the WSL-backed task. A direct prescribed Computer Use bootstrap is also rejected by the same sandboxCwd validation before it can use the pipe.

A minimal no-op JavaScript call fails in the same way, so this is not caused by a website, login state, Chrome profile, browser permissions, or the content of the workspace.

What steps can reproduce the bug?

1. Install/run Codex Desktop on Windows.
2. Set the Codex agent environment to WSL (Ubuntu 24.04 in this reproduction).
3. Open a Windows-hosted workspace through WSL, for example:

``text
/mnt/c/Users/<user>/Documents/Codex/<workspace>
``

1. Confirm that the bundled Browser, Chrome, and Computer Use packages are present.
2. Confirm that codex mcp list --json reports node_repl as enabled and points to the bundled Windows node_repl.exe.
3. Invoke a minimal node_repl/js operation, for example:

``js
nodeRepl.write("ok")
``

1. Observe that it fails before printing ok:

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

1. Ask Codex to initialize each surface:

• the in-app Browser;
• Chrome control;
• Computer Use.

1. Observe that none of them can initialize from the WSL-backed task.

The failure is reproducible in a fresh task and occurs before token/context-window usage is relevant.

What is the expected behavior?

Windows Codex Desktop should provide a supported bridge for Browser, Chrome control, and Computer Use when the agent runs in WSL.

For a WSL-backed task invoking a Windows-owned MCP/runtime, Codex should normalize sandbox metadata into the server's path namespace before dispatch. For example:

/mnt/c/Users/<user>/Documents/Codex/<workspace>

should be translated to a Windows-local URI such as:

file:///C:/Users/<user>/Documents/Codex/<workspace>

Native WSL paths such as /home/... should similarly use a valid Windows-accessible WSL/UNC representation, or the relevant MCP process should run in the matching WSL environment.

After path normalization, Codex should consistently provision:

• the in-app Browser backend instead of resolving it as wsl-disabled;
• the Chrome backend/extension bridge;
• the Computer Use native pipe and skill entrypoint.

If these integrations are intentionally unsupported for WSL-backed tasks, the UI and official documentation should clearly say so and should not present apparently usable controls that fail only after invocation.

Additional information

The same current Desktop process repeatedly logs a second Windows/WSL path-conversion error during bundled Chrome reconciliation:

bundled_plugins_marketplace_install_failed ... pluginName=chrome ...
ENOENT: no such file or directory, access
'C:\home\<wsl-user>\.codex\plugins\cache\openai-bundled\chrome\26.715.52143'

The source cache exists at /home/<wsl-user>/.codex/...; C:\home\... is not a valid Windows representation of that location. This is additional evidence that the Desktop/plugin bridge mixes Windows and WSL path namespaces.

This new issue is an intentional current-build umbrella report. The older reports split the same integration failure across individual surfaces or path variants:

• #29413 — exact /mnt/c sandboxCwd rejection before Chrome/Browser bootstrap
• #29639 — native WSL /home variant and the separate wsl-disabled Browser gate
• #25301 — Computer Use unavailable when the app-server runs in WSL
• #30435 — combined WSL cwd/Chrome/Computer Use behavior on an older 26.623 build
• #33560 — later Browser-control /mnt/c reproduction

I also checked the related implementation work:

• #31998 (mcp: add URI-native sandbox state metadata) is closed and was not merged.
• #28914 (Scope MCP sandbox metadata to server environment) was merged, but it is not a confirmed WSL path fix and the current 26.715 build still reproduces the error.

Could an OpenAI maintainer please confirm:

1. Are Browser, Chrome control, and Computer Use intended to be supported in Windows Desktop tasks whose agent runs in WSL?
2. If yes, which issue or implementation is the canonical fix for the shared bridge, and is there a target release or approximate ETA for the repair?
3. If no near-term WSL support is planned, can the app and documentation make that limitation explicit?

The current practical workaround is to use a Windows-native Codex agent for Browser/Chrome/Computer Use and reserve the WSL agent for Linux shell/repository work. That is not an in-WSL fix and forces users to choose between the correct development environment and core Desktop-control capabilities.

All local usernames, workspace names, pipe IDs, runtime IDs, and session identifiers above are redacted. Sanitized Desktop log excerpts can be provided if useful.