Fix Codex’s “sandboxCwd is not a local file URI” on WSL

Codex Desktop ran its app server inside WSL. Chrome and Computer Use used Windows plugin runtimes. Every request failed before its JavaScript ran because Codex sent a Linux file URI to a Windows MCP server in the sandbox working-directory field, sandboxCwd.

The first fix was to translate the URI for the process that received it: /mnt/c/... to file:///C:/..., and paths inside the WSL filesystem to file://wsl.localhost/<distro>/.... I applied a public patch to the exact Codex release used by the desktop app.

A fresh process exposed two more WSL-to-Windows boundaries. CODEX_CLI_PATH had to select a Windows-native sandbox helper. Plugin clients also had to load through Windows-valid file URLs.

This note follows the error, the checks that ruled out other causes, the version-pinned build, the fresh-process repairs, and the separate Chrome recovery and browser check.

The setup

Codex sent each request from Linux, and the local MCP server received it on Windows. Both systems could reach the workspace, but the file URI had to use the receiving operating system's path convention.

Failure: request validation rejected sandboxCwd

The smallest test asked the MCP server to evaluate a trivial JavaScript expression and return its working directory. It failed before the expression ran:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI: file:///mnt/c/.../project

The public report with the same failure class was openai/codex#29639. Its workspace was stored under /home/... in the native WSL filesystem, while mine was exposed under /mnt/c/.... In both cases, a Windows .exe received a Linux-local sandboxCwd URI.

What I ruled out

I checked each boundary separately before changing the generated configuration.

The plugins were installed

The local MCP server received the request

The workspace was reachable

Changing the MCP server's cwd did not change sandboxCwd

Removing sandbox context was not the fix

One directory, two local file URIs

Using /mnt/c was not itself the bug. The error came from sending a URI local to Linux to a process validating it under Windows rules.

Codex already knew the active WSL distribution and the MCP server's STDIO command. It did not combine those facts before attaching sandboxCwd.

The patch: map sandboxCwd only for Windows STDIO servers under WSL

I found a focused public fork commit that implemented the missing mapping: Nicolas0315/codex@1870471. I checked out the release used by Codex Desktop, applied the patch there, and kept the change scoped to this runtime boundary.

The patch:

In reduced form:

if is_wsl() && windows_exe_via_wsl_interop(stdio_command) {
    sandbox_cwd = map_wsl_uri_for_windows(sandbox_cwd, distro_name);
}

The server-type check prevents the mapping from changing requests sent to Linux MCP servers.

Version-pinned build and tests

I built from the release tag used by the desktop app with Cargo's lockfile unchanged. The adjacent Codex executables remained on that same release. Before the release build, I ran the test groups touched by the patch:

The mapping tests covered both workspace locations:

• /mnt/c/... becomes file:///C:/....
• /home/... becomes file://wsl.localhost/<distro>/home/....

The guardrail tests also kept the original URI for a Linux STDIO command and for a non-WSL host.

Fresh-process verification exposed two more boundaries

The running desktop process could reach Computer Use. That did not prove that a new CLI process could reconstruct the same chain from its saved configuration. Fresh-process testing separated four runtime roles that had looked like one configuration problem:

Plain codex still selected the stock launcher

The desktop app had an explicit path to the patched Linux executable. A plain codex command in WSL did not use that setting; shell resolution still selected the stock package launcher. I added a higher-priority CLI entry that points to the verified patched build and left the package-managed launchers installed as rollback paths.

This fixed launcher selection without replacing the package installation.

The Windows sandbox helper tried to execute a Linux binary

The Windows node_repl.exe creates its sandboxed Node child through a Codex helper selected by CODEX_CLI_PATH. Pointing that variable to the Linux executable produced Windows error 193: the file was a valid Linux ELF, but not a valid Win32 application.

The platform-specific executable roles therefore had to diverge:

I registered the command name codex-wsl-bridge on both platforms. WSL resolves it to the patched Linux build; Windows resolves it to the bundled PE. The generated configuration can therefore use one command name while each host runs the correct executable.

I kept the sandbox enabled. Disabling it also avoided the failing child process, but would have removed the isolation instead of fixing the executable boundary.

Dynamic imports needed Windows-valid module specifiers

The integration is installed as a plugin, but Windows Node loads the plugin's .mjs client with import(). Once Node started reliably, a module path discovered by the Linux process could still arrive as:

await import("/mnt/c/.../computer-use-client.mjs")

await import("file:///C:/.../computer-use-client.mjs")

The installed plugin instructions convert this path during normal use. I also added a narrowly matched, trusted PreToolUse path-rewrite hook for deterministic enforcement. The hook changes only /mnt/<drive>/... string literals inside dynamic imports sent to the Node REPL. It leaves shell paths, Linux-native tools, and unrelated JavaScript unchanged. Codex records trust against the exact hook definition, so a later edit disables it until the new definition is reviewed.

Checks after the build

The six WSL-to-Windows checks passed. Chrome required a separate recovery sequence and end-to-end browser check.

1. Direct MCP call

2. Plain CLI process from a Windows-mounted workspace

3. Plain CLI process from the native WSL filesystem

4. Deliberately raw plugin import

5. Computer Use application discovery

6. Post-restart acceptance check

7. Chrome connection recovery and end-to-end check

These were separate failures. The URI mapping restored MCP request transport and Computer Use. The Chrome sequence restored the browser connection, and the tab-opening check verified it with a real browser action.

What I would check first next time

I would use this order of diagnosis again:

Status and caveat

As of July 10, 2026, openai/codex#29639 remains open, has no linked pull request, and upstream main does not contain this mapping. The commit is a public fork patch rather than an official release.

I kept a rollback copy, pinned the build to the installed Codex version, and would replace it with an upstream release once the same mapping ships there.

For related Windows and WSL failures, see my Codex issue reproductions and debugging notes.

Credits