WSL agent: bad cwd and Chrome/Computer Use unavailable

Component

Codex Desktop for Windows / WSL agent mode / bundled plugins (chrome, computer-use) / path translation

Version / environment

Codex Desktop: 26.623.5546.0
Codex CLI: 0.142.3
Platform: Windows 11 + WSL2 Ubuntu
Setting: runCodexInWindowsSubsystemForLinux = true
CODEX_CLI_PATH: unset

Summary

This is a follow-up to #28086.

The original missing Linux codex binary part appears partially fixed on my machine: WSL agent mode now starts with a Linux codex binary, and it no longer needs a user-provided CODEX_CLI_PATH.

However, after switching Codex Desktop to WSL agent mode, the resulting session still has two separate problems:

The workspace/cwd and sandbox paths are malformed by mixing a Windows install-resource path with a Windows user path.
Bundled Windows integration plugins such as chrome and computer-use become unavailable or fail their Windows path handling.

Evidence: WSL agent is actually active

Inside the Codex session after switching Agent Environment to WSL:

uname=Linux
WSL_DISTRO_NAME=Ubuntu
codex-cli 0.142.3

The relocated WSL binary is a Linux ELF and runs successfully:

/mnt/c/Users/kangm/.codex/bin/wsl/d3a1a875cd8d759f/codex: ELF 64-bit LSB pie executable, x86-64, static-pie linked, stripped
codex-cli 0.142.3

Desktop log also shows WSL spawning rather than launching the Windows codex.exe directly:

[spawn-async] Spawning process inside WSL
[StdioConnection] stdio_transport_spawned executablePath=C:\Users\kangm\.codex\bin\wsl\d3a1a875cd8d759f\codex spawnCommand=wsl.exe

Problem 1: malformed cwd / sandbox path

The environment context and sandbox policy used this malformed path:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0/app/resources/C:\Users\kangm\Documents\Codex\2026-06-28\new-chat-2

That path combines the app install resources directory with a Windows C:\Users\... path. The expected WSL path should be closer to:

/mnt/c/Users/kangm/Documents/Codex/2026-06-28/new-chat-2

Observed effect: shell commands only worked when an explicit valid workdir such as /tmp was provided. Without an explicit workdir, process creation failed because the default cwd did not exist.

Problem 2: Chrome / Browser is disabled in WSL mode

The current WSL-mode desktop log contains:

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

In a previous Windows-native session on the same install, the corresponding log line was:

browser_use_availability_resolved available=true browserPane=true platform=Windows reason=available release=26.623.42026

So the browser/Chrome integration appears to be explicitly disabled by WSL agent mode.

Problem 3: bundled plugin reconcile mistranslates WSL paths into invalid Windows paths

The same WSL-mode log contains this failure while reconciling the bundled Chrome plugin/native host:

bundled_plugins_marketplace_install_failed ... pluginName=chrome ...
ENOENT: no such file or directory, access 'C:\mnt\c\Users\kangm\.codex\plugins\cache\openai-bundled\chrome\26.623.42026'

The actual Windows path should be:

C:\Users\kangm\.codex\plugins\cache\openai-bundled\chrome\26.623.42026

The actual WSL path exists as:

/mnt/c/Users/kangm/.codex/plugins/cache/openai-bundled/chrome/26.623.42026

This looks like /mnt/c/... was converted incorrectly into C:\mnt\c\... instead of C:\....

Problem 4: Computer Use native pipe starts, but the current WSL agent session does not expose the expected tool entrypoint

The desktop log says the Windows native pipe started:

[computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32

But in the WSL agent session, the node_repl js tool needed by the computer-use plugin was not exposed by tool discovery. Searching for node_repl js returned unrelated tools instead of the JavaScript execution tool.

Expected behavior

When WSL agent mode is enabled:

Workspace/cwd/sandbox paths should be translated to valid WSL paths.
Bundled plugin path reconciliation should not turn /mnt/c/... into invalid C:\mnt\c\... Windows paths.
If chrome / Browser Use and computer-use are intentionally unsupported in WSL agent mode, the UI should make that explicit instead of presenting them as available plugins that fail or disappear at runtime.
If they are intended to work, the Windows helper/native-host paths should continue to be managed from the Windows side while the agent runs in WSL.

Chrome control broken in WSL-agent mode: native-messaging host manifest written with un-translated /mnt/c path (and non-existent 'latest' segment) #30265
Chrome plugin writes invalid WSL-style path in Windows native host manifest #28956
Computer Use fails to initialize in Codex App on Windows + WSL #29482
Browser Use Node REPL fails in Windows Desktop app with WSL workspace due to unmapped sandboxCwd #29639
Windows Desktop: Settings “Open config.toml” does nothing on fresh install/state reset #28994

Powered by Codex Action

I reviewed the suggested duplicates.

This is related to, but not a direct duplicate of, the linked issues:

Chrome control broken in WSL-agent mode: native-messaging host manifest written with un-translated /mnt/c path (and non-existent 'latest' segment) #30265 / Chrome plugin writes invalid WSL-style path in Windows native host manifest #28956 cover the Chrome native-host path translation problem.
Computer Use fails to initialize in Codex App on Windows + WSL #29482 covers Computer Use failing in Windows + WSL.
Browser Use Node REPL fails in Windows Desktop app with WSL workspace due to unmapped sandboxCwd #29639 covers Browser/Node REPL sandboxCwd mapping in WSL.
Windows Desktop: Settings “Open config.toml” does nothing on fresh install/state reset #28994 is only loosely related through malformed WSL cwd state.

This issue is intended to track the current combined behavior on 26.623.5546.0: WSL agent now starts successfully, but cwd translation, Chrome, and Computer Use are still broken together in the same WSL-agent setup.

Adding another current repro from a newer Windows Desktop build.

Environment

Platform: Windows 11 + WSL2 Ubuntu
Codex Desktop package observed in logs: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0
Browser/Computer Use release field in logs/env: 26.623.101652
Codex CLI in WSL session: codex-cli 0.142.5
Agent mode: WSL-backed Desktop session

Relevant config shape:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

[mcp_servers.node_repl.env]
BROWSER_USE_AVAILABLE_BACKENDS = "chrome"
BROWSER_USE_CODEX_APP_VERSION = "26.623.101652"

User-visible symptom

I can open the in-app browser pane and load an authenticated web page, but the agent cannot inspect or claim that tab. Browser setup loads the current browser client, but no browser backend is available to the WSL-backed thread.

Runtime checks from the agent side:

agent.browsers.list() => []
agent.browsers.get("iab") => Browser is not available: iab

Using the old cached Browser Use client path also fails, but the cleaner current-client result is the empty backend list above.

Desktop log evidence

The key availability line matches this issue:

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

The browser sidebar itself is active/attached, so this is not simply that the pane is missing:

IAB_LIFECYCLE webview captured browser use session route conversationId=<redacted> disposeAfterSessionActivity=false

Bundled marketplace state also matches the WSL/path/plugin drift described here:

bundled_plugins_runtime_marketplace_written pluginCount=3 pluginNames=["chrome","computer-use","latex"]

There is no active browser-use plugin in the generated openai-bundled marketplace, although stale cache entries from the older browser-use/0.1.0-alpha1 era still exist locally.

The same session also shows the invalid Windows path synthesis pattern:

bundled_plugins_marketplace_install_failed ... pluginName=chrome ...
ENOENT: no such file or directory, access 'C:\\mnt\\c\\<redacted>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\26.623.101652'

Expected Windows path shape would be closer to:

C:\\Users\\<redacted>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\26.623.101652

Additional observation

Computer Use native pipe startup appears to happen on the Windows host:

computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-<redacted> platform=win32

But from the WSL-backed agent thread, Browser Use still resolves no usable browser backends.

Impact

This blocks my workflow where I intentionally open/log into a site in the Codex in-app browser and expect the agent to read the visible page. The page is visible in the app, but the WSL-backed runtime cannot claim or inspect it.

Expected behavior

Either:

Browser/Chrome/Computer Use should work from WSL-backed Desktop sessions through a supported bridge, or
the UI should clearly mark Browser/Computer Use unsupported in WSL agent mode and avoid presenting an apparently usable in-app browser for agent-inspection workflows.

The current state is confusing because the browser pane exists and can show the page, but the runtime capability gate returns reason=wsl-disabled and agent.browsers.list() is empty.

Fresh reproduction on 26.715 (2026-07-21): all three Windows-control surfaces remain blocked in a WSL-backed thread

I can reproduce the combined behavior tracked here on the current 26.715 Windows Desktop build. This is not a missing-plugin or Chrome-extension-only failure: the shared JavaScript bridge rejects WSL sandbox metadata before any Browser, Chrome, or Computer Use client code executes.

Environment

Codex Desktop MSIX package: 26.715.7063.0
Browser/Chrome/Computer Use bundled release: 26.715.52143
Codex CLI in WSL: 0.145.0-alpha.18
Windows: Microsoft Windows NT 10.0.26200.0 x64
WSL: 2.6.3.0
Distribution: Ubuntu 24.04
Kernel: 6.6.87.2-microsoft-standard-WSL2
Agent environment: WSL
Workspace: /mnt/c/Users/<user>/Documents/Codex/<workspace>

The browser, chrome, and computer-use bundles are present in the local bundled-plugin cache at the same release. The generated node_repl MCP server is also enabled and the node_repl/js tool is visible.

Minimal reproduction

Run Codex Desktop on Windows with the agent environment set to WSL.
Open a Windows-hosted workspace through its WSL path, for example /mnt/c/Users/<user>/Documents/Codex/<workspace>.
Invoke any minimal node_repl/js call, or ask Codex to initialize the in-app Browser, Chrome control, or Computer Use.
The call 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:///mnt/c/Users/<user>/Documents/Codex/<workspace>

I reproduced this with both the Browser/Chrome bootstrap and the prescribed Computer Use bootstrap. Both fail at the same metadata-validation step, before their imported client modules run.

Why all three surfaces are affected

The generated MCP configuration shows a Windows-owned runtime behind the WSL-backed thread:

node_repl command: C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe
Node: v24.14.0
platform: win32
BROWSER_USE_AVAILABLE_BACKENDS: chrome
SKY_CUA_NATIVE_PIPE: 1

The current Desktop log independently shows:

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

Observed impact:

In-app Browser: the pane can exist, but the WSL-backed thread is explicitly resolved as reason=wsl-disabled; agent control cannot initialize.
Chrome control: its Browser client depends on node_repl/js, so it cannot reach extension/native-host discovery or any page interaction.
Computer Use: the Windows native pipe starts and the plugin client file is installed, but the WSL-backed thread does not expose the Computer Use skill; even a direct prescribed bootstrap is rejected by the same sandboxCwd validation before it can use the pipe.

This rules out website content, authentication, Chrome profile state, and the extension as the primary failing layer. A no-op JavaScript call fails before any of those layers are reached.

Additional path-translation evidence

The same current Desktop process repeatedly logs a separate bundled Chrome reconciliation failure that converts a WSL home path into an invalid Windows path:

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 its valid Windows representation. This appears to be another manifestation of Windows/WSL path namespaces being mixed in the Desktop/plugin bridge.

Expected behavior

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

/mnt/c/... should become a valid Windows drive URI such as file:///C:/... for the Windows process.
Native WSL paths such as /home/... should use a valid Windows-accessible WSL/UNC representation, or the relevant MCP process should run in the WSL environment.
Bundled-plugin reconciliation should not synthesize paths such as C:\home\... or C:\mnt\c\....
The Browser availability gate, Browser/Chrome backend provisioning, and Computer Use native-pipe injection should be handled consistently after path normalization.

If these integrations are intentionally unsupported for WSL-backed threads, the app should clearly mark Browser, Chrome control, and Computer Use as unavailable in that mode and avoid presenting controls that fail only after invocation.

Related status

Windows Desktop + WSL workspace: node_repl rejects /mnt/c sandboxCwd before Chrome/browser bootstrap #29413 tracks the exact /mnt/c sandboxCwd rejection.
Browser Use Node REPL fails in Windows Desktop app with WSL workspace due to unmapped sandboxCwd #29639 tracks the equivalent native-WSL /home case and the separate wsl-disabled gate.
Computer Use is unavailable in Windows Desktop when app-server runs in WSL (reason=wsl-disabled) #25301 tracks Computer Use being unavailable when the app-server runs in WSL.
mcp: add URI-native sandbox state metadata #31998 (mcp: add URI-native sandbox state metadata) was closed without merge; the current installed build still reproduces the failure.

All local usernames, workspace names, pipe IDs, and runtime IDs above are redacted. I can provide a sanitized Desktop log excerpt if a maintainer needs it.

Still reproducible on Codex Desktop for Windows build 26.803.10989.0 with Ubuntu under WSL2.

The persisted configuration is correct:

integratedTerminalShell = "wsl"

However, after an app update / task resume, the task was provisioned as Windows PowerShell with this malformed workspace root:

C:\home\<linux-user>\Projects

The intended WSL workspace is:

/home/<linux-user>/Projects

The current desktop logs also repeatedly show the same /mnt/c conversion failure described in this issue. For example, a WSL path shaped like:

/mnt/c/Users/<windows-user>/Documents/...

is handed to the Windows workspace watcher as:

C:\mnt\c\Users\<windows-user>\Documents\...

rather than:

C:\Users\<windows-user>\Documents\...

That produces repeated [git-init-watcher] ENOENT warnings every five seconds. Earlier logs from the same installation show normal Spawning process inside WSL behavior, so the setting and Ubuntu installation previously worked.

Impact in the affected task:

default shell is PowerShell despite the WSL setting;
the declared workspace/sandbox root does not exist;
repository operations require explicit wsl.exe -d Ubuntu -- bash -lc ... wrappers or remote connectors;
task-terminal state reads can hang.

This confirms the path/provisioning problem remains present in build 26.803.10989.0, rather than being limited to the 26.623.* builds in the original report.

Current-version confirmation on Windows Store build 26.820.7780.0, WSL execution, with a ChatGPT Project-backed workspace mirror.

After the separate mcp_servers.codex_app startup regression was bypassed, the WSL agent task itself could start, but the Windows-side Git watcher repeatedly mistranslated the project workspace:

WSL cwd: /mnt/c/Users/<user>/.codex/.chatgpt-projects/<project-id>
Windows watcher cwd: C:\\mnt\\c\\users\\<user>\\.codex\\.chatgpt-projects\\<project-id>
ENOENT: no such file or directory

The warning repeated every five seconds. After another reload/path-casing variation, the watcher attempted C:\\users\\<user>\\...\\.git, which is at least a valid Windows root translation, but the ChatGPT Project mirror is intentionally not a Git repository, so the .git watch still failed and degraded to the workspace-root watch.

This confirms the /mnt/c/... -> C:\\mnt\\c\\... conversion defect remains present in 26.820.7780.0 and also affects the new ChatGPT Project mirror layout. The project name, account identifiers, task IDs, and private repository data are omitted.

I found this existing report closely matches a Windows-to-WSL path translation failure observed on a newer desktop build, so I am adding a bounded reproduction rather than opening a duplicate.

Environment: Windows 11; Codex Desktop 26.1007.2314.0; WSL2 Ubuntu; bundled Linux Codex 0.162.0-alpha.17.2. Identifying account, project, and package-directory values are redacted.

Desktop observation: A WSL Agent task using a Windows-hosted ChatGPT project mirror logged a cwd shaped like:

/mnt/c/Program Files/WindowsApps/<desktop-package>/app/resources/C:\Users\<user>\.codex\.chatgpt-projects\<project>

The git-init-watcher recorded ENOENT at the malformed workspace root; the managed desktop command entry point also failed with Failed to create unified exec process: No such file or directory (os error 2). Specifying alternate per-command workdirs did not fix that original desktop failure.

Read-only inspection of the shipped Windows bundle located a mirror-path producer using host-platform node:path.join. I did not capture the entire dynamic handoff call stack, so this points to a Windows-to-Linux namespace conversion boundary, not a conclusively identified downstream function.

Controlled isolation: With the same installed Linux Codex executable and its built-in :read-only sandbox, preserving the Linux argv from the Windows wsl.exe --exec request:

cwd passed to sandbox	result
Existing Linux D: project path (`/mnt/d/...`)	exit 0
Literal Windows mirror path (`C:\Users\<user>\...`)	ENOENT
Logged mixed Windows/Linux cwd	ENOENT
Existing mirror path converted to `/mnt/c/Users/<user>/.codex/.chatgpt-projects/<project>`	exit 0

A separate file-write probe under :read-only was denied and did not create a file. No sandbox bypass, ACL change, or permission relaxation was used.

This isolates an invalid-cwd failure for the CLI reproducer, showing that the installed Linux Codex and its readonly sandbox work with a valid Linux cwd. It does not establish that cwd is the only missing object in the original Desktop unified-exec failure; the original full unified-exec argv and exact missing child launcher were not captured.

Could maintainers confirm whether this matches existing mirror-path conversion work, and whether the desktop handoff should normalize the mirror cwd and workspace/filesystem roots before dispatching to WSL? Happy to provide further redacted targeted diagnostics if useful.

Navigation Menu

Repository navigation

WSL agent: bad cwd and Chrome/Computer Use unavailable #30435

Component

Version / environment

Summary

Evidence: WSL agent is actually active

Problem 1: malformed cwd / sandbox path

Problem 2: Chrome / Browser is disabled in WSL mode

Problem 3: bundled plugin reconcile mistranslates WSL paths into invalid Windows paths

Problem 4: Computer Use native pipe starts, but the current WSL agent session does not expose the expected tool entrypoint

Expected behavior

Related

Environment

User-visible symptom

Desktop log evidence

Additional observation

Impact

Expected behavior

Fresh reproduction on 26.715 (2026-07-21): all three Windows-control surfaces remain blocked in a WSL-backed thread

Environment

Minimal reproduction

Why all three surfaces are affected

Additional path-translation evidence

Expected behavior

Related status

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

WSL agent: bad cwd and Chrome/Computer Use unavailable #30435

Description

Component

Version / environment

Summary

Evidence: WSL agent is actually active

Problem 1: malformed cwd / sandbox path

Problem 2: Chrome / Browser is disabled in WSL mode

Problem 3: bundled plugin reconcile mistranslates WSL paths into invalid Windows paths

Problem 4: Computer Use native pipe starts, but the current WSL agent session does not expose the expected tool entrypoint

Expected behavior

Related

Activity

github-actions commented on Jun 28, 2026

kangmingxuan commented on Jun 28, 2026

th3nolo commented on Jul 3, 2026

Environment

User-visible symptom

Desktop log evidence

Additional observation

Impact

Expected behavior

CissiBot commented on Jul 21, 2026

Fresh reproduction on 26.715 (2026-07-21): all three Windows-control surfaces remain blocked in a WSL-backed thread

Environment

Minimal reproduction

Why all three surfaces are affected

Additional path-translation evidence

Expected behavior

Related status

s243a commented on Aug 14, 2026

romcharod-ui commented on Aug 26, 2026

timewet commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions