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:

Codex in-app Browser control
Chrome control
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?

Install/run Codex Desktop on Windows.
Set the Codex agent environment to WSL (Ubuntu 24.04 in this reproduction).
Open a Windows-hosted workspace through WSL, for example:
```
/mnt/c/Users/<user>/Documents/Codex/<workspace>
```
Confirm that the bundled Browser, Chrome, and Computer Use packages are present.
Confirm that codex mcp list --json reports node_repl as enabled and points to the bundled Windows node_repl.exe.
Invoke a minimal node_repl/js operation, for example:
```
nodeRepl.write("ok")
```

Observe that it fails before printing ok:

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

Ask Codex to initialize each surface:
- the in-app Browser;
- Chrome control;
- Computer Use.
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:

Windows Desktop + WSL workspace: node_repl rejects /mnt/c sandboxCwd before Chrome/browser bootstrap #29413 — exact /mnt/c sandboxCwd rejection before Chrome/Browser bootstrap
Browser Use Node REPL fails in Windows Desktop app with WSL workspace due to unmapped sandboxCwd #29639 — native WSL /home variant and the separate wsl-disabled Browser gate
Computer Use is unavailable in Windows Desktop when app-server runs in WSL (reason=wsl-disabled) #25301 — Computer Use unavailable when the app-server runs in WSL
WSL agent: bad cwd and Chrome/Computer Use unavailable #30435 — combined WSL cwd/Chrome/Computer Use behavior on an older 26.623 build
Browser control rejects file:///mnt/c/... sandboxCwd in WSL agent mode for Windows-hosted folders #33560 — later Browser-control /mnt/c reproduction

I also checked the related implementation work:

mcp: add URI-native sandbox state metadata #31998 (mcp: add URI-native sandbox state metadata) is closed and was not merged.
Scope MCP sandbox metadata to server environment #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:

Are Browser, Chrome control, and Computer Use intended to be supported in Windows Desktop tasks whose agent runs in WSL?
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?
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.

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

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

Powered by Codex Action

I reviewed the suggested duplicate, #33560.

It is closely related and likely shares the same WSL-to-Windows sandboxCwd translation defect, but I do not believe it covers the full scope of this report:

Browser control rejects file:///mnt/c/... sandboxCwd in WSL agent mode for Windows-hosted folders #33560 is limited to Browser control for Windows-hosted /mnt/c workspaces.
This issue reproduces on the current 26.715 build and documents three simultaneously unavailable surfaces: the in-app Browser, Chrome control, and Computer Use.
It also includes the independent reason=wsl-disabled availability gate, a ready Computer Use native pipe that the WSL-backed task cannot use, and the separate C:\home\... bundled-plugin path mistranslation.
This issue asks OpenAI to confirm the intended WSL support boundary and provide a target release or approximate ETA if support is planned.

For those reasons, I would prefer to keep this open as a current-build, cross-surface umbrella issue unless a maintainer identifies a canonical issue that explicitly tracks all three integrations. I am happy to consolidate if maintainers confirm that #33560 is intended to cover the full scope described here.

I can reproduce this on the same Windows machine after switching the Agent Environment from Windows Native to WSL.

A/B result:

Windows Native: the built-in Browser and Computer Use both work.
WSL: both become unusable.
A WSL-native project under /home/... fails before Browser initialization with:
Mcp error: -32602: js: codex/sandbox-state-meta: sandboxCwd is not a local file URI: file:///home/<user>/<repo>
A project physically stored on a Windows drive but opened through WSL (/mnt/d/...) fails identically:
sandboxCwd is not a local file URI: file:///mnt/d/<path>

The failure occurs before any page opens, so it is not website-, login-, or browser-profile-specific. Moving the project to a Windows drive does not help while the agent environment remains WSL; switching the agent environment back to Windows Native restores Browser and Computer Use.

This matches the shared Windows-host/WSL-agent path-namespace bridge described here. If WSL support is not currently available, it would help if the app and documentation surfaced that limitation explicitly instead of exposing controls that fail only when invoked.

