Repository navigation
Windows: sandbox setup fails with SHARING_VIOLATION on running node_repl.exe #51638
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Powered by Codex & OWL Версия 26.1002.51308
What subscription do you have?
plus
What platform is your computer?
Microsoft Windows NT 10.0.22621.0 x64
What issue are you seeing?
Codex Windows 26.1002.6548.0.
Normal local execution consistently fails before PowerShell starts:
helper_unknown_error: setup refresh had errors
Log:
runtime read/execute validation failed
...\runtimes\cua_node\2c9e75c4e9c71beb\bin\node_repl.exe
The process cannot access the file because it is being used by another process. (os error 32)
Process Monitor shows:
codex-windows-sandbox-setup.exe -> CreateFile -> SHARING VIOLATION
Multiple instances of the same node_repl.exe are already running when sandbox setup starts.
Example process relationship:
codex.exe -> node.exe -> node_repl.exe
Rebuilding the entire cua_node runtime did not help: Codex recreated it from scratch and the error returned.
Normal sandbox:
Write-Output "NORMAL_TEST" → fails with setup refresh had errors
Elevated execution:
Write-Output "ELEVATED_TEST" → succeeds
Reinstalling the Store app also did not help.
This looks like a Windows sandbox initialization/order issue where ACL validation is attempted after node_repl.exe is already running.
What steps can reproduce the bug?
Feedback ID: no-active-thread-01a115d3-d463-73b3-8888-11d9d9007050
What is the expected behavior?
No response
Additional information
Feedback ID: no-active-thread-01a115d3-d463-73b3-8888-11d9d9007050
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ehaftpl commentedon Oct 7, 2026
I can reproduce the same issue on Codex & OWL 26.1002.52244
(Store package 26.1002.7124.0).
Same node_repl.exe ACL validation failure with os error 32,
and the same codex.exe → node.exe → node_repl.exe relationship.
Restarting Windows, reinstalling Codex and temporarily pausing
360 Total Security did not help. Terminating node_repl.exe moved
the failure to VCRUNTIME140_1.dll in the @oai/sky runtime.
The runtime processes later appeared again.
Logs are available. Elevated execution has not been tested.
Trevor92711Davis commentedon Oct 7, 2026
I can reproduce this on another Windows installation, including after a full Windows restart.
Environment:
Reproduction on this installation:
await cua.getState();.Tool error:
node_repl kernel exited unexpectedly
windows sandbox failed: helper_unknown_error: setup refresh had errors
Sanitized sandbox log excerpt (2026-10-07 19:29:03 UTC, after reboot):
runtime read/execute validation failed: validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exe:
open ACL target for root-only update:
The process cannot access the file because it is being used by another process. (os error 32)
A process inspection before reboot found four running instances of that executable, with parents named codex.exe or node.exe. This is an observation; I have not identified which process holds the incompatible handle or confirmed the underlying locking mechanism.
Expected: sandbox initialization succeeds and browser tools can list tabs. A browser-runtime executable lock should not prevent unrelated sandboxed shell commands from starting.
Impact: local browser automation and normal sandboxed shell execution are blocked. Full logs and the work session are omitted because they contain unrelated private work context; the excerpt above isolates the recurring failure.
tonylabaudio-pixel commentedon Oct 8, 2026
Urgent triage request: Computer Use is completely blocked on another Windows installation by this same node_repl.exe sharing violation.
Environment
Reproduction and impact
nodeRepl.write('diagnostic: JavaScript kernel started');
The first sandboxed PowerShell read also failed before execution. After the chat permission context changed from workspace-write to danger-full-access, ordinary shell reads succeeded, but node_repl still failed with the same Windows sandbox setup error. This is an observed difference between the execution paths; the internal reason the Node path continued to use sandbox setup has not been established.
Actual errors
After one reset/retry, the tool instead returned:
Sanitized sandbox log excerpt from the minimal diagnostic:
The same path/error was logged during the earlier attempts at 08:14:34, 08:14:48, 08:15:41, and 08:15:54 UTC. The sandbox setup_error.json reports code helper_unknown_error and message setup refresh had errors.
A read-only process inventory found six running node_repl.exe instances from this exact bundled runtime; parents were codex.exe or node.exe. The process holding an incompatible handle has not been identified. This does not by itself prove that a particular running instance is responsible.
Expected behavior and requested action
Computer Use initialization should succeed and the authorized Notepad launch should run. A conflict while validating/updating runtime ACLs should not prevent the JavaScript kernel from starting or block unrelated sandboxed shell commands.
Please prioritize investigation of Windows sandbox runtime ACL refresh and runtime startup coordination, especially handling already-running node_repl.exe files. Please provide a supported recovery procedure and identify the release containing a fix. The user is requesting urgent handling because the Computer Use workflow is completely unusable on this installation.
No ACL/security settings were changed, no helper processes were terminated, and no reinstall was performed during this investigation. Reset/retry did not recover the runtime. We have not verified a fix.
This report contains only sanitized diagnostic excerpts and relevant versions; no credentials, full session transcript, private documents, or unrelated app logs are included.
Otaru25 commentedon Oct 8, 2026
Same failure here, plus a clean before/after that may help pinpoint when it started.
Environment: Windows 11 (10.0.26200.0 x64), Codex App 26.1002.52244.
Failure signature (identical every time):
runtime read/execute validation failed: validate runtime read/execute access on
...\AppData\Local\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exe:
open ACL target for root-only update: <file in use, cannot access> (os error 32)
setup refresh completed with errors: [...]
setup error: setup refresh had errors
After killing the node_repl.exe processes it moves to the next file in the same tree: ...@OAI\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll.
Before/after, from %USERPROFILE%.codex.sandbox:
No config change happened in between — same machine, same user, same settings.
Timing: the app spawns codex-computer-use-swift.exe about 35 s after launch and keeps it alive for the whole app lifetime; it respawns within seconds if killed. So there is no moment where the app is running and the cua_node files are not held open — the setup can never win this race.
Re-materialization test: with the app fully closed I renamed the entire runtimes\cua_node\3dd31cfff853001c directory. On the next launch the app re-created it from scratch, and the fresh files failed identically. So this is not a stale or corrupted file issue.
ACL detail: on the failing file the sandbox group ACE is present but inherited — DETECTIVE\CodexSandboxUsers:(I)(RX). It looks like the setup opens the file unconditionally to write the ACE instead of checking first, which is why the sharing violation is fatal rather than skipped.
Also tried, all ineffective: restarting app and machine; disabling the computer-use plugin in the UI; setting enabled = false for unified-computer-use@openai-bundled and commenting the notify hook in config.toml (the app restores both on startup); manually killing the holding processes; setting computer-use-bundled-plugin-auto-install-disabled = true in .codex-global-state.json (the value sticks but the plugin stays enabled and the hook is re-registered).
Full log attached (232 KB).
sandbox.2026-10-08.log
AaronDimac commentedon Oct 8, 2026
Additional reproduction with a controlled CLI version comparison on Windows. The failure also affects the standalone npm CLI when the ChatGPT desktop app is running.
Environment
cua_node\3dd31cfff853001c.[windows] sandbox = "elevated".Minimal reproduction
With ChatGPT open, run from standalone PowerShell:
Actual:
windows sandbox failed: helper_unknown_error: setup refresh had errors.Expected:
sandbox-ok, with sandbox initialization succeeding while the desktop app is open.Controlled app/daemon tests using 0.162.0
sandbox-ok; doctor shows zero failuresStopping the shared daemon does not stop the desktop app's separate runtime helpers. Closing ChatGPT is currently the user's workaround.
Consecutive version comparison with ChatGPT open
The same sandbox command was run against the same test folder, using npm-cached older releases without replacing the global installation:
errors=[]node_repl.exewith OS error 32Each CLI version was confirmed with
--version. These tests suggest a relevant behavior change between 0.160.1 and 0.161.0; they do not identify the exact source-code defect or establish that downgrading is a complete fix.Sanitized log excerpt from 0.162.0
Running
node_repl.exe/node.exeinstances from that runtime were observed under the desktop app's app-server. Stopping those helpers previously allowed provisioning to succeed, but the failure returned when the helpers restarted. The exact incompatible handle has not been identified.No Defender exclusion or weaker sandbox mode was introduced. Defender's doctor warning is generic; the checked Protection History contained no Codex block. Please use the version comparison and app-open/app-closed test to help investigate runtime ACL validation against already-running files.
anasduale commentedon Oct 9, 2026
Additional 0.162.0 reproduction and bounded MXC workaround tests
Additional evidence from a separate Windows installation, tested 9 October 2026.
Environment: Windows build 10.0.26300, native PowerShell, Codex CLI 0.162.0. The desktop-distributed binary also identifies itself as 0.162.0. A Codex computer-use helper is running.
With
[windows] sandbox = "elevated", sandbox setup fails before the requested command runs. The original observed command was a Git read. A subsequent sandbox invocation also returnedhelper_unknown_error: setup refresh had errors.Relevant log excerpt, with user path and runtime identifier redacted:
Expected: ordinary sandbox commands can start while Codex's own helper is running.
Actual: runtime validation fails and sandbox setup returns an error. We suspect a conflict opening the running executable for ACL handling; the precise internal open flags and causal version change have not been independently established.
The original investigator reports the previous 0.160.0 setup refresh was clean. This reviewer directly verified the 0.162.0 log and failure, but did not rerun the old version or audit update provenance.
Workaround tested locally:
windows.sandbox = "mxc". Basic execution, repository Git reads, allowed writes, denied outside writes, and verified HTTPS succeeded. Fresh app-server command execution passed using both npm and desktop binaries. No helper was killed and no ACL or sandbox account was manually changed.Separate MXC observation: with a workspace outside a repository, reading the repository's
.git/HEADsucceeds butgit -C <repo> log -1returnscannot change to ... Permission denied. Setting the process working directory through .NET fails similarly. Starting the sandbox in that repository or declaring it as a workspace root succeeds. The intended semantics of directory traversal here need clarification.Limits: MXC is labelled under development. These were bounded command-level tests, not complete browser/MCP workflow qualification or a security audit. Existing running conversations retained their original permissions. Please confirm the supported recovery path and investigate the runtime ACL sharing violation.
tonylabaudio-pixel commentedon Oct 9, 2026
Urgent follow-up: fresh chats started with @computer still cannot control native Windows apps.
Environment:
Reproduction:
Evidence of incorrect routing rather than a missing app:
Expected: an @computer desktop-app task on Windows must receive the native Computer Use runtime and enumerate AutoCAD.
Actual: it is routed to a browser-only cua_repl surface and always returns apps: [].
Otaru25 commentedon Oct 12, 2026
Fixed for me on the current build. Tested 2026-10-12, no configuration changes required.
Environment: Windows 11 (10.0.26200.0 x64), Codex desktop app 26.1007.2314.0 (previously reproduced on 26.1002.52244), [windows] sandbox = "elevated" (the default), computer-use helpers running as usual.
Results:
The sandbox helper version reported in the log also moved from codex-command-runner-0.158.0-alpha.2.1 to 0.162.0-alpha.17.2, which matches the fix referenced earlier in this thread.
For reference, on 26.1002.52244 I recorded 0 setup failures on 2026-09-28 (before the regression) and 242 failures / 0 successes on 2026-10-08 after the update. My interim workaround was switching [windows] sandbox to "mxc"; it is no longer needed and I am back on "elevated".
Thanks to everyone in this thread who narrowed this down.
rringr commentedon Oct 12, 2026
Additional reproducible case from Windows 10 Pro 22H2 (OS build 19045.6456), Codex CLI 0.162.1 (npm), Codex Desktop 26.1007.2314.0.
Observed failure:
codex exec --sandbox workspace-write --cd <initialized-temporary-git-repo> --ephemeral -starts the model, but bothapply_patch(creating one harmless text file) andexec_commandfail. The latter reports:The sandbox log repeatedly reports:
ProcMon captured codex-windows-sandbox-setup.exe → CreateFile → SHARING VIOLATION for
node_repl.exe. In the trace, anode_repl.exeprocess was started before the failing sandbox setup attempted to open the same executable; this suggests a setup/runtime concurrency or ordering race, rather than a repository ACL issue.Useful differential test:
codex sandbox -- powershell.exe -NoProfile -Command "Write-Output CODEX_SANDBOX_OK"succeeds, while the subsequentcodex exec --sandbox workspace-writefails repeatedly with the above error.Get-Process node_repl, Sysinternals Handle and Process Explorer did not find a persistent holder when inspected afterwards. Closing a CLI session alone does not reliably resolve the error; sandbox provision succeeds under some conditions (errors=[]in logs).codex doctorrecognizes the installation and authentication as healthy, but reportssandbox provisioning failed / helper_unknown_error.Expected: concurrent Codex Desktop/CLI sessions and an additional noninteractive CLI session can execute normal
workspace-writetools in separate Git worktrees without failing Windows sandbox provisioning.Request: Please investigate whether runtime read/execute ACL validation can be made safe when the bundled runtime executable is already running (or skip updates when permissions are already correct), and identify a supported fixed version or safe workaround without switching to
danger-full-access, disabling security controls, or requiring all other Codex sessions to close.