Computer Use fails to initialize in Codex App on Windows + WSL

Resolved 💬 2 comments Opened Jun 22, 2026 by Pilseniro Closed Jul 17, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.616.51431 • Released Jun 20, 2026

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows 10.0.26200.8655 x64; Codex App running with WSL agent environment and WSL terminal.

What issue are you seeing?

Computer Use / Computadora does not initialize correctly in Codex App when the project/thread is running from WSL.

The plugin appears installed and computer-use-client.mjs exists, but the runtime fails before it can list Windows apps/windows.

I reproduced two related initialization errors:

codex/sandbox-state-meta: missing field sandboxPolicy

And in a later fresh session:

codex/sandbox-state-meta: sandboxCwd is not a local file URI:
file:///mnt/c/Users/nirst/Documents/Codex/2026-06-22/...

The failure happens before any Windows app automation runs.

What steps can reproduce the bug?

Open Codex App on Windows.
Open a project stored in WSL, for example /home/pilsenir/projects/sfo-web.
Use WSL as the agent environment and WSL terminal.
Ask Codex to use Computer Use / Computadora.
Try a minimal smoke test, such as listing available Windows apps/windows.
Computer Use fails before listing apps/windows.

I also reproduced this after restarting Codex App and starting a fresh session.

What is the expected behavior?

Computer Use should initialize successfully from Codex App and either list controllable Windows apps/windows or show a recoverable configuration/setup error.

It should not fail before app/window listing because the project is running from WSL.

Additional information

Normal WSL tooling is working in the same environment:

Node/npm work.
GitHub CLI works.
Browser opener works.
Repo typecheck/tests work.

This appears isolated to the Computer Use / Windows automation runtime, not the repo shell environment.

I also reported this through Codex App /feedback from the affected session.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

#29413
#29338
#29303
#29251
#29267

Powered by Codex Action

Nicolas0315 · 2 months ago

I put up a branch for the WSL-to-Windows sandboxCwd path mismatch described here:

https://github.com/openai/codex/compare/main...Nicolas0315:codex/wsl-windows-mcp-sandbox-cwd?expand=1

Commit: 187047147bcf16a2f6a8fe302b8e7263482f9f90

What it changes:

Keeps each MCP server's stdio command in server metadata.
When Codex is running under WSL and the stdio MCP command is a Windows .exe launched through interop, rewrites only the codex/sandbox-state-meta.sandboxCwd value for that MCP call.
Maps /mnt/c/... to a Windows drive file URI such as file:///C:/....
Maps native WSL paths such as /home/... to file://wsl.localhost/<distro>/home/....
Leaves native Linux/WSL MCP commands and non-WSL hosts unchanged.

Verification:

rtx4090 local Windows: just fmt, git diff --check, focused codex-core tests, existing mcp_sandbox_cwd tests, codex-mcp metadata test, and cargo check -p codex-core -p codex-mcp all passed.
cyberagent-mac-m5max: fetched the commit over SSH, git diff --check, focused tests, and cargo check -p codex-core -p codex-mcp passed.
nicolas2025: fetched over SSH, git diff --check, focused tests, and cargo check -p codex-core -p codex-mcp passed; no lingering cargo/rustc/link processes.
nicolas-macbook-pro: fetched over SSH and git diff --check passed; cargo is not installed there.
rtx5060ti: fetched over SSH and git diff --check passed; Rust build is blocked by the machine's known link.exe setup issue (link: extra operand ...), with no lingering cargo/rustc/link processes.
git merge-tree --write-tree origin/main HEAD is clean against current origin/main (69596f0e4).