Windows Desktop + WSL workspace: node_repl rejects /mnt/c sandboxCwd before Chrome/browser bootstrap

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

Version 26.616.51431 Build 2026.6.21 ( Observed related plugin/runtime versions: - openai-bundled Chrome plugin: 26.616.51431 - Chrome extension: 1.1.5_0)

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop on Windows fails to start node_repl for a WSL workspace before any JavaScript code executes.

The workspace is opened from WSL as:

/mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

The same path maps cleanly to Windows:

C:\\Users\\<user>\\Documents\\Codex\\2026-06-22\\chrome-codex

However, calling mcp__node_repl__js fails before the provided JS code runs:

tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

This blocks Chrome/browser plugin bootstrap in WSL workspaces because the Chrome skill depends on node_repl.

The Chrome native host static configuration appears valid after repair:

Chrome is running.
Codex Chrome Extension is installed and enabled in the selected Chrome profile.
Native messaging manifest exists.
HKCU registry default value points to the manifest.
extension-host.exe exists.
extension-host-config.json exists.
browserClientPath, nodePath, nodeReplPath, and codexCliPath all point to existing files.

Despite that, the browser/Chrome bootstrap cannot start because node_repl rejects the WSL-style sandboxCwd before browser code is reached.

This looks like a WSL path-to-Windows-file-URI conversion issue. The Windows-side node_repl appears to receive:

file:///mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

but likely expects a Windows-local URI such as:

file:///C:/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

What steps can reproduce the bug?

Use Codex Desktop on Windows.

Open a WSL workspace whose path is under /mnt/c, for example:

 /mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

Confirm the WSL path maps cleanly to a Windows path:

 wslpath -w /mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

Expected output:

 C:\\Users\\<user>\\Documents\\Codex\\2026-06-22\\chrome-codex

Confirm WSL interop works:
```
 cmd.exe /c ver
```
This succeeds and prints the Windows version.
In Codex, invoke the Chrome/browser skill, or run a minimal node_repl call such as:
```
 nodeRepl.write("hello");
```

The call fails before the JavaScript code executes:

 tool call failed for `node_repl/js`

 Caused by:
     Mcp error: -32602: js: codex/sandbox-state-meta:
     sandboxCwd is not a local file URI:
     file:///mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

Verify that the Chrome native host configuration is not the failing layer:
- Chrome is running.
- Codex Chrome Extension is installed and enabled.
- Native messaging manifest exists.
- HKCU native messaging registry entry points to the manifest.
- extension-host.exe exists.
- extension-host-config.json exists.
- browserClientPath, nodePath, nodeReplPath, and codexCliPath all point to existing files.
Retry the browser/Chrome bootstrap.

Actual result: it still fails at node_repl startup with the same sandboxCwd error, before browser code runs.

Session id / token usage / context usage:

Not available from the UI at the time of filing.

Possibly related issues found before filing:

What is the expected behavior?

When a Codex Desktop thread uses a WSL workspace, node_repl should either receive a Windows-local file URI for /mnt/c/... paths, for example:

file:///C:/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

instead of:

file:///mnt/c/Users/<user>/Documents/Codex/2026-06-22/chrome-codex

or run in the WSL/Linux context and accept Linux-local workspace paths.
The Chrome/browser plugin should be able to bootstrap from WSL workspaces when the native host configuration is valid.

Additional information

WSL uname -mprs:
Linux 6.6.114.1-microsoft-standard-WSL2 x86_64 x86_64

I initially investigated this as a Chrome extension/native host problem.

There were native host setup issues on this machine, but after manually repairing them the static checks pass:

Manifest path:

  C:\\Users\\<user>\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json

Registry key:

  HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension

Registry default value:

  C:\\Users\\<user>\\AppData\\Local\\OpenAI\\extension\\com.openai.codexextension.json

Host path:

  C:\\Users\\<user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\latest\\extension-host\\windows\\x64\\extension-host.exe

extension-host-config.json exists and points to existing files.

After this repair, the failure remains exactly at node_repl startup with the sandboxCwd is not a local file URI error. This suggests the remaining problem is independent of Chrome native messaging and is instead caused by WSL workspace path metadata being passed to a Windows-side runtime without conversion.

Also note: the bundled Chrome plugin package on this installation only contains the Windows host binary:

extension-host/windows/x64/extension-host.exe

