The Codex application cannot use the built-in browser if the project files are in WSL(Windows Subsystem for Linux)

Open 💬 2 comments Opened May 29, 2026 by Koha2014

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

26.519.81530

What subscription do you have?

GPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

The Codex Desktop in-app browser is visible and can display a local page, but the agent cannot connect to/control it through the Browser plugin when the workspace is opened from WSL via a UNC path.

The failure happens before any real browser navigation or click.

Actual error:
node_repl kernel exited unexpectedly
node_repl diagnostics:

{
  "kernel_status": "running",
  "kernel_stderr_tail": "windows sandbox failed: setup refresh failed with status exit code: 1",
  "reason": "stdout_eof",
  "stream_error": null
}

What steps can reproduce the bug?

On Windows, open a project located inside WSL in Codex Desktop.

Example workspace path:
\\wsl$\Ubuntu\home\user\projects\testsite

Start a local frontend app.

Example:
http://localhost:5005

Open the Codex in-app browser.

The in-app browser visually opens and can show:
http://localhost:5005/login

Try to control the in-app browser through the Browser plugin / node_repl using the browser-client bootstrap:

const { setupBrowserRuntime } = await import(
  'C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.519.81530/scripts/browser-client.mjs'
);

await setupBrowserRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get('iab');

The node_repl kernel exits unexpectedly with:

"windows sandbox failed: setup refresh failed with status exit code: 1"

Notes:

The same localhost app works when tested through an external Google Chrome instance launched with remote debugging / CDP.
Through external Chrome/CDP, the agent can open the app, log in, and run UI smoke tests successfully.
The built-in browser works normally when the workspace is opened from a regular Windows folder instead of a WSL UNC path.

What is the expected behavior?

The Browser plugin should be able to connect to and control the Codex in-app browser when the workspace is opened from a WSL UNC path.

At minimum, Codex should provide a documented workaround or configuration for WSL workspaces.

Additional information

Environment:

OS: Microsoft Windows NT 10.0.19045.0 x64
Windows edition observed separately: Windows 10 Pro
Workspace is located in WSL
Workspace is opened in Codex as a UNC path, for example:

\\wsl$\Ubuntu\home\user\projects\testsite

Local frontend example:

http://localhost:5005

In-app browser example URL:

http://localhost:5005/login

Browser plugin path/version:

C:\Users\<user>\.codex\plugins\cache\openai-bundled\browser\26.519.81530\scripts\browser-client.mjs

Codex runtime binary path observed:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\958d608b5e0546a5\codex.exe

Codex app version was not visible in Windows uninstall registry entries or EXE ProductVersion metadata on this machine.

View original on GitHub ↗

2 Comments

Artem-B · 1 month ago

Another aspect of this problem is when the folder is in the windows filesystem, but the "Agent environment" in the general settings is set to WSL. The path ends up reported as /mnt/c/path/to/project and then the agent complains that "sandboxCwd is not a local file URI"

The control runtime rejected this workspace path:
file:///mnt/c/Users/art/Documents/Playground
Specifically, it reported:
>  sandboxCwd is not a local file URI

The path is valid inside WSL/Linux, but the Windows desktop-control runtime apparently expects a Windows-local URI—likely:
file:///C:/Users/art/Documents/Playground

medking82 · 26 days ago

Fresh current-build reproduction (2026-08-01) shows that the Settings message is caused by an explicit WSL availability gate, not by a missing Browser plugin.

Environment

Codex Desktop MSIX: 26.727.6591.0
Browser bundle/release: 26.727.51351
Desktop-bundled Codex CLI: 0.146.0-alpha.9.2
Windows Desktop with the agent configured to run in WSL2
Workspace on native WSL storage under /home/<user>/...
runCodexInWindowsSubsystemForLinux = true

The Browser settings page displays:

In-app browser plugin unavailable

However, the bundled plugin is present on disk at the current release. The decisive Desktop log entry is:

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

This isolates the user-visible state to Desktop eligibility logic: the Browser pane is enabled and the plugin files exist, but WSL agent mode resolves the capability as unavailable. Reinstalling the Browser plugin or clearing its cache cannot change this decision.

This is related to, but distinct from, the path failure discussed above and in #29639:

The reason=wsl-disabled gate prevents the in-app browser backend from being provisioned to the WSL-backed task.
Separately, when a Windows node_repl.exe is invoked from WSL, codex/sandbox-state-meta.sandboxCwd is still sent as file:///home/... or file:///mnt/c/... and rejected before JavaScript executes.
The external Chrome/native-host reconciliation problem in #30265 is a third downstream blocker.

Fixing only the sandboxCwd conversion therefore will not make the in-app browser available while this Desktop gate remains.