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:

1. The workspace/cwd and sandbox paths are malformed by mixing a Windows install-resource path with a Windows user path.
2. 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:

1. Workspace/cwd/sandbox paths should be translated to valid WSL paths.
2. Bundled plugin path reconciliation should not turn /mnt/c/... into invalid C:\mnt\c\... Windows paths.
3. 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.
4. 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.

Related

Related to #28086, but this tracks the remaining WSL-mode cwd/path/plugin integration problems after the Linux codex binary startup path appears to have been partially fixed in 26.623.5546.0.