codex - 💡(How to fix) Fix Computer Use is unavailable in Windows Desktop when app-server runs in WSL (`reason=wsl-disabled`)

Summary

Codex Desktop on Windows can successfully use Remote Control while the app-server is configured to run in WSL, but Computer Use / Browser Use is explicitly marked unavailable in the same setup.

The important distinction is that Remote Control worked, but Computer Use did not. Logs show the availability gate returning reason=wsl-disabled, followed by native helper startup failures because the Windows Computer Use helper paths are unavailable.

Environment

Sanitized representative setup:

Product: Codex Desktop Windows Store app
Package family: OpenAI.Codex_26.527.x_x64__2p2nqsd0c76g0
Desktop release string in logs: 26.527.31326
OS: Windows 11 x64
Mode: Desktop configured to run app-server in Windows Subsystem for Linux
Codex home: Windows profile path mounted into WSL as /mnt/c/Users/<user>/.codex

Relevant config shape:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"
keepRemoteControlAwakeWhilePluggedIn = true

[plugins."computer-use@openai-bundled"]
enabled = true

The plugin was later disabled manually to avoid repeated failures, but the root issue reproduced while Computer Use was enabled.

Observed behavior

Remote Control status reads succeeded:

remoteControl/status/read ... errorCode=null

Computer Use / Browser Use was unavailable in the same Desktop session:

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

The native Computer Use helper then failed to start:

[computer-use-native-pipe] computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
[computer-use-native-pipe] computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable" platform=win32

Trying to toggle the Computer Use plugin from Settings also failed once because plugin/marketplace refresh had concurrently modified config:

Failed to update plugin enabled state
Configuration was modified since last read. Fetch latest version and retry.

That config-write conflict is tracked separately, but it made the Computer Use failure harder to recover from through the UI.

Steps to reproduce

1. Install Codex Desktop from the Microsoft Store on Windows.
2. Configure Desktop to run Codex in WSL:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

1. Enable Remote Control and verify the machine can be reached remotely.
2. Enable the bundled Computer Use plugin.
3. Open Settings > Computer use or try to use browser/computer-control functionality.
4. Observe that Remote Control can work, but Computer Use remains unavailable with reason=wsl-disabled and helper-path startup failures.

Expected behavior

If Windows Desktop + WSL is a supported Desktop mode, Computer Use should either:

1. work by bridging from the WSL app-server to the Windows native helper in a supported way, or
2. be clearly marked unsupported before the user enables it, with an actionable message explaining that Computer Use currently requires Windows-native app-server mode.

The current behavior is ambiguous: Remote Control works, the Computer Use plugin is visible/toggleable, but the availability gate disables browser/computer-use due to WSL and the helper startup reports missing paths.

Actual behavior

• Remote Control works in the WSL-backed Desktop profile.
• Computer Use is not usable in that same profile.
• Logs show reason=wsl-disabled and Windows Computer Use helper paths are unavailable.
• The UI does not provide a safe one-click path to switch into a Windows-native Computer Use profile without risking shared state/config issues.

Root cause hypothesis

Computer Use currently appears to require Windows-native helper paths and a Windows-native runtime contract, while the active Desktop profile launches the app-server inside WSL.

That creates a split runtime:

• Desktop host process is Windows.
• App-server/runtime is Linux/WSL.
• Codex home/state/config live under a Windows profile path but are accessed as /mnt/c/... from WSL.
• Computer Use helper is Windows-native and not exposed to the WSL-backed runtime as an available capability.

The product has enough plumbing for Remote Control to work in this mode, but Computer Use appears gated off by design or by incomplete bridge implementation.

Suggested fixes

1. Add an explicit capability matrix for Desktop runtime modes:

Windows-native app-server: Remote Control yes/no, Computer Use yes/no, Browser Use yes/no
WSL app-server: Remote Control yes/no, Computer Use yes/no, Browser Use yes/no

1. If Computer Use is unsupported in WSL mode, hide/disable the toggle and show a direct explanation: Computer Use currently requires Windows-native agent mode.

2. If Computer Use is intended to work in WSL mode, pass a stable Windows helper path/capability contract into the WSL-backed app-server instead of failing with missing-helper-path.

3. Provide a safe built-in switch path from WSL-backed Desktop to Windows-native Computer Use mode that does not reuse incompatible SQLite/plugin/cache paths blindly.

4. Add a release-gate smoke test for this exact setup:

Windows Desktop + WSL app-server
Remote Control enabled
Computer Use plugin enabled
browser_use_availability_resolved should be either available=true or UI should say unsupported before enabling

1. Avoid surfacing this as a generic plugin failure; the user-visible reason should distinguish unsupported WSL runtime mode from missing/corrupt helper installation.

Related issues

• #25194: Windows Computer Use helper path failure / Connect computer crash symptoms.
• #25216: Windows Desktop + WSL umbrella/release-gate issue.
• #24268: Windows+WSL bundled plugin cache path can be synthesized as invalid C:\mnt\c\....
• #24065: Settings/plugin config writes can fail with configVersionConflict during plugin/marketplace refresh.

Privacy note

All user names, exact local thread/project names, and raw logs are redacted. The snippets above contain only sanitized method names, feature state, package family/version, and error strings needed to diagnose the product behavior.