Sorry for the additional comment. Just wonder if any updates on this issue? Computer Use on Windows is completely broken when ChatGPT is running under WSL.

Confirmed again on September 13, 2026 with the Computer Use plugin release 26.908.40834. This reproduction uses a Windows-drive directory exposed to the WSL agent as /mnt/c/... and attempts to open Windows Calculator.

Environment observed locally:

Agent: WSL2, Ubuntu 24.04.4 LTS, kernel 6.6.87.2-microsoft-standard-WSL2, x86-64.
codex --version in WSL: codex-cli 0.154.0-alpha.6.2.
Computer Use plugin: 26.908.40834; the configured BROWSER_USE_CODEX_APP_VERSION also reports 26.908.40834 (not independently checked in the About dialog).
Bundled runtime manifest: Windows x64, Node 24.20.0, runtime 0.0.11/20260909002225-0b90dbee8d2e.
The active node_repl MCP configuration launches the bundled Windows node_repl.exe through WSL interop.

The Computer Use initialization fails, and the issue also reproduces with this minimal node_repl/js call, without importing Computer Use or requesting any desktop action:

nodeRepl.write('node_repl basic execution works');

Actual result (local path anonymized):

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 JavaScript does not execute. js_reset succeeds, but retrying initialization returns the same error. Calculator never opens.

As a separate diagnostic, the bundled Windows Node reports process.platform === 'win32'. Its fileURLToPath() rejects file:///mnt/c/Users/<user>/Documents/Codex with ERR_INVALID_FILE_URL_PATH, while the equivalent file:///C:/Users/<user>/Documents/Codex parses successfully. This is supporting evidence for a path-namespace mismatch, not proof that rewriting this URI alone would restore end-to-end Computer Use.

Is there a supported way to keep the agent in WSL while using Windows Computer Use, or a canonical fix being tracked for this metadata boundary?

Reproduced on 2026-09-16: Windows Desktop + WSL2, Computer Use and in-app Browser unavailable

Adding a current reproduction to this existing issue.

Environment

Windows Store package: OpenAI.Codex 26.908.4834.0 (queried with Get-AppxPackage).
Desktop component release / BROWSER_USE_CODEX_APP_VERSION: 26.908.40834.
Bundled Computer Use plugin: 26.908.40834.
Browser Use plugin: 0.1.0-alpha1.
WSL agent CLI: codex-cli 0.154.0-alpha.6.2.
WSL2 kernel: 6.6.114.1-microsoft-standard-WSL2.
Workspace is on the Windows C drive, exposed to the agent as /mnt/c/Users/<windows-user>/Documents/Codex/<workspace>.
The generated node_repl MCP configuration launches the bundled Windows node_repl.exe through WSL interop.

Observed behavior

Computer Use initialization and in-app Browser initialization fail through the bundled node_repl/js entry point. The user can manually open a page in the in-app browser, but the agent cannot read or control that tab.

Browser setup with the installed browser-client and backend: "iab" is rejected before the JavaScript executes. A fresh minimal smoke test on 2026-09-16 reproduces the same failure without importing any browser or Computer Use module:

nodeRepl.write('node_repl basic execution works');

Actual result (path anonymized):

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/<windows-user>/Documents/Codex/<workspace>

Separate Browser availability signal

The latest matching desktop log entry, dated 2026-09-15, reports:

browser_use_availability_resolved available=false browserPane=true platform=Windows reason=wsl-disabled release=26.908.40834

The current generated MCP environment also has:

BROWSER_USE_AVAILABLE_BACKENDS=""

These observations suggest both a WSL-to-Windows metadata mismatch and a separate in-app Browser availability/provisioning barrier. Successful path conversion alone should not be treated as proof of an end-to-end repair.

Reproduction

Run the Windows desktop app with the agent environment set to WSL.
Open a Windows-drive workspace through its /mnt/c/... path.
Manually open a page in the in-app browser.
Ask the agent to inspect that tab or initialize Computer Use.
Run the minimal node_repl/js probe above; it fails before JavaScript execution.

