Windows Codex: WSL-rooted tasks cannot reach trusted node_repl/Computer Use app approval

Codex
,
1

Summary

On Windows, a Codex task rooted in a WSL project cannot currently reach the
trusted node_repl context needed by the installed Computer Use integration.
The failure occurs before JavaScript and before any app discovery or action
because sandboxCwd remains a WSL-form file URI rather than an exact supported
Windows-local representation.

A second test used one fresh visible projectless task in a Windows-backed
directory exposed through /mnt/c. That task also retained a WSL-form
file:///mnt/c/... sandbox URI and its first node_repl call failed before
JavaScript. No Computer Use request, app-approval prompt, Chrome launch,
observation, screenshot, accessibility read, input, navigation, or network
action occurred in either test.

Sanitized environment identities

  • Codex runtime-configured app version: 26.818.61809
  • Codex Store package resource version observed locally: 26.818.8289.0
  • Computer Use plugin: computer-use@26.818.61809
  • Computer Use manifest SHA-256:
    14dcf555000492ec91b2442d62fd8b373b13f8f9d7a6bab500f20c41338ca928
  • Trusted node_repl.exe SHA-256:
    7671e35e2158179dd2586dbd3d4c6ab82653e81185e473f6e815a5751d266ce4
  • @oai/sky:
    0.6.17-202608171537-pr-1300023-7efba775c041
  • @oai/sky package-manifest SHA-256:
    4267e7e942938d683eaa85419327787c2b562feacf87284260a8448bf81b9e02

These identities were authenticated from local installed files in the
originating task. The failed projectless task could not authenticate the
plugin or @oai/sky from inside its own node_repl, because startup failed
before JavaScript.

Reproduction summary

Failure A — WSL Linux-filesystem project:

CWD=/home/<user>/<project>
SANDBOX_CWD=file:///home/<user>/<project>
RESULT=codex/sandbox-state-meta rejected sandboxCwd as not a local file URI
JAVASCRIPT_EXECUTED=NO
COMPUTER_USE_CALLS=0

Failure B — Windows-backed projectless directory exposed through WSL:

CWD=/mnt/c/Users/<user>/<projectless-directory>
SANDBOX_CWD=file:///mnt/c/Users/<user>/<projectless-directory>
WINDOWS_NATIVE=NO
NODE_REPL=UNAVAILABLE
JAVASCRIPT_EXECUTED=NO
COMPUTER_USE_CALLS=0

For a future authorized reproduction, a no-effect node_repl expression that
reports only sanitized cwd/sandbox identity is sufficient. Computer Use and
@oai/sky should not be invoked until the startup and sandbox mapping contract
passes independently.

Expected product ownership

This appears to belong in Codex app/task routing or exact trusted node_repl
sandbox-context projection:

  1. A visible WSL task and exact turn retain their canonical project and
    sandbox policy.
  2. Codex supplies one exact Windows-local representation for every sandbox
    root, with deterministic round-trip identity and no broader access.
  3. The trusted Windows node_repl starts only after mapping and policy
    validation.
  4. The existing Computer Use integration remains the sole owner of app
    selection, authentic app-approval elicitation, scope, interruption, and GUI
    execution.

A browser-only shim, approval proxy, custom helper-protocol client, plugin
wrapper, or standing service would duplicate or weaken existing ownership and
would not repair the task/runtime boundary.

Security invariants

  • Never interpret user prose or task text as an app-approval response.
  • Never copy, cache, synthesize, broaden, replay, or transfer approval state
    between tasks, turns, sessions, or apps.
  • Preserve each sandbox root and access mode independently; reject relative,
    unavailable, ambiguous, symlink-broadened, distribution-ambiguous, or
    ancestor mappings.
  • Bind context projection and any later elicitation to the exact visible task,
    turn, app, and pending request.
  • Missing elicitation, invalid correlation, denial, interruption, timeout, or
    mapping failure must stop without retry or fallback automation.
  • Denial must precede app effect and disclosure: no launch, observation,
    focus, screenshot, accessibility/page content, input, or navigation.
  • Do not introduce a daemon, service, port, broad app grant, configuration
    bypass, or bridge-owned persistence.

Minimum acceptance tests

  1. Map a narrow WSL Linux-filesystem root to one supported canonical
    Windows-accessible representation and prove exact round trip with unchanged
    root modes.
  2. Map /mnt/<drive>/... to the same Windows directory rather than retaining
    file:///mnt/<drive>/....
  3. Fail closed for missing distributions, unavailable shares, multiple
    mappings, case collisions, symlink/junction escapes, broader ancestors,
    dropped read-only roots, or added writable roots.
  4. Reject missing, stale, malformed, or mismatched task/turn correlation.
  5. In a separately authorized denial-only Chrome test, exactly one first
    approval-gated request must surface the authentic Computer Use prompt before
    any Chrome effect or content disclosure; denial must be explicit and
    effect-free with no retry.
  6. In a separately authorized approval test, only the existing runtime may
    continue the same pending request, and Chrome approval must not authorize
    another app, task, stale turn, or broader sandbox.
  7. User interruption must prevent every later Computer Use call in that turn.
  8. Sanitized diagnostics must exclude screenshots, accessibility/page text,
    window titles or handles, account data, credentials, approval response
    payloads, and persistent authorization state.

Maintainer questions

  1. Is the intended ownership visible-task host routing, trusted node_repl
    sandbox projection, or a jointly owned contract between those components?
  2. Is there already a supported canonical mapping for WSL Linux-filesystem
    roots and Windows-backed /mnt/<drive> roots that the app is not applying?
  3. Which component should own exact round-trip and no-broader-root validation?
  4. What sanitized startup telemetry would be most useful for a fixture-only
    reproduction before any installed or live Computer Use test?

Evidence provenance

This report relies only on sanitized local task results, installed-file
identities, and local source inspection. One earlier read-only official
documentation search and page open occurred outside that evidence boundary and
is recorded in the originating case, but no statement or recommendation here
relies on it.

No attachments are proposed. I can provide a further sanitized fixture-only
reproduction plan if a maintainer identifies the correct source boundary, but
no product change, installation, or live approval test has been performed.

2

Welcome to the forum!

You are welcome to discuss Codex issues here. However, the official place to report and track them is the OpenAI Codex GitHub issue tracker.

I asked ChatGPT to look for the closest related issue, and it identified:

If that issue matches your problem, consider adding a :+1: reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.

If it does not describe the same problem, search the existing Codex issues for a closer match. If you cannot find one, open a new issue and include as much relevant detail as possible.