Windows desktop 26.908 + WSL: browser/Computer Use blocked by sandboxCwd URI rejection; recurring paid-service failure

Summary

The Windows desktop app repeatedly fails to initialise browser/Chrome and Computer Use operations from a WSL-backed task. A minimal Node REPL call fails during codex/sandbox-state-meta validation, before the supplied JavaScript or any browser interaction executes.

This was reproduced again on 16 September 2026. The user reports that Windows/WSL path and browser-control failures have disrupted work for two days, despite paying US$200 per month, and explicitly requests escalation and a reliable resolution.

Existing project-creation report from this account: #45658. That remains open and concerns AbsolutePathBuf deserialized without a base path. This report records the separate browser-runtime failure.

Verified environment

• Windows MSIX package: OpenAI.Codex_26.908.9136.0_x64.
• Packaged application version: 26.908.70816.
• Agent execution environment: WSL2.
• Project physically stored on a Windows drive and accessible from WSL as /mnt/f/....
• Windows Node runtime present: 6f12e0ef1c6e5061.
• Ordinary shell execution, file access and connected read-only services continue working in the same task.

Local usernames, project names and task identifiers are omitted.

Steps to reproduce

1. Run the Windows desktop app with the agent in WSL.
2. Open a Windows-drive project through its WSL path, for example /mnt/f/Projects/Example.
3. Ask the agent to use the installed Chrome or Computer Use capability.
4. Invoke the normal Node REPL entry point. The diagnostic call reproduced here was:

nodeRepl.write({ok:true,cwd:nodeRepl.cwd});

5. The call fails before that code executes:

Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI:
file:///mnt/f/Projects/Example

The final path in this error has been anonymised; the method, error code and URI shape are unchanged.

Expected behaviour

A supported WSL task should be able to invoke the native Windows browser/computer runtime. Translate the WSL workspace path to a valid Windows-local path/URI at the host boundary, or use a compatible execution route.

If any capability is intentionally unavailable with a WSL agent, state that clearly before the agent accepts browser work and provide a documented supported recovery.

Actual impact

• Browser-based workflows cannot start.
• Account and alert configuration cannot be completed.
• The agent can edit files and research through connectors, but cannot complete the advertised browser steps.
• Repeated attempts waste working time. Successful filesystem access or registering one project is not evidence that browser control works.

The requested resolution is a verified end-to-end browser action, not another assurance that files or configuration exist.

Investigation boundaries and additional observation

A separate repair agent reproduced the failure with the harmless call above. No desktop restart has been performed during this investigation.

Local configuration also contains older compatibility overrides disabling some Codex controls; those are being investigated separately. Scheduler-management tools are absent from this task, but this report does not claim that the scheduler's absence has the same cause as the browser URI failure. Any resulting configuration correction and retest will be reported separately.

Related reports reviewed

• #33560 — same failure for a Windows-hosted folder accessed through /mnt/c; merely storing the project on a Windows drive does not resolve the WSL-runtime boundary.
• #42924 — Computer Use initialisation fails with the same sandboxCwd error.
• #29413 — Node REPL rejects the WSL cwd before browser bootstrap.
• #41774 — mixed Windows/WSL runtime and cwd failures.
• #45658 — this user's separate, still-open project creation/import path failure.

This is a current reproduction and customer escalation on the installed version above. Please link/consolidate it with the owning browser-runtime issue as appropriate and provide a supported recovery or fix status.

No credentials, raw conversation logs, screenshots, personal project paths or employment documents are attached.

Start with the Node REPL entry point and the codex/sandbox-state-meta validation described in the report, then compare the related cases in #33560, #42924, #29413, and #41774. Done means the harmless diagnostic call succeeds for a WSL path and a verified end-to-end browser or Computer Use action works, or the unsupported configuration is clearly reported with recovery steps.