Expected behavior

Keep the agent and development commands in WSL while allowing it to use the Windows in-app browser and Computer Use through a supported bridge. Please confirm the intended WSL support boundary and whether a fix is tracked for both the metadata translation and the Browser availability gate. If this setup is currently unsupported, please make that limitation explicit in the UI.

Related: #29413 and #29639. Paths are anonymized; no full logs, credentials, or session transcript are attached.

Confirming this still reproduces with a native WSL workspace.

Environment:

Codex CLI 0.154.0
Windows desktop with WSL2 agent
Linux kernel 6.18.33.2-microsoft-standard-WSL2
Workspace under /home/<user>

Reproduction:

From the WSL-backed task, invoke the bundled Computer Use skill to inspect an authenticated Edge page.
Initialize the prescribed @oai/sky client through node_repl/js.
Attempt sky.list_apps().

The call fails before any JavaScript executes or Windows applications are enumerated:

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

Reproduced again on 2026-09-20 in Codex Desktop for Windows with the agent environment set to WSL2 / Ubuntu.

Current reproduction

The canonical repository lives inside WSL:

/home/<user>/dev/<repo>

Git, project files, tests, and deployment workflows work correctly when the Codex agent runs in WSL2.

However, attempting to initialize Computer Use fails before it can even enumerate Windows applications/windows. The exact failure class is:

sandboxCwd is not a local file URI:
file:///home/<user>/dev/<repo>

The failure occurs before Facebook, Instagram, Chrome, or any target application/site is accessed, so it is not related to website authentication, browser state, or the project itself.

Observed behavior:

WSL2 agent:
- Git/repository: works
- Linux tests/deploy tooling: works
- Computer Use / browser bridge: fails during initialization

Windows Native agent:
- Computer Use / browser: works
- But moving the canonical Linux-oriented repository to Windows is not an acceptable workaround because the project relies on Linux filesystem semantics and deploys exclusively to Linux servers.

This is particularly confusing from the product model: Codex Desktop itself is running on Windows, while only the agent execution environment is WSL. The expected behavior is that Windows-owned Desktop capabilities (Browser / Computer Use / native pipe) remain usable while the code agent runs in WSL.

Expected behavior

When a WSL-backed agent invokes a Windows-owned Desktop capability, Codex should translate or scope sandboxCwd into the namespace expected by the Windows runtime, rather than forwarding:

file:///home/<user>/...

directly to a native Windows component.

A Windows-accessible WSL/UNC representation could be used, or the sandbox metadata could be scoped independently for the Windows-side Computer Use runtime.

User impact

The current behavior forces a false choice between:

using the correct Linux/WSL development environment for Git, tests, Docker and Linux deployment; or
switching the entire Codex agent to Windows Native just to use Browser / Computer Use.

For Linux-first repositories on Windows, that makes the Desktop integration significantly less useful and can lead users to consider unnecessary repository migrations or duplicate checkouts.

Please treat this as another current reproduction of the shared Windows Desktop ↔ WSL bridge problem. A supported path where the agent remains in WSL while Windows Desktop capabilities remain available would resolve the workflow cleanly.

No repository files, credentials, browser accounts, or external configuration were modified while reproducing this issue.

Navigation Menu

Repository navigation

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

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

Reproduced on 2026-09-16: Windows Desktop + WSL2, Computer Use and in-app Browser unavailable

Current reproduction

Expected behavior

User impact

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

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

github-actions commented on Jul 21, 2026

CissiBot commented on Jul 21, 2026

iamtornado commented on Aug 18, 2026

hktonylee commented on Sep 5, 2026

yizhaozhang11 commented on Sep 13, 2026

StreamVi commented on Sep 16, 2026

Reproduced on 2026-09-16: Windows Desktop + WSL2, Computer Use and in-app Browser unavailable

austin42 commented on Sep 19, 2026

Williamitiro commented on Sep 20, 2026

Current reproduction

Expected behavior

User impact

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions