Repository navigation
Windows elevated sandbox setup fails when node_repl.exe is running (OS error 32) #52389
Description
Environment
- Windows 11 Home, build 10.0.26300
windows.sandbox = "elevated"- Affected setup helpers:
- npm CLI
0.160.1(@openai/codex-win32-x64,codex-windows-sandbox-setup.exe) - App-server daemon
0.161.0and0.162.0
- npm CLI
- Codex runtime present at
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe, used by thenode_replMCP server
Observed behavior
Sandboxed Codex commands intermittently fail with:
helper_unknown_error: setup refresh had errors
The sandbox log (~/.codex/.sandbox/sandbox.<date>.log) reports:
runtime read/execute validation failed: validate runtime read/execute access on C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\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)
setup refresh completed with errors: [...]
setup error: setup refresh had errors
setup refresh: exited with status ExitStatus(ExitStatus(1))
The same refresh also reports a non-fatal OS error 32 while attempting to update an ACE on the user-profile directory.
Evidence
- Examined 28 failed sandbox refreshes over approximately 24 hours. All 28 reported the same
node_repl.exefile-sharing error. - The failures began when
node_replwas first used on this machine (~/.codex/node_repl/created at the time of the first failure), although thecua_noderuntime had been installed about two weeks earlier. Approximately 1,060 earlier refreshes in the examined logs had no recorded errors. - Failures also occurred with
codex exec --ignore-user-config, suggesting the behavior is not controlled solely by the user's[mcp_servers.node_repl]configuration. - The executable already had an inherited Modify permission for
CodexSandboxUsers. The helper nevertheless failed while opening the target for its ACL operation. - In observed sessions, sandbox refreshes resumed succeeding after the sessions hosting
node_repl.exeexited and that process terminated.
The relationship between process lifetime and failures is supported by observations and timestamps, but was not captured through simultaneous process and file-handle tracing.
Possible cause (unconfirmed)
The sandbox setup helper may be opening runtime executables with access or sharing flags incompatible with a running executable.
This could cause a Windows sharing violation (ERROR_SHARING_VIOLATION, OS error 32) during ACL validation or modification.
The exact file-opening flags and internal helper behavior have not been verified.
Expected behavior
Codex sandbox initialization should succeed while other Codex sessions are using Codex-provided runtime executables.
Potential fixes to investigate include:
- Opening ACL targets with compatible sharing flags.
- Avoiding unnecessary ACL operations when effective permissions are already sufficient.
- Handling executable-in-use sharing violations without aborting setup, provided sandbox security requirements remain satisfied.
Suggested reproduction (inferred; not deliberately reproduced)
- Install or initialize the Codex runtime containing
cua_node. - Configure Windows elevated sandbox mode.
- Start an interactive Codex session that launches the
node_replMCP server, and confirmnode_repl.exeis running. - In another terminal, execute:
codex exec --ignore-user-config -c windows.sandbox="elevated" --sandbox workspace-write "Run git status."- Sandbox initialization may fail with
setup refresh had errors. Inspect~/.codex/.sandbox/sandbox.<date>.logfor the sharing violation onnode_repl.exe.
Workaround
Exit interactive Codex sessions hosting node_repl.exe and wait for that process to terminate before dispatching another sandboxed Codex worker.
This has restored successful sandbox initialization in the observed cases.
Activity
github-actions commentedon Oct 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Hendra827 commentedon Oct 9, 2026
This appears to be the same Windows sandbox regression tracked in #51932 and addressed by PR #51822. In my case, 100% of local tasks fail before execution with
helper_unknown_error: setup refresh had errorsand OS error 32 on an in-use runtime file. Could the team confirm which Desktop release will include the fix, and whether a supported workaround or hotfix is available?PANART-Dev commentedon Oct 9, 2026
Additional confirmed reproduction on Windows 10 Pro, 10.0.19045 (build 19045), observed on 9 October 2026. Adding this environment to the existing report instead of opening a duplicate.
windows.sandbox = "elevated".cua.getTabandcua.getState) exits before returning browser/page state:trusted Node process exited unexpectedlyornode_repl kernel exited unexpectedly.A CUA-session reset and a full desktop application restart did not resolve it. Process timestamps confirmed that the app server and helper processes had actually restarted before the new failures. Six
node_repl.exeprocesses were observed afterwards, but the process holding the conflicting file handle was not identified. No processes were forcibly terminated and no ACL/security configuration was modified.Browser interaction worked earlier on this machine. The failure now occurs before automation connects to the existing browser tab.
The merged fix #51822 appears relevant. Please confirm which Windows desktop release includes it, or whether there is a supported recovery procedure for this runtime configuration. The exact desktop app version was not available from the inspected process file metadata; no version is inferred from the runtime hash. Project data, session transcripts, credentials and full logs have been omitted.
asknask commentedon Oct 9, 2026
I don't have as many details as the posters above but I've never been able to get computer-use to work for me (always fails, not just with the latest version).
yuanjie-design commentedon Oct 9, 2026
Additional confirmed reproduction on Windows 11 Pro, build 26200, observed on 9 October 2026.
Environment
Impact and sanitized error
Both ordinary sandboxed shell commands (including Get-Location) and in-app browser/Node REPL initialization fail before execution. Explicitly approved commands outside the sandbox can run. The failure reproduces with both workspace-write and read-only task permissions.
The log also identified the same sharing violation on the CUA Swift runtime's VCRUNTIME140_1.dll. Process-module inspection confirmed that DLL was loaded by codex-computer-use-swift.exe, whose parent was the desktop application's ChatGPT.exe process. Stopping that helper caused the application to restart it.
Verified recovery attempts
codex sandbox cmd.exe /d /c echo SANDBOX_OK. This succeeded with exit code 0 at 14:08:53 Asia/Shanghai. After the desktop application reopened, the next sandboxed command failed at 14:11:42 with the same node_repl.exe sharing violation.ReadAndExecute, Synchronize. This does not establish all effective permissions, but the recorded failure is a sharing violation, not an access-denied error.failed to prepare MXC sandbox: native MXC is unavailable on this executor. No saved configuration was changed by the probe.No runtime binaries, ACLs, sandbox mode, or approval policy were manually modified. The desktop reinstall preserved the existing user configuration; this was not a clean-user-profile test. Root cause is not proven, but the observations are consistent with ACL refresh failing when bundled runtime files are in use.
Please confirm which supported Windows desktop release includes a fix for this failure, and whether a supported recovery or hotfix is available. Personal paths, project content, account credentials, session transcripts, and full logs have been omitted.
dawsongrattidge1 commentedon Oct 9, 2026
Additional reproduction and diagnostics from Codex desktop on Windows, 2026-10-09.
Environment
codex-cli 0.162.0-alpha.2.Impact and reproduction observed
Even a sandboxed
Get-LocationorGet-Contentfails before the command starts:The same read-only diagnostic commands run successfully outside the sandbox through approved escalation. The Node REPL also reported
trusted Node process exited unexpectedly; kernel reset, rerun your request.Sanitized sandbox log evidence
After terminating the Codex JavaScript kernels, the next failing target became:
bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll.A Windows Restart Manager resource query for that DLL identified
codex-computer-use-swift.exeas its user. Stopping that helper did not resolve the issue: the app immediately respawned it. Its observed parent was the app'sChatGPT.exeprocess.Diagnostic workaround and outcome (not a supported or durable fix)
We preserved the loaded originals outside the runtime validation directory and replaced the affected runtime binaries with copies whose SHA-256 hashes matched the originals. Targets included the Swift helper executable, its three Microsoft runtime DLLs, and subsequently
bin\node.exe. No executable contents or sandbox policy settings were changed.After these changes, normal sandbox commands succeeded. We verified reading an existing workspace file, creating a temporary file, reading it, editing it, and deleting it. All passed without escalation.
However, at 18:13 UTC on the same day, a later sandboxed read failed again, with the log once more naming
bin\node_repl.exeand OS error 32. The recovery was temporary and appears dependent on helper process lifetime.Expected behavior / investigation request
Sandbox setup should work while Codex-provided JavaScript and computer-use helpers are running. Please investigate runtime ACL validation/update handles and compatibility with loaded executables/DLLs, and provide a supported durable fix. Exact internal file-opening flags have not been inspected; the sharing-mode explanation remains a hypothesis supported by the above observations.
Only sanitized diagnostic excerpts are included; no workspace contents, credentials, or full session transcripts are attached.
BEN2GOYVR commentedon Oct 9, 2026
Additional reproduction details from an affected Windows 11 Home environment:
@openai/codex)Minimal independent reproduction (in PowerShell 7, outside Orca):
Result:
The same failure occurs before execution of harmless commands such as
Get-DateorGet-Locationfrom Orca/Codex.Diagnostics:
codex doctor --summary: 20 ok, 1 idle, 5 notes, 3 warn, 1 fail. The failure iselevated Windows sandbox provisioning recorded a structured failure.runtime read/execute validation failedon%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe, withopen ACL target for root-only updatereturning OS error 32 (file in use by another process).C:\Users\Default(OS error 5); its relationship to the primary failure is unconfirmed.node_repl.exereturned no result when checked.codex --versionandcodex --helpwork; Doctor reports installation, authentication, local DBs and connectivity healthy.Recovery attempted without success:
EPERMcleanup warning forcodex-code-mode-host.exewhile replacing files, but the CLI remains operational.I have not disabled the sandbox, changed ACLs, granted Defender exclusions, or deleted runtime files.
Could you confirm whether this is a known runtime lifecycle / elevated sandbox ACL coordination issue and recommend a supported fix that preserves existing authentication, sessions and repositories?
enrico-f commentedon Oct 10, 2026
Additional reproduction — Codex CLI 0.162.1 on Windows
I can confirm that the same issue is reproducible on my Windows development workstation.
Environment
elevatedworkspace-write, approval policyon-requestObserved behavior
Any command executed from an interactive Codex session fails during sandbox initialization, including harmless read-only commands such as
Get-Location.The sandbox log consistently identifies the underlying error:
Troubleshooting performed
codex sandbox cmd /d /c echo CODEX_SANDBOX_OK.codexsandboxofflineWindows account.elevatedsandbox: same initialization failure.unelevated: command execution also failed, with aCreateProcessAsUserWerror.node_replMCP server: no improvement.Get-Location: failed before PowerShell could run.node_repl.exe: no matching handles found.Additional observation
The standalone
codex sandboxdiagnostic works, whereas normal interactive Codex sessions fail. The diagnostic and interactive execution paths appear to use different sandbox setup configurations.Disabling the
node_replMCP server does not prevent the interactive sandbox initialization from validating access tonode_repl.exe.Expected behavior
The Windows sandbox should initialize successfully and execute commands permitted by
workspace-write, without requiring users to disable sandbox protections.Request
Could the maintainers confirm whether a fix for this runtime ACL sharing violation is included in an upcoming stable Codex CLI release?
Thank you for investigating this issue.
acquirenti-cell commentedon Oct 11, 2026
Ulteriore caso verificato su Windows l'11 ottobre 2026 (interfaccia italiana).
Ambiente: pacchetto desktop OpenAI.Codex 26.1002.7124.0 x64; configurazione windows.sandbox = "elevated". Il servizio CodexSandboxService.OpenAI.Codex risulta in esecuzione.
Fatti verificati:
Problema aggiuntivo riportato dall'utente: dopo aver selezionato l'approvazione per la sessione, ricompare una richiesta apparentemente identica. La schermata mostra "Command approval", "Approve", "Approve for session", "Decline", mentre il testo della richiesta è in italiano. Non è stato verificato se le richieste sottostanti siano identiche o se cambi il comando; non affermiamo che la persistenza delle approvazioni sia la causa primaria.
Richiesta: correggere il conflitto nell'inizializzazione della sandbox senza disabilitare le protezioni, chiarire il motivo delle nuove approvazioni e tradurre il dialogo in italiano. Nessun file di lavoro, dato dei contatti, identificativo della chat o percorso personale è allegato.
Michaelnb86 commentedon Oct 12, 2026
Additional direct file-use evidence from an affected Codex Desktop session on 2026-10-12 (Asia/Shanghai):
OpenAI.Codex_26.1002.7124.0_x64; bundled CLI reports0.162.0-alpha.2.helper_unknown_error: setup refresh had errors. An explicitly approved command outside the sandbox runs.runtime read/execute validation failedwhile opening%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exefor a root-only ACL update, returning Windowsos error 32(file in use).RmRegisterResources+RmGetList) while the failure was active. The query returned four associated processes, allnode_repl.exerunning from the same executable path. Two were direct children of the Codex app-server process; the other two were children of its CUA REPLnode.exeprocesses. This is direct, simultaneous file-use evidence, not only a process-name inference.This does not reveal the setup helper's exact file-open/share flags, but it narrows the failure to ACL validation of an executable that other Codex runtime processes are actively using. Please confirm whether a supported desktop build includes a fix for this concurrency case. Personal paths, account details, project data, and full logs are omitted.
lmsworking commentedon Oct 13, 2026
Additional reproduction: managed daemon 0.162.1, runtime process lifetime, and sandbox setup source comparison
I reproduced the Windows sandbox ACL sharing violation on October 13, 2026 (Asia/Taipei).
Environment
0.162.1%LOCALAPPDATA%\OpenAI\Codex\bin\%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\cfb32733c877621e\bin\node_repl.exeObserved failure
Even a basic PowerShell command such as
Get-Locationfails before execution:The sandbox log identifies:
Process hierarchy
The managed app-server daemon had the following active descendants:
Both
node_repl.exeprocesses were executing the same runtime executable.Verified timeline (local time, UTC+8)
codex.exestartednode_repl.exePID 62700 andnode.exePID 61320 startednode_repl.exePID 42660 startedThis establishes that both runtime processes existed before the failing sandbox refresh. The exact file handle responsible for the sharing violation has not been independently identified.
Successful versus failing setup sources
The same day's sandbox log contained repeated successful refreshes using:
Those refreshes completed with
errors=[], using a command runner identified as0.162.0-alpha.17.2.Failing refreshes were launched from:
This is a correlation, not proof of a version-specific regression, because runtime and process states also differed.
Recovery attempts
node_repl.exeprocesses — new runtime processes appeared and the same failure recurred.Related upstream fix
PR #51822, Avoid sharing violations when repairing Windows runtime ACLs, was merged on October 7, 2026.
#51822
The documented change from
MAXIMUM_ALLOWEDtoREAD_CONTROL | WRITE_DACfor file ACL operations appears directly relevant to this failure.Questions for maintainers
0.162.1include PR Avoid sharing violations when repairing Windows runtime ACLs #51822?I can provide additional sanitized log excerpts if needed.
Louis-1991 commentedon Oct 13, 2026
Confirmed workaround on Windows – Codex CLI 0.162.1
I encountered the same Windows sandbox issue with Codex CLI 0.162.1.
Every command failed with:
Even a simple
Get-Locationcommand could not execute.Root cause observed
The sandbox log showed:
Restarting Windows did not resolve the problem.
Switching temporarily to
windows.sandbox="unelevated"allowed commands to execute, but I wanted to restore the normal Windows sandbox.What worked for me
Step 1 – Completely close Codex
Exit Codex CLI.
Step 2 – Identify remaining Codex processes
Open a separate PowerShell window:
In my case, two
codex.exeprocesses and twonode_repl.exeprocesses were still running after closing Codex.Step 3 – Terminate only the remaining Codex processes
Use the process IDs identified in Step 2.
Example:
Replace the placeholders with your actual process IDs.
Do not terminate unrelated Node.js processes.
Run the process check again to confirm that no Codex runtime processes remain.
Step 4 – Locate the affected runtime directory
My affected runtime directory was:
Your runtime directory name may be different.
Step 5 – Rename the runtime directory
Instead of deleting the runtime, I renamed it to keep a backup:
Important: Replace the runtime directory name with the one found on your system.
Step 6 – Start Codex normally
No
unelevatedoverride was used.Step 7 – Verify sandbox execution
Inside Codex, I requested:
Get-LocationResult:
SUCCESS!
The normal Windows sandbox was working again.
Conclusion
Renaming the existing
cua_noderuntime directory allowed Codex to recreate it.This resolved the sandbox initialization failure on my installation.
No Codex reinstall was necessary.
No Windows ACL or security permission changes were required.
No project files were modified.
The original runtime directory was preserved as a backup.
This is a locally confirmed workaround, not necessarily a universal or permanent fix.
Hopefully this helps others experiencing the same issue!
GOOD LUCK!