Repository navigation
Windows sandbox fails opening running node_repl.exe for ACL update (error 32); Computer Use and shell blocked #51590
Description
Summary
On Windows 11, Computer Use cannot initialize and ordinary sandboxed shell commands fail before execution with helper_unknown_error: setup refresh had errors. The sandbox log identifies an error 32 (sharing violation) when opening the running node_repl.exe for an ACL-related operation. Restarting the app and rebooting the PC did not resolve it.
This report is submitted at the affected user's explicit request. Paths are anonymized; no credentials, personal files, or full session transcripts are included.
Environment
- Windows 11 Pro, version 10.0.26200.
- Desktop app's bundled CLI:
codex-cli 0.162.0-alpha.2(verified with --version; desktop app version not verified). - cua_node manifest:
node_version: 24.21.0-cua.1,node_binary_version: 24.21.0. - Runtime archive:
cua-node-0.0.29-20261003001300-807782c586fc-windows-x64.zip. - Runtime path:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\2c9e75c4e9c71beb\bin\node_repl.exe. - Observed on October 7, 2026.
Steps and actual behavior
- Initialize the documented Computer Use runtime in node_repl:
const { sky } = await import("@oai/sky"); await sky.list_apps();
- The call fails before app discovery:
Some attempts instead report
node_repl kernel exited unexpectedly windows sandbox failed: helper_unknown_error: setup refresh had errorstrusted Node process exited unexpectedly; kernel reset, rerun your request. - Resetting the JavaScript kernel and retrying does not resolve it.
- A trivial ordinary sandboxed PowerShell command,
Write-Output 'sandbox-diagnostic-ok', also fails before execution:Failed to create unified exec process: helper_unknown_error: setup refresh had errors - App restart and a verified Windows reboot do not resolve it. Windows boot time was 14:06 JST; matching failures were logged at 14:23 JST.
Relevant sandbox log (anonymized)
runtime read/execute validation failed:
validate runtime read/execute access on %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\2c9e75c4e9c71beb\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 error: setup refresh had errors
setup refresh: exited with status ExitStatus(ExitStatus(1))
A similar error is logged for the user-profile directory, but that entry says continuing setup; the executable validation is listed as the fatal setup error.
Additional read-only diagnostics
Windows Restart Manager (RmRegisterResources / RmGetList, without any shutdown call) identifies eight live node_repl.exe processes using the same executable. Their parent chains all lead to codex.exe and then the desktop app's ChatGPT.exe, either directly or through node.exe. Existing runtime processes remain alive while new initialization fails. Their existence alone does not prove which particular handle causes the sharing violation.
A controlled CreateFileW probe only opens and closes handles; it makes no file-content or ACL changes. For the running node_repl.exe:
| Desired access | Share flags 7 (read/write/delete) | Share flags 1 (read) | Share flags 0 |
|---|---|---|---|
| READ_ATTRIBUTES | Success | Success | Success |
| READ_CONTROL | Success | Success | Success |
| READ_CONTROL + WRITE_DAC | Success | Success | Success |
| GENERIC_READ | Success | Success | Success |
| GENERIC_READ + GENERIC_WRITE | Error 32 | Error 32 | Error 32 |
The running node.exe shows the same results. A non-executable diagnostic script used as a control opens successfully in all these cases. On the user-profile directory, GENERIC_READ/GENERIC_WRITE with share flags 0 reproduces error 32, while share flags 1 and 7 succeed.
The deployed node.exe --version works in a separately approved execution context and prints v24.21.0.
There were no matching node_repl executable-validation errors in the available October 4–6 sandbox logs. The October 7 log first contains this error at 09:34 JST, after the current executable files' 08:53 JST modification times. This is a temporal association, not proof of an update regression.
Hypothesis and requested investigation
The results suggest that the ACL preparation path may request unnecessary file-content write access for a running executable, or otherwise use access/share flags incompatible with a live runtime. The actual helper's CreateFile arguments have not been captured, so this remains a hypothesis.
Please examine the open ACL target for root-only update / runtime validation path and advise on a supported repair or fixed build that preserves sandbox protections. No ACL changes, sandbox disabling, binary replacement, or process termination were attempted.
Expected behavior
Computer Use and ordinary local execution should initialize while other bundled runtime processes are running, or report an actionable supported recovery path.
Related reports
- Windows: all local execution fails with helper_unknown_error: setup refresh had errors #51090
- Windows Computer Use fails to initialize: helper_unknown_error: setup refresh had errors #43255
- Windows Computer Use fails after trusted Node process exits;
setup refresh had errorsand native GUI APIs are unavailable #43373
This report adds the specific error-32 log and controlled access-mode probe to the similar startup failures.
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
M4rkzzz commentedon Oct 7, 2026
Additional reproduction and verified fallback recovery on another Windows installation (2026-10-07, UTC+08):
Environment
codex doctor:26.1002.6548.0.codex-cli 0.162.0-alpha.2.[windows] sandbox = "elevated".Observed failure
An ordinary PowerShell
Get-Locationfailed before the command started:The sandbox log identified:
Other attempts failed on the same runtime's
node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll.The target files existed and already had inherited ReadAndExecute access for
CodexSandboxUsers. Stopping idle runtime helpers did not provide a durable recovery; the desktop app respawned its Swift helper. Adding an equivalent explicit ACL did not help and was fully reverted. No broad ACL reset, runtime deletion, or binary replacement was performed.Separately approved
require_escalatedshell commands worked, so this was not a complete loss of connectivity or a failure to read the project under the current Windows account.Tested fallback, with actual original-chat verification
The documented unelevated fallback worked with the same bundled CLI. A one-off test used:
The diagnostic successfully read and parsed an existing JSON file, wrote and removed a temporary file inside the workspace, and rejected a temporary write outside the workspace. Git status also succeeded.
After backing up
config.toml, we changed only:The idle local executor used by the cloud chat was then restarted, and the desktop app reconnected it to the existing environment. In the original cloud chat, ordinary default-permission commands subsequently succeeded without
require_escalated:Get-Location: exit 0, correct existing workspace.git --no-optional-locks status --porcelain --untracked-files=no: exit 0, existing 347 tracked-change entries still present.No account re-registration, credential deletion, chat recreation, Git reset, or project source changes were needed for this recovery.
Limits / requested fix
This is a verified fallback, not a repair of the elevated implementation. Unelevated mode has weaker network isolation. The already-running local desktop chat continued using its old configuration and still failed; only the restarted cloud executor/original cloud chat was verified recovered. A full desktop restart was not performed as part of that final acceptance.
Please provide a fix that lets the elevated sandbox validate live bundled runtime files without blocking all ordinary command execution. A clearer error showing the failing file and sharing violation, plus a supported executor configuration-reload/recovery action, would also help.
This comment intentionally omits private workspace paths, conversation/environment IDs, file contents, credentials, and full diagnostic archives.
gpsboss1 commentedon Oct 7, 2026
Additional verified recovery after downgrading the complete desktop app on another affected computer (2026-10-07).
Environment and failure
helper_unknown_error: setup refresh had errors. Logs identified the runningnode_repl.exeand, on subsequent attempts, the loadedVCRUNTIME140_1.dll, withopen ACL target for root-only update/ os error 32. Restarting the app and Windows did not provide a lasting recovery.Recovery after downgrading the complete desktop app
After the downgrade, the running desktop package was verified as
OpenAI.Codex_26.930.7945.0_x64, with bundled CLI0.160.1. We restored[windows] sandbox = "elevated", fully exited and reopened the desktop app, and verified the following in the original chat:require_escalated.apply_patchsuccessfully created, modified and deleted a temporary file; reading back the modified content also passed.This verifies recovery in the original chat after a complete desktop-app downgrade, adding to the separate older-CLI comparison in #51596. On the failing release, switching to unelevated and restarting had also restored command and patch execution. The current configuration is back to elevated.
Native API comparison and limitations
On the failing release, a controlled
CreateFileWcomparison against the same runningnode_repl.exeused identicalOPEN_EXISTING, read/write/delete sharing, andFILE_FLAG_BACKUP_SEMANTICSparameters:MAXIMUM_ALLOWED: failed with error 32.READ_CONTROL: succeeded.READ_CONTROL | WRITE_DAC: succeeded.The target's ACL was readable, and the sandbox group already had read/execute permissions.
These observations support a regression involving runtime ACL initialization, but both the desktop app and its bundled CLI changed during the downgrade, so the unique cause has not been isolated. There is no clean-install reproduction, and the specific conflicting handle has not been identified with a debugger. A candidate source patch was not compiled or installed and must not be treated as a verified fix.
Please investigate whether
MAXIMUM_ALLOWEDis necessary when validating running files that already have the required read/execute permissions. Personal paths, project contents, credentials and complete raw logs are omitted.zweek9999-prog commentedon Oct 7, 2026
Corroborating this issue on a Windows 10 Pro x64 host (build 19045). The affected user confirms a direct before/after: Browser and Computer Use worked before using the blue in-app download/update button above the account avatar, and stopped working after the desktop-app update. Windows update history also records a desktop package replacement from 26.930.7945.0 to 26.1002.6548.0 at 18:17 on 2026-10-07. The failing app reports release 26.1002.51308 (build 13417, production channel). This is an update-triggered regression on this host; the package update should be investigated, distinct from the separately listed Workspace Dependencies bundle.
await cua.getState()) and Computer Use/Node REPL fail before returning browser or app state. Resetting and retrying the JS kernel gives the same failure.helper_unknown_error: setup refresh had errors. The same read-only command succeeds through the approved escalated execution path.helper_unknown_error/setup refresh had errors. The October 7 sandbox log identifies the fatal step as read/execute validation ofnode_repl.exe:open ACL target for root-only updatefails with Windows error 32 (the file is being used by another process).Expected: sandboxed local commands and Browser/Computer Use initialize normally after a desktop-app update. Please investigate what changed in the desktop package/runtime ACL setup and provide a supported recovery path. The specific code-level cause remains for maintainers to identify. This comment contains no personal path, runtime identifier, raw log, credential, or session transcript. Updated at the affected user's explicit request.
Follow-up (2026-10-08): The complete desktop app was rolled back to MSIX 26.930.7945.0; the running executable path and Windows registration were verified. Ordinary sandboxed commands and native Computer Use then worked again in the original chat. This is a verified recovery for the sandbox/tool-startup failure on this host, not a fix for the newer release. A separate external-Chrome request-header-policy error still occurs on the rolled-back version, while the in-app browser works; that distinct issue is documented in #44140. The earlier Browser Use bullet describes the failure as observed on the newer build and should not be read as evidence that both failures share one cause.
JerryWei1577 commentedon Oct 7, 2026
Additional independently observed report, submitted at the affected user's explicit request. Personal paths and project information are omitted.
Environment (verified locally)
Impact / observed behavior
Ordinary shell requests fail before command-process creation, including Get-Location and git status:
Consequently compilation and tests cannot start. External PowerShell works. An unrestricted diagnostic execution context also works; this does not establish that the sandbox has recovered.
Newest sandbox error array (path anonymized)
The same node_repl target appears at 2026-10-07T13:32:53.316381200Z, 13:38:38.446961700Z, and 13:52:21.696427800Z:
The Chinese message means: another program is using the file and the process cannot access it (Windows sharing violation).
Earlier errors targeted node_repl.exe in runtime 2c9e75c4e9c71beb at 11:18:42Z / 12:04:02Z, and its bin\node_modules\@OAI\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll at 12:36:52Z. That old runtime directory is now absent; the same class of failure persists on the new runtime after reboot.
Read-only resource-owner diagnostics
Windows Restart Manager (RmRegisterResources / RmGetList; no shutdown API) registered the EXACT current node_repl.exe path and returned these three live users. Independently enumerating process modules confirmed that each maps that exact executable:
These parents are alive; the evidence does not support treating these as orphaned pre-reboot processes. They were created after the verified reboot.
In addition, codex-computer-use-swift.exe PID 2220 (parent ChatGPT.exe, started 13:08:42Z) maps the current runtime's own VCRUNTIME140_1.dll, VCRUNTIME140.dll and MSVCP140.dll under @oai/sky/bin/windows/swift/x64.
This establishes current resource users / mapped images, not the precise helper handle or CreateFile access/share flags responsible for error 32.
Request
Please investigate why normal live bundled runtime processes make the ACL preparation/runtime validation fatal for unrelated subsequent shell requests. A supported fix should retain sandbox protections and permit ordinary commands while these runtimes are running. Please also check the Swift DLL targets so resolving only node_repl.exe does not expose a second identical failure.
No runtime process was terminated, no runtime was manually deleted/replaced, and no manual ACL/security/configuration change was made during this investigation. Only sanitized error excerpts and process relationships are supplied; no credentials, .sandbox-secrets, private sessions, repository contents or complete logs are attached.
Haisemberg2008 commentedon Oct 7, 2026
I am experiencing a closely matching failure on Windows after a Codex update. Normal command execution fails before process creation with exec-server (-32603), helper_unknown_error: setup refresh had errors. The sandbox log reports a sharing violation (os error 32) while opening the bundled runtime at %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node<runtime>\bin\node_repl.exe for runtime read/execute validation and a root-only ACL update. Computer Use is also unavailable.
Restarting the application and Windows, resetting/reinstalling Codex, and signing in again did not resolve it. Two node_repl processes were checked against that exact runtime location and manually terminated as a controlled test. They disappeared, then node_repl instances reappeared. One subsequent minimal Get-Location attempt failed with the same setup error. Resource Monitor handle searches did not identify the blocking handle.
The timing suggests a possible update regression, but we have not established causality or identified the specific blocking process. We have not removed the runtime, changed ACLs, disabled sandbox protections, or reinstalled the system Node.js installation. Could the maintainers provide a supported repair or fixed build, and specify which sanitized diagnostics would help?
deerwoodmedia commentedon Oct 7, 2026
I can confirm the same issue on ChatGPT/Codex Windows 26.1002.7124.0.
Browser control fails with helper_unknown_error: setup refresh had errors.
My sandbox log shows:
runtime read/execute validation failed ... cua_node\3dd31cfff853001c\bin\node_repl.exe ... The process cannot access the file because it is being used by another process. (os error 32)
I confirmed the process chain is:
ChatGPT.exe → codex.exe → node.exe / node_repl.exe
I reproduced it after Repair, Reset, complete reinstall/reboot, rebuilding .sandbox-bin, terminating all Codex runtime processes, and completely regenerating the cua_node runtime. A freshly regenerated runtime immediately produces the same error.
App version: 26.1002.7124.0
Browser/Computer Use is completely unavailable as a result.
qujiahe777-gif commentedon Oct 7, 2026
Additional reproduction on a newer Windows Desktop build
I can reproduce the same failure after updating to:
OpenAI.Codex package:
26.1002.7124.0
Package:
OpenAI.Codex_26.1002.7124.0_x64__2p2nqsd0c76g0
Platform:
Windows 11 x64
Use case:
A ChatGPT Dot attempts a minimal local-computer task that only reads one harmless local text file.
Reproduction
DOT_LOCAL_RUNNER_OK
User-visible error
exec-server rejected request (-32603):
helper_unknown_error: setup refresh had errors
The Dot stops without retrying and never reads the file.
Relevant sandbox log
At approximately 2026-10-07 10:50:58 America/Vancouver
(2026-10-07 17:50:58 UTC):
failed to grant non-inheriting read-attributes ACE on user profile
%USERPROFILE%:
open ACL target for root-only update:
The process cannot access the file because it is being used by another process.
(os error 32);
continuing setup
The fatal error immediately afterwards is:
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)
setup refresh: processed 1 write roots (read roots delegated);
errors=["runtime read/execute validation failed ... node_repl.exe ... os error 32"]
setup refresh completed with errors
setup error:
setup refresh had errors
codex-windows-sandbox-setup.exe exits with status 1.
Important update/regression evidence
Before updating the Desktop app, the same class of failure was observed against an older cua_node runtime:
cua_node\2c9e75c4e9c71beb\bin\node_repl.exe
After updating to package 26.1002.7124.0, a new runtime is being used:
cua_node\3dd31cfff853001c\bin\node_repl.exe
The same ACL-open sharing violation still occurs on the new node_repl.exe.
This makes a stale/corrupted single old runtime less likely.
Additional A/B observation
On the same PC, with ChatGPT/Codex Desktop fully closed, a standalone Codex CLI sandbox probe has been able to execute real read-only and isolated workspace-write tool calls successfully.
When the Desktop/Dot local-task path is used, local execution fails during sandbox setup as described above.
I am not claiming that this proves the exact locking process or code-level root cause, but it suggests that Desktop/runtime process lifecycle may be relevant.
Impact
No unsupported workaround was used for this reproduction:
Request
Please investigate the Windows Desktop / cua_node lifecycle together with the sandbox ACL refresh path.
In particular, could the sandbox ACL validation avoid requesting an access mode that conflicts with the already-running node_repl.exe, or sequence runtime startup and ACL preparation so that the executable is not locked during validation?
A supported workaround or confirmation of a fixed Desktop build would be very helpful.
JBRonaldo commentedon Oct 7, 2026
Additional reproduction on Windows 11 build 22631, submitted at the affected user's request. This adds a delegated-task comparison and a fresh failure after a separate task-dispatch problem improved.
Minimal reproduction and latest result
Get-Location.exec-server rejected request (-32603): helper_unknown_error: setup refresh had errorsThe latest reproduction was on October 7, 2026, approximately 17:40–17:50 UTC; an exact timestamp was not retained. No browser or Computer Use operation was requested for this minimal test.
Environment and version limits
26.1002.7124.0was previously verified running.26.930.7945.0package was tried as a rollback, after which the user returned to the latest version. The exact currently running package version has not been reverified, so the fresh reproduction should not be attributed to a specific package version.Diagnostic evidence and comparison
Earlier sandbox diagnostics identified this sequence: runtime read/execute validation failed → open ACL target for root-only update → Windows error 32 (sharing violation), targeting the bundled
runtimes/cua_node/<runtime-hash>/bin/node_repl.exe.Read-only Windows Restart Manager inspection found resource users in the current Codex/ChatGPT process tree. This does not establish the precise conflicting handle or justify describing those processes as orphans. No processes were terminated and no ACLs were changed during that inspection.
The affected user reports that directly created local Codex tasks can execute commands. In the failing delegated task, command execution through the connected Remote Desktop Commander tool works, while the native exec path fails. These paths may have different execution/security contexts, so the successful alternative does not establish that the native sandbox is healthy.
A separate task-dispatch outage had improved enough for delegated-task creation, reading, and messaging to work again, but the first native exec request still failed. Task-dispatch recovery therefore did not establish recovery of this Windows execution failure; no causal link between the two problems is claimed.
Expected behavior and request
A basic
Get-Locationshould start in the supported native execution path without being blocked by an unrelated active Computer Use runtime file.Could maintainers provide a supported recovery path that preserves sandbox protections, or identify a fixed desktop build? Please consider the difference between directly created local tasks and dot-delegated tasks when investigating. We have not identified the internal root cause and are not proposing sandbox disabling or termination of active runtime processes.
Related discussion: #51601. This comment contains only a sanitized technical summary; no project contents, account/device identifiers, full local paths, private task IDs, credentials, raw logs, or session transcripts are attached.
laurentziuul commentedon Oct 7, 2026
Confirming the same issue on another Windows machine.
Environment:
C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exeObserved behavior:
The process cannot access the file because it is being used by another process. (os error 32)while sandbox setup tries to update/validate access to
node_repl.exe.node_repl.exeprocesses from that exact Codex runtime remained alive.node_repl.exeprocesses manually and verified none remained.The machine has also been rebooted multiple times and Windows system integrity has been verified:
DISM /Online /Cleanup-Image /CheckHealth→ no corruptionsfc /scannow→ no integrity violationsThis strongly suggests a regression in the Codex Windows sandbox/runtime lifecycle rather than a Chrome-specific problem: stale
node_repl.exeprocesses can cause the initial sharing violation, but killing them alone is not sufficient to restore Computer Use / Chrome connectivity.Happy to provide the relevant sandbox log, process listing, screenshots, or additional diagnostics if useful.
15 remaining items
LyshineTo commentedon Oct 8, 2026
Additional reproduction on another Windows machine. A normal application restart did not resolve the failure.
Environment
26.1002.7124.0.Failure
After restarting the app, a single
Get-Locationrequest failed before the command process was created:The matching sandbox log still identifies the same runtime executable:
The helper then reports
setup refresh had errorsand exits with status1.A separate user-profile warning also reports error
32, but explicitly sayscontinuing setup. The fatal errors array contains the runtime executable validation error.Read-only diagnostics
RmRegisterResources/RmGetList, without shutdown or restart calls) identifies three live processes using this executable.MainModuleinspection independently confirms that all three map the same executable image.Process/Threadobjects, not namedFile/Sectionhandles referring to the executable.Limits of this evidence
The absence of a matching named file handle does not rule out executable-image occupancy.
Process/Threadhandles and theirGrantedAccessvalues are not executable-file access rights.These snapshots were taken after the failure and cannot identify a historical transient handle. We have not captured the helper’s actual
CreateFiledesiredAccess/shareModeparameters, nor reproduced the access-mode probe from this issue locally.No project-owner/ACL reset, sandbox disabling, binary replacement, forced process termination, or handle closure was attempted.
Request for maintainer guidance
Could you help confirm:
open ACL target for root-only updaterequests access incompatible with an already loaded executable.Danieldewolf13 commentedon Oct 8, 2026
Additional Windows reproduction, posted with the affected user's explicit authorization.
Environment:
cua_node/3dd31cfff853001chelper_unknown_error: setup refresh had errors, Windows error 32 while updating the ACL ofnode_repl.exe, andtrusted Node process exited unexpectedly; kernel resetNew recovery evidence:
node_repl, Codex, and ChatGPT processes.%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_nodedirectory aside.cua.getState()immediately reproduced the same failure.This suggests the problem is not fixed by clearing/recreating the runtime, ordinary permission grants, or restarting all related processes. It currently forces extensive manual PowerShell copy/paste and blocks reliable browser automation. We have deliberately not switched to
[windows] sandbox = "unelevated"because that weakens isolation; a supported fix that preserves the normal sandbox model would be appreciated.No credentials, account identifiers, project identifiers, or private local paths are included here.
Sparkler2 commentedon Oct 8, 2026
I’m experiencing the same node_repl.exe sharing violation (Windows error 32) on Windows 10 Pro, build 19045. Browser control and ordinary sandboxed commands fail. Restarting the app and rebooting Windows did not resolve it.
Feedback ID: 01a0ed6e-9640-7fd2-b307-251db40a6ebd
Kelten229 commentedon Oct 8, 2026
Same issue here: Codex app for Windows (Microsoft Store) 26.1002.x, bundled CLI 0.162.0-alpha.2.
sandbox log: "open ACL target for root-only update ... node_repl.exe ... (os error 32)".
Setting [windows] sandbox = "unelevated" does NOT help. No node_repl process is running before launch, so the lock is held by the app itself during setup refresh (matches the root cause in #51623).
SaschaK93 commentedon Oct 8, 2026
Additional finding: unelevated workaround fails with split writable roots
I tested the community workaround by switching the Windows sandbox configuration to unelevated.
The original setup-refresh failure was bypassed, but execution was blocked by a different safety check:
unelevated ... cannot enforce split writable root sets ... refusing to run unsandboxed
The affected task requires separate writable root sets, which the unelevated sandbox cannot enforce.
No command was executed.
I am reverting to sandbox = "elevated" and will not disable sandbox protections or broaden filesystem permissions.
This suggests the unelevated workaround is not suitable for all affected Windows task configurations.
Feedback ID: 01a10f4b-95af-7544-938c-8d40c379802b
Please advise on a supported fix that preserves elevated sandbox isolation and split writable root restrictions.
chrisclezama commentedon Oct 8, 2026
Independent reproduction, ProcMon evidence, and partial recovery after rollback
I independently reproduced this issue on Windows with Codex Desktop package
26.1002.7124.0.Original failure
With
[windows] sandbox = "elevated", isolated execution failed before model inference with:helper_unknown_error: setup refresh had errorsThe sandbox logs identified Windows error 32 during
open ACL target for root-only update.Affected files included:
cua_node/.../bin/node_repl.execua_node/.../@oai/sky/bin/windows/swift/x64/VCRUNTIME140_1.dllProcess Monitor findings
Two independent ProcMon captures each recorded eight
SHARING VIOLATIONevents involving multiplecodex-windows-sandbox-setup.exeprocesses.The failing
CreateFilerequests showed:Read Attributes, Synchronize, Maximum AllowedOpenRead, Write, DeleteProcess Explorer confirmed that
codex-computer-use-swift.exehad loaded the exact DLL involved in the second failure. The Desktop application automatically restarted that component after termination.Restarting Codex, rebooting Windows, and terminating existing
node_repl.exeprocesses did not resolve the original failure.The exact conflicting handle owner was not conclusively identified.
Workaround and rollback results
Switching to
windows.sandbox = "unelevated"restored ordinary Desktop sandbox command execution and basic workspace file operations. However, this mode has weaker security isolation and was not suitable for our existing credential-bearing custom worker configuration.I subsequently installed the older, officially signed Desktop package
26.930.7945.0, containingcodex-cli 0.160.1, and restoredwindows.sandbox = "elevated".After the downgrade, ordinary Codex Desktop sandboxed PowerShell execution succeeded.
Get-Locationreturned exit code 0, and temporary file creation, verification, and cleanup passed. The original Windows error 32 did not recur during those tests.Limitation: The rollback restored basic Desktop execution, but I have not verified complete recovery of our custom isolated-worker environment. A separate nested-worker test encountered Windows error 5 involving access to Codex temporary/state storage. I am not claiming that this is the same defect.
I submitted a PDF containing screenshots, ProcMon findings, and diagnostic details privately to OpenAI Support.
Request to maintainers
Could you confirm whether a fix is planned for the elevated sandbox's runtime ACL-validation behavior, particularly the
Maximum Allowedaccess request against running executables and loaded DLLs?An official fix preserving elevated sandbox isolation would be greatly appreciated. The downgrade is a useful temporary recovery, but it is not a permanent solution.
chrisclezama commentedon Oct 8, 2026
Recovery update — regenerated
deny_read_acl_state.jsonFollowing my previous report, I wanted to document an additional recovery action that may help identify the underlying issue.
I found reports suggesting that Windows sandbox provisioning failures can involve inconsistent or stale state under:
%USERPROFILE%\.codex\.sandbox\In particular, the file:
deny_read_acl_state.jsonI had Codex regenerate that file as part of the recovery process.
Afterward, the original sandbox startup probe passed:
The setup returned
errors=[], instruction loading completed, and Windows error 32 did not recur during the probe.Important qualifications:
26.1002.7124.0to26.930.7945.0during troubleshooting.This may be worth investigating as part of the elevated sandbox provisioning/ACL-state lifecycle.
Could maintainers confirm whether stale or inconsistent
deny_read_acl_state.jsonstate could contribute to these failures and, if so, provide a supported state-regeneration procedure that preserves sandbox security?I am sharing this as a successful recovery observation, not a confirmed root-cause diagnosis.
lca-mse commentedon Oct 8, 2026
Today morning my Codex updated to 1002 too. yesterday night no problem, starting today after the updated codex invested a lot of tokens on 2 machines to analyze the broken sandboxes here too.
we wrote twice a /feedback
==
Title: Possible Windows sandbox regression after desktop app update: error 32 on node_repl.exe prevents all sandboxed commands
Summary
The Windows sandbox worked yesterday evening, October 7, 2026. Today, October 8, even a simple read-only command fails before execution.
The desktop app appears to have updated during this morning's restart. Yesterday I was using a release dated October 5; the currently installed release is dated October 7. I do not have the exact previous version number. The timing suggests a possible regression, but the update has not been confirmed as the cause.
Environment
Steps to reproduce
Exact prompt used:
“Führe ausschließlich Get-Location innerhalb der normalen Sandbox aus.
Keine Eskalation und keine Änderungen.”
Expected result
Get-Location runs inside the sandbox and returns the working directory.
Actual result
The command fails before the requested shell process starts:
Failed to create unified exec process:
helper_unknown_error: setup refresh had errors
Sandbox log
The latest confirmed failure occurred on October 8 at 09:56:43 local time, after a Windows reboot at 09:52:55.
The setup log reports:
runtime read/execute validation failed:
validate runtime read/execute access on
C:\Users\MarioSemo\AppData\Local\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exe:
open ACL target for root-only update:
Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. (os error 32)
English translation of the Windows message:
“The process cannot access the file because it is being used by another process.”
The log then reports:
setup error: setup refresh had errors
Relevant sandbox log file:
C:\Users\MarioSemo.codex.sandbox\sandbox.2026-10-08.log
Troubleshooting already performed
Read-only process and ACL diagnostics
Impact
Routine local development work is blocked inside the sandbox, including read-only workspace commands. Using individually approved commands outside the sandbox works, but introduces repeated approval requests.
Not yet tested
The documented unelevated sandbox fallback has not yet been tested.
Please investigate the sharing violation during runtime access validation, particularly whether the runtime processes are started before the sandbox setup attempts to update access to node_repl.exe.
==
Additional findings — October 8, 2026
At least one additional colleague has reported the same problem
starting today. This suggests a potentially broader issue.
The unelevated fallback has now been tested:
"couldn't create signal pipe, Win32 error 5".
After switching back to elevated and restarting the application,
even Get-Location again failed before execution.
Windows Restart Manager identified two processes using the exact
node_repl.exe named in the error:
Both processes were newly started with the current app instance,
rather than leftovers from an earlier run.
We terminated only these two node_repl.exe processes.
They did not reappear during the subsequent observation.
The next sandbox attempt progressed past node_repl.exe, but failed
with the same sharing violation (Windows error 32) on:
...\cua_node\3dd31cfff853001c\bin\node_modules
@OAI\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll
This suggests that runtime access validation encounters multiple
files already in use. Stopping node_repl.exe alone does not restore
the elevated sandbox.
No ACL changes were made during these additional tests.
hermannehrlich commentedon Oct 8, 2026
Same here. I hit this on Windows with Codex CLI 0.162.0-alpha.2. The sandbox setup helper failed with OS error 32 while Node/CUA runtime files were loaded. Stopping those processes made setup succeed, but the error returned when Node restarted.
A working temporary workaround was to keep the current CLI, command runner and code-mode host, but use the official 0.160.1 codex-windows-sandbox-setup.exe in a separate runtime directory.
A dedicated launcher briefly sets the user-level CODEX_CLI_PATH, refreshes Explorer’s environment, launches Codex normally, then restores the variable after confirming the selected CLI. A separate watchdog restores it after 45 seconds if startup stalls. Elevated sandbox now works with Node running. The launcher checks component hashes and stops after incompatible updates. This is a workaround though, not a real fix.
If you want, you can task your Codex to set up a temporary workaround with this prompt:
kn1cht commentedon Oct 9, 2026
Same here and downgrading to 0.160.1 worked. Hope this gets fixed soon!
25097988-rgb commentedon Oct 9, 2026
Additional reproduction on another Windows installation, submitted with the affected user's explicit authorization. Still reproducible on October 9, 2026 (UTC+08).
Verified environment
codex-cli 0.162.0-alpha.2.cua_node/3dd31cfff853001c.Failure
Both Browser Use (
cua.getState()) and Computer Use (@oai/skyinitialization andlist_apps()) fail before browser/app discovery:The profile-root read-attributes grant also reports error 32 non-fatally. The runtime validation failure is fatal. Resetting the tool session, fully restarting the desktop, and rebooting Windows did not resolve this.
Controlled local probe
On the exact active
node_repl.exe, usingCreateFileW,OPEN_EXISTING, share flags 7 (read/write/delete), andFILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT:All returned handles were closed immediately. No file data was written and no ACL was changed. Separate ordinary read/metadata probes succeeded. Windows Restart Manager's read-only resource query identified live
node_repl.exeinstances using this executable.This closely matches the access-mask explanation in #51623. We have not captured the installed setup helper's actual CreateFile call stack, so the binary-level cause remains correlated rather than independently proven. There is no evidence here attributing the failure to Chrome extensions, SSO, or endpoint security.
Please identify a supported fixed desktop build or recovery path preserving sandbox protection, particularly for Computer Use/Browser Use. No sandbox disabling, runtime replacement, ACL workaround, or security-software changes were applied. Credentials, personal paths, device identifiers, workspace content, and full chat/log archives are omitted.
volcano-77 commentedon Oct 9, 2026
Adding a reproduction on Windows 10 Home 22H2 (build 19045).
windows sandbox failed: helper_unknown_error: setup refresh had errors.node_repl.exefor a root-only ACL update because the file was in use (os error 32).node_repl.exeprocesses were observed starting at 19:34:05 and 19:34:06, before the failure. This is a timing observation; I have not identified which process, if any, held the conflicting handle.Please investigate the runtime ACL refresh failure and advise on a supported fix or recovery path. This report includes only a sanitized error summary; no full logs, personal paths, device identifiers, proxy details, credentials, or secret files are attached.
lca-mse commentedon Oct 10, 2026
Yes, the previous
node_repl.exeissue no longer occurs in the current checks.Successfully verified:
CodexSandboxOffline.node_replstarts successfully and executes JavaScript.sky.list_apps()works.node_repl.exeprocesses, the latest sandbox refreshes reporterrors=[]. No corresponding error 32 occurred today.No elevation of privileges or configuration changes were necessary.
elevatedis an appropriate setting: According to the [OpenAI documentation](https://learn.chatgpt.com/docs/windows/windows-sandbox), it is the preferred classic sandbox mode. MXC is now preferred on compatible devices.You can keep your current configuration unchanged.
(Version 1007)
pearsonkri87-cmyk commentedon Oct 13, 2026
Additional reproduction and process-isolation evidence, October 13, 2026 (EDT), submitted at the affected user's request.
Environment
Process isolation
Two live service branches shared the same runtime executable:
The earlier cua parent command line was verified. Later screenshots show the same parent structure; the later cua parent's command line was not independently verified, so that branch identity also relies on the prior verified structure and the user's identification.
The user performed the process terminations. Neither REPL was invoked after the direct-service termination in the latest isolation sequence. Earlier direct REPL invocations to read diagnostics occurred before that termination.
Fresh failure and recovery logs
At 2026-10-13T16:39:35.6879151Z:
After both processes ended, at 12:43:13 EDT the SAME app-server-daemon 0.162.1 helper and payload_len=3672 completed with errors=[]; Get-Location returned the workspace directory with exit code 0. The user-profile ACL warning explicitly saying continuing setup and the C:\Users\Default visibility warning remained on successful commands, distinguishing them from the fatal runtime validation error.
These tests support either remaining service branch being sufficient to retain the failure under the tested conditions, subject to the later cua-parent identification limitation above. Ending both restores shell access. The log identifies the file, not the locking PID or exact handle/share flags. Computer-use functionality itself was not invoked during the latest isolation run.
No sandbox configuration, ACLs, runtime binaries, or security settings were changed. No full config, session transcripts, screenshots, or unrelated logs are attached. Please investigate coexistence of active REPL runtimes and shell setup refresh, and identify a supported fixed build or recovery path that preserves sandbox protection.
behavioralvalueinvestor commentedon Oct 16, 2026
For anyone landing here after updating to CLI 0.163.0: #51822 fixed the os error 32 setup failure for me (
errors=[]). Browser Use still crashes with "trusted Node process exited unexpectedly" / "cua is not defined". That's a separate bug:trusted-worker.jsreceives noNODE_REPL_TRUSTED_SERVICES. Details and repro in #54447.