›_ Codex Issues
Codex Issues / #25301

Computer Use is unavailable in Windows Desktop when app-server runs in WSL (`reason=wsl-disabled`)

Open 💬 5 comments Opened May 30, 2026 by MisterRound

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.
  1. 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.
  1. 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.
  1. 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.

View original on GitHub ↗

5 Comments

Statusnone420 · 2 months ago

I may have hit the same Windows bundled-plugin state issue in #25220. A full destructive clean reinstall of both Codex app + CLI and removing stale .codex folders fixed it for me. I posted details there to avoid duplicating the thread.

MisterRound · 2 months ago

Update from newer Windows Desktop builds: I can now make Computer Use work in a Windows Desktop + WSL setup, but only when four separate gates are satisfied. This changes the issue from "CUA is simply unavailable in WSL mode" to "CUA works if the Windows native sidecar is isolated from the WSL Desktop home and still receives the product native pipe."

Working local shape:

[features].computer_use = true
browser_use = false
browser_use_external = false

Desktop process/user env:

CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1
CODEX_NODE_REPL_PATH=%USERPROFILE%\.codex\node_repl_wsl.sh

The wrapper launches Windows node_repl.exe --disable-sandbox from an isolated runtime home:

CODEX_HOME=%USERPROFILE%\.codex\chrome-runtime-home

and dynamically discovers/passes the product-managed pipe:

SKY_CUA_NATIVE_PIPE=1
SKY_CUA_NATIVE_PIPE_DIRECTORY=\\.\pipe\codex-computer-use-<uuid>

Validated operations through the supported computer-use-client.mjs path:

  • setupComputerUseRuntime({ globals: globalThis })
  • sky.list_apps()
  • sky.list_windows()
  • sky.get_window(...)
  • sky.get_window_state(...)
  • sky.launch_app(...)
  • sky.press_key(...)
  • fresh-screenshot coordinate sky.click(...)
  • sky.drag(...)
  • sky.close()

Recent local proof:

  • CUA pipe present: \\.\pipe\codex-computer-use-<uuid>
  • current-thread list_apps smoke passed and closed cleanly
  • 12-second hold-open smoke stayed responsive and closed cleanly
  • Calculator action smoke clicked a digit and verified display update
  • Phone Link iPhone QR flow worked after fixing a local Windows Bluetooth service issue; CUA itself was not the blocker
  • Photoshop 2026 clean-document UI-only stress passed using CUA window actions only: Ctrl+N, brush drags, Type tool click, typed text layer, verification screenshot/text, clean close
  • shared %USERPROFILE%\.codex\tmp\arg0 remained WSL/Linux-only
  • no unsafe shared-home/bare Desktop node_repl.exe -> codex.exe app-server --listen stdio:// sidecars were present

Failure modes that still need product fixes:

  1. If Desktop product-generated CUA/browser-use node_repl sidecars use shared CODEX_HOME=%USERPROFILE%\.codex, they can create Windows .bat arg0 helpers in the shared WSL app-server helper root and break shell execution.
  2. If the isolated sidecar does not receive SKY_CUA_NATIVE_PIPE_DIRECTORY, computer-use-client.mjs fails with Computer Use native pipe path is unavailable.
  3. A root metadata probe like nodeRepl.nativePipeCreateConnectionType === undefined is not enough to declare CUA broken; the trusted computer-use-client.mjs bootstrap is the real capability gate.
  4. Generated bundled marketplace/cache drift can remove or hide computer-use-client.mjs; that is a plugin reconciliation failure, not proof that CUA app control failed.

Suggested product behavior:

  • In Desktop Windows + WSL mode, product-generated CUA/browser-use sidecars should use an isolated Windows runtime home by default, not the shared WSL Desktop CODEX_HOME.
  • Preserve/inject SKY_CUA_NATIVE_PIPE_DIRECTORY into that isolated runtime.
  • Keep shared %USERPROFILE%\.codex\tmp\arg0 WSL/Linux-only, or namespace arg0 helpers by runtime family.
  • Validate CUA with an action-path smoke, not only pipe creation or list_apps().
eschulma · 2 months ago

Thank you for the detailed analysis. My God why should anyone have to go through this.

I finally gave up and run Windows Native with the desktop app, with tricks in my repo builds to allow my WSL testing to still be fast.

And of course there is always the CLI...but overall it is shameful how broken the WSL integration is.

william-kerr · 2 months ago
And of course there is always the CLI...but overall it is shameful how broken the WSL integration is.

I agree. I don't want to let Codex run on Windows outside of WSL installing garbage in my pristine Windows 11 installation, so the Chrome and Computer Use plugins are just teasers at this point. If OpenAI doesn't have any employees who like Windows, they can hire me and I'll use Windows 100% of the time to make sure that new release features work on Windows in WSL (or are hidden in the UI until they work).

th3nolo · 1 month ago

Adding a current repro that still hits the same reason=wsl-disabled gate on 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:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

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

Observed behavior

I can open the in-app browser pane and load an authenticated page, but the WSL-backed agent cannot inspect or claim it.

Current browser runtime checks:

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

Key Desktop log line:

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

The app still records the browser sidebar / webview lifecycle, so the visible browser pane exists:

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

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 the WSL-backed agent still gets no browser backends.

Related marketplace/path symptom

The generated bundled marketplace contains only these plugins:

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

The same session also logs the invalid C:\mnt\c\... path synthesis pattern during Chrome reconcile:

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'

Impact

This blocks me from using Codex Desktop’s in-app browser for authenticated page inspection while the agent runs in WSL mode. The browser is visually usable, but not exposed to the agent as a controllable backend.

Expected behavior

If Browser/Computer Use is unsupported in WSL-backed Desktop sessions, the app should say that directly and not expose an ambiguous browser pane for agent-inspection workflows. If it is intended to work, the Windows helper/native-pipe/browser capability needs to be bridged into the WSL-backed runtime so agent.browsers.list() is not empty.