No Linux/WSL native host binary was present, so installing Chrome inside WSL does not appear to be a practical workaround for this plugin.

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

Codex App Browser fails on macOS when node_repl receives file URL sandboxCwd #29348

Powered by Codex Action

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

I can still reproduce this on 2026-07-02 after restarting Codex Desktop.

Environment:

Windows with the Codex agent and integrated terminal configured for WSL
Workspace stored on the Windows drive and exposed to WSL as:
/mnt/c/Users/<user>/Documents/Codex/<workspace>
Bundled Chrome and Computer Use plugin version: 26.623.81905

A minimal node_repl/js invocation fails before any JavaScript executes:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///mnt/c/Users/<user>/Documents/Codex/<workspace>

The same failure blocks both:

Computer Use before sky.list_apps() can run
Chrome/browser control before browser-client setup can run

Both plugin client files are installed. This appears to remain a WSL-to-Windows sandboxCwd URI translation issue rather than a Chrome, OpenAI login, or website issue.

I can still reproduce this on 2026-07-03 after several Codex Desktop updates and a full Browser plugin reinstall/re-enable cycle.

Environment:

Windows Codex App with the agent environment set to WSL
Codex CLI in WSL: codex-cli 0.142.3
BROWSER_USE_CODEX_APP_VERSION="26.623.81905"
BROWSER_USE_AVAILABLE_BACKENDS="chrome"
Browser plugin: enabled
node_repl: enabled
WSL workspace:
- Linux path: /home/<user>/projects/<repo>
- Windows UNC form: \\wsl.localhost\Ubuntu\home\<user>\projects\<repo>
WSL CODEX_HOME points to the Windows Codex home: /mnt/c/Users/<user>/.codex

Minimal smoke test:

nodeRepl.write('ok')

Observed result in the WSL filesystem workspace:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///home/<user>/projects/<repo>

I also tested a Windows-filesystem workspace while the Codex App agent environment was still set to WSL:

Windows path: C:\Users\<user>\Documents\BrowserUseTest
WSL path: /mnt/c/Users/<user>/Documents/BrowserUseTest

That fails before JavaScript execution as well:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///mnt/c/Users/<user>/Documents/BrowserUseTest

Control case:

With the Codex App agent environment switched to Windows native, a Windows-filesystem test project succeeds:

C:\tmp\codex-browser-repro

Results in that control case:

nodeRepl.write('ok'): succeeds
Browser Use initialization: succeeds
Opening http://127.0.0.1:8768/index.html: succeeds
DOM snapshot: succeeds
Screenshot: succeeds
Click verification: succeeds

Result matrix:

Agent environment	Workspace	Result
Windows native	`C:\tmp\codex-browser-repro`	Success
WSL	`/home/<user>/projects/<repo>`	Fails before JS execution
WSL	`/mnt/c/Users/<user>/Documents/BrowserUseTest`	Fails before JS execution

