Windows read-only sandbox cannot load node_repl kernel staged under host TEMP

Summary

In a managed read-only Codex Desktop task on Windows, the Node REPL/browser runtime stages kernel.js under the host user's TEMP directory, then launches the Node child as the dedicated CodexSandboxOffline identity. That sandbox identity cannot read the generated directory, so Node exits before model code runs with MODULE_NOT_FOUND.

The identical smoke test succeeds under full access. Installed runtime files exactly match the Microsoft Store package, so this is a sandbox staging/visibility incompatibility rather than file corruption.

Environment

• ChatGPT/Codex Desktop for Windows x64: 26.721.4979.0
• Embedded Codex CLI: 0.146.0-alpha.3.1
• Windows 11 Pro 25H2, build 26200.8875
• Native Windows sandbox: elevated implementation
• Managed task permission: read-only
• cua-node 0.0.5
• Node 24.14.0
• node_repl 20260716.1

Reproduction

1. Start a Windows Codex task with managed read-only filesystem/network permissions.
2. Ensure the node_repl MCP tool is exposed.
3. Call:

``js
nodeRepl.write(nodeRepl.cwd)
``

1. Observe that the kernel exits before executing the code.

Actual behavior

Diagnostics report:

node_repl kernel exited unexpectedly
Error: Cannot find module 'C:\Users\<host-user>\AppData\Local\Temp\.tmp...\kernel.js'
code: 'MODULE_NOT_FOUND'
Node.js v24.14.0

In the same task:

• Process identity is <machine>\CodexSandboxOffline.
• USERPROFILE and TEMP still point to C:\Users\<host-user>.
• The sandbox identity receives Access Denied when entering the generated .tmp... directory.
• The sandbox log records the Node launch in read-acl-only mode without a read grant for that host TEMP directory.

Expected behavior

The generated kernel should be staged in a location readable by the sandboxed child, or the launcher should grant narrowly scoped read access to that one generated directory before starting Node.

Browser/Node tools should work in read-only tasks without granting broad access to the host TEMP directory or disabling the sandbox.

Controls

• The same Node REPL smoke test succeeds immediately under full access.
• Historical successful Node REPL use on this machine occurred under danger-full-access; the managed read-only cases fail consistently.
• Installed node.exe, node_repl.exe, and bundled browser-client.mjs hashes exactly match the packaged Microsoft Store copies.
• Codex Doctor reports installation, auth, network, MCP configuration, and state databases healthy when run outside the sandbox.
• No matching Windows Defender quarantine/detection event was found.
• Restarting/resetting the JS kernel does not help in read-only mode.

Impact

The bundled browser and other Node REPL-backed workflows cannot bootstrap in managed read-only tasks. This also removes browser fallback from read-only scheduled automations.

Suggested fix and regression test

• Create the kernel in a per-execution directory visible to both launcher and sandboxed child.
• Grant only the minimum read/execute access required for that generated directory.
• Verify read-only, workspace-write, and full-access modes independently.
• Assert a minimal nodeRepl.write(...) call and bundled browser-client initialization succeed without broad TEMP ACL changes.

No raw logs or private task contents are attached.