This makes the failure look broader than just a WSL-filesystem path issue. As long as the agent environment is WSL, sandboxCwd is generated as a Linux file URI (file:///home/... or file:///mnt/c/...) and the Windows-side node_repl.exe rejects it before Browser Use, Chrome setup, or any JavaScript can initialize.

The current best diagnosis is still a WSL-agent-to-Windows-node_repl sandbox metadata path/URI namespace mismatch.

Adding another data point from Windows + WSL mode, with one extra bit of instrumentation that may help locate the failing layer.

Environment / setup:

Codex Desktop on Windows with agent environment and integrated terminal set to WSL.
WSL CLI: codex-cli 0.142.4.
Workspace is a native WSL path: /home/<user>/projects/economics.
Chrome plugin is installed/enabled, but the failure occurs before any Chrome/browser-client code can run.

Minimal live tool call still fails:

nodeRepl.write("ok")

Observed result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///home/<user>/projects/economics

Additional proxy/bypass evidence:

I configured [mcp_servers.node_repl] to point at a small WSL Python proxy instead of directly at the Windows node_repl.exe. codex mcp get node_repl reports the expected proxy command:

command: /usr/bin/python3
args: /mnt/c/Users/<user>/.codex/bin/node_repl_wsl_proxy.py

That proxy logs incoming tools/call metadata and rewrites WSL sandboxCwd file URIs before forwarding to the Windows runtime. Manual/synthetic proxy tests show it does rewrite the path, for example:

file:///home/<user>/projects/economics
=> file://wsl.localhost/Ubuntu-24.04/home/<user>/projects/economics

However, after a full Codex Desktop restart and a fresh thread, the actual mcp__node_repl.js tool call above still fails with the original file:///home/... value, and the proxy trace receives no new entry from that live call.

At the same time, the process tree shows both:

codex app-server -> node_repl.exe                  # direct Windows runtime child
codex app-server -> node_repl_wsl_proxy.py -> node_repl.exe

So the visible config says node_repl is proxied, and the proxy works in isolation, but the live exposed mcp__node_repl.js tool appears to be bound to a Desktop/app-server-owned direct node_repl.exe route instead of the configured [mcp_servers.node_repl] command.

That seems consistent with this being a Desktop Windows+WSL app-server/runtime bridge issue rather than a Chrome plugin install issue. It may also explain why config-level MCP workarounds do not fully resolve the problem: the Desktop-managed Node REPL bridge can still bypass the configured MCP server entry.

Follow-up: Computer Use is affected by the same bridge failure in this WSL session.

The Computer Use plugin files are installed, including:

/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/26.623.101652/scripts/computer-use-client.mjs

But the prescribed lightweight Computer Use bootstrap/list-apps call fails before Computer Use can initialize:

if (!globalThis.sky) {
  const { setupComputerUseRuntime } = await import("/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/26.623.101652/scripts/computer-use-client.mjs");
  await setupComputerUseRuntime({ globals: globalThis });
}
globalThis.apps = await sky.list_apps();
nodeRepl.write(JSON.stringify(apps, null, 2));

Observed result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///home/<user>/projects/economics

So the issue is not Chrome-specific on this machine. In WSL agent mode, both Chrome and Computer Use are blocked at the shared node_repl/js bridge layer before either plugin's own client code can run.

Another occurrence of this same bug (Feedback ID: 019f68a0-acfa-7be3-af89-9082ba15d05c):

Chrome fails to connect from a WSL2 workspace before reaching the extension. node_repl/js rejects the codex/sandbox-state-meta before any JS runs:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///mnt/c/Users//Documents/Codex//chrome-integration-validation

Expected behavior: the desktop integration should translate the WSL path into a Windows-local URI (e.g. file:///C:/Users//Documents/Codex//chrome-integration-validation) or run the Chrome bridge inside the WSL context, consistent with what's already reported in this issue.

Still reproducible on 2026-07-21 with a newer Codex Windows/Computer Use build. This reproduction is specifically through the bundled Computer Use plugin, not only Chrome/browser use.

Environment

Codex Windows package: 26.715.7063.0
Bundled Computer Use plugin: 26.715.52143
Platform: Microsoft Windows NT 10.0.26200.0 x64
Codex agent environment: WSL
Integrated terminal: WSL
Workspace stored on the Windows drive and exposed to the agent as:
/mnt/c/Users/<user>/Documents/Codex/2026-07-21/<workspace>
Corresponding Windows location:
C:\Users\<user>\Documents\Codex\2026-07-21\<workspace>
runCodexInWindowsSubsystemForLinux = true
The configured Node REPL runtime is the bundled Windows node_repl.exe
Target app: Zen Browser, installed at C:\Program Files\Zen Browser\zen.exe and already running
Computer Use plugin: installed and enabled
Codex task/thread ID: 019f8465-cade-7882-9274-5f709a5d8faa

Minimal reproduction

Following the bundled Computer Use skill's prescribed initialization:

if (!globalThis.sky) {
  const { setupComputerUseRuntime } = await import(
    "/mnt/c/Users/<user>/.codex/plugins/cache/openai-bundled/computer-use/26.715.52143/scripts/computer-use-client.mjs"
  );
  await setupComputerUseRuntime({ globals: globalThis });
}

var guidanceDoc = await sky.documentation("guidance");

The mcp__node_repl__js call fails before any supplied JavaScript executes:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///mnt/c/Users/<user>/Documents/Codex/2026-07-21/<workspace>

Because validation fails before execution, Computer Use cannot initialize, read its runtime documentation, call sky.list_apps(), request app approval, capture a window, or interact with Zen. Zen itself is installed and running, and the Computer Use plugin files are present, so this is not a missing-app, missing-plugin, or browser-permission failure.

This appears to be the same WSL-agent-to-Windows-node_repl.exe URI namespace mismatch already identified here. The Windows-side runtime receives:

file:///mnt/c/Users/<user>/Documents/Codex/2026-07-21/<workspace>

where it likely requires:

file:///C:/Users/<user>/Documents/Codex/2026-07-21/<workspace>

This confirms that the issue remains present in the 26.715 app/plugin release and affects the bundled Computer Use plugin before its own client code can run.

Additional reproduction: still present in 26.721 and affects both Chrome and the in-app browser

Observed on 2026-07-25 with a newer Codex Desktop build than the previously reported 26.715 reproduction.

Environment

Codex Windows package: 26.721.4979.0
Bundled Chrome plugin/runtime: 26.721.41059
Platform: Microsoft Windows NT 10.0.26200.8894 x64
Agent environment: WSL2
Distribution: Ubuntu 24.04
WSL kernel: 6.18.33.1-microsoft-standard-WSL2
Workspace: native WSL path /home/<user>/UNAV/Master
WSL interop is working: cmd.exe /c ver succeeds
wslpath -w /home/<user>/UNAV/Master resolves to \\wsl.localhost\Ubuntu-24.04\home\<user>\UNAV\Master
The configured node_repl command is the bundled Windows node_repl.exe; its Node runtime and trusted paths are also Windows paths.

Minimal reproduction

A minimal Node REPL call fails before the supplied JavaScript executes:

nodeRepl.write("ok");

Result:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta:
    sandboxCwd is not a local file URI:
    file:///home/<user>/UNAV/Master

The same pre-execution validation failure occurs when attempting to initialize:

The bundled Chrome plugin through an explicit @Chrome request.
The in-app browser through an explicit integrated-browser request.
The bundled Computer Use runtime.

In every case, the failure happens at the shared node_repl/js boundary before browser-client.mjs or computer-use-client.mjs can execute. This means the browser backend, current page, Chrome profile, website allowlist, and Chrome native messaging layer are never reached.

As a control check, launching the installed Windows Chrome executable directly from WSL with Windows interop succeeds and opens the requested URL. What remains unavailable is browser automation and inspection through the Codex bridge.

This further supports the diagnosis that the Desktop-managed Windows node_repl.exe is receiving a Linux-local sandboxCwd URI without namespace conversion. For a native WSL path, it likely needs a UNC-style Windows URI such as:

file://wsl.localhost/Ubuntu-24.04/home/<user>/UNAV/Master

Alternatively, the Node REPL runtime needs to execute in WSL and accept file:///home/... as local.

The issue therefore remains reproducible in the 26.721 release and is not limited to /mnt/c/... workspaces or to the Chrome extension specifically.

Still reproducible on 2026-07-30 in a newer Windows Codex Desktop build, using a native WSL filesystem workspace.

Environment:

Codex Desktop app/runtime: 26.721.81911
Bundled WSL Codex CLI: codex-cli 0.146.0-alpha.3.1
Separately installed WSL CLI: codex-cli 0.146.0
Agent environment: WSL
Workspace shape: /home/<user>/dev/<worktree>
Configured Node REPL remains the bundled Windows node_repl.exe

The built-in Browser call fails before navigation or browser client initialization:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///home/<user>/dev/<worktree>

Launching the installed Windows Chrome executable directly from WSL with headless screenshot flags succeeds against the same local application in about 7.6 seconds. This confirms the local app, host alias, WSL interop, and Chrome itself are healthy; the failure remains at the Desktop-managed WSL-to-Windows Node REPL metadata boundary.

This build therefore still needs either a translated UNC-style URI for native WSL paths or a Node REPL runtime that accepts Linux-local file URIs.

This issue is still reproducible on 2026-08-05 in my WSL environment.

Codex reports the following error:

sandboxCwd is not a local file URI:
file:///mnt/c/Users/jlill/Documents/Codex/

The workspace is located on the Windows filesystem and accessed through /mnt/c from WSL. Codex remains configured to run under WSL.

I can reproduce the same practical limitation with Codex Desktop on Windows while using WSL as the agent environment.

In my case, the Integrations UI reports that the in-app browser plugin is unavailable. Updating the Codex App did not change this. I intentionally removed the Chrome integration because it is not usable from my WSL workflow, and reinstalling the whole App is not an acceptable workaround because I need to preserve existing local conversations.

The relevant runtime configuration exposes no usable browser backend in the WSL agent environment (BROWSER_USE_AVAILABLE_BACKENDS is empty). This makes the report's conclusion especially useful: Chrome/native-host repair is not a workaround for WSL, since the bootstrap path fails before browser code runs and the bundled Chrome host is Windows-only.

A supported WSL browser backend, or correct WSL-path handling by the Windows-side runtime, would be needed. Thanks for the detailed diagnosis.

Additional reproduction and a tested Computer Use workaround, observed on 2026-09-07.

Environment:

Codex Windows app package: 26.901.6511.0
Bundled Computer Use plugin/runtime: 26.901.51231
Agent environment: WSL2
Task directory on the Windows drive, accessed as /mnt/c/Users/<user>/Documents/Codex/<date>/<task>
Configured MCP runtime: the bundled Windows node_repl.exe
Tests were performed in full-access mode.

The normal node_repl/js call attempting to import @oai/sky and call sky.list_apps() fails before JavaScript executes:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///mnt/c/Users/<user>/Documents/Codex/<date>/<task>

We tested a small WSL-side stdio MCP adapter, registered separately as node_repl_wsl, forwarding to the same installed Windows runtime. The adapter translates only the drive-backed cwd URI in the request metadata:

params._meta["codex/sandbox-state-meta"].sandboxCwd

file:///mnt/c/Users/<user>/Documents/Codex/<date>/<task>
  -> file:///C:/Users/<user>/Documents/Codex/<date>/<task>

The adapter passes the permission profile through unchanged and does not add a disable-sandbox flag. It launches the Windows runtime from a valid Windows-accessible directory and uses its configured environment.

After the separate MCP entry was loaded, actual tool calls from the WSL task succeeded at all of the following:

Importing @oai/sky and enumerating running Windows apps with sky.list_apps().
Selecting a returned window and capturing its screenshot with sky.get_window_state().
Clicking a sidebar toggle with sky.click(), observing the change, and clicking again to restore it.

This adds end-to-end Computer Use evidence to the path-translation approach already discussed here. We did not need to switch the agent back to Windows-native mode for these successful calls.

Scope/limitations: this is a local workaround, not a validated general fix. Native WSL /home/... paths, UNC translation, restricted permission profiles, and general browser automation were not tested. The adapter does not translate permission-profile paths, so this does not establish correct sandbox behavior for restricted profiles. An upstream fix should account for the target MCP process's path namespace and preserve permission semantics across that boundary.

Confirmed on a newer current runtime:

Windows Codex Desktop runtime/package: 26.903.9818.0
Agent environment: WSL; workspace cwd: /mnt/c/workspaces/specmaster
Test model: Luna Alto
Test: required @oai/sky initialization through node_repl, followed by a harmless attempt to list/select a safe Windows app

The runtime failed before any JavaScript executed or any app/window could be listed:

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

No screenshot or UI action was reached. The same Windows-backed folder is otherwise accessible from WSL, and this failure is independent of project instructions. This reproduces the exact failure class described here on a newer build and confirms that Computer Use remains unavailable for this WSL workspace before Chrome/browser bootstrap.

Navigation Menu

Repository navigation

Windows Desktop + WSL workspace: node_repl rejects /mnt/c sandboxCwd before Chrome/browser bootstrap #29413

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Minimal reproduction

Additional reproduction: still present in 26.721 and affects both Chrome and the in-app browser

Environment

Minimal reproduction

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Desktop + WSL workspace: node_repl rejects /mnt/c sandboxCwd before Chrome/browser bootstrap #29413

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jun 22, 2026

Nicolas0315 commented on Jun 26, 2026

qwertz92 commented on Jul 1, 2026

bouze commented on Jul 2, 2026

masonpetrosky commented on Jul 4, 2026

masonpetrosky commented on Jul 4, 2026

gilmarvitor commented on Jul 16, 2026

AbdelhamidQ commented on Jul 21, 2026

Environment

Minimal reproduction

Leandroglez39 commented on Jul 25, 2026

Additional reproduction: still present in 26.721 and affects both Chrome and the in-app browser

Environment

Minimal reproduction

khukhunaishvili commented on Jul 30, 2026

jotalillo commented on Aug 5, 2026

libaiyun commented on Aug 6, 2026

guwidoe commented on Sep 7, 2026

omar-ramon commented on Sep 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions