Repository navigation
Windows sandbox setup refresh fails on inaccessible old cua_node runtime after update #49433
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.928.20755
What subscription do you have?
ChatGPT Pro
What platform is your computer?
"$([Environment]::OSVersion.VersionString) $($(if ([Environment]::Is64BitOperatingSystem) { 'x64' } else { 'x86' }))"
What issue are you seeing?
All normal sandboxed shell commands fail before execution.
The error is:
Failed to create unified exec process:
helper_unknown_error: setup refresh had errors
The latest sandbox log repeatedly shows:
runtime read/execute validation failed on:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\f53823cd54b14f45\bin\node_repl.exe
CreateFileW failed, and setup refresh exits with status 1.
The current configuration references a newer cua_node runtime:
1b30f7d4d73226ca
The newer runtime's node_repl.exe can be opened for reading, but the older runtime referenced by sandbox setup returns Access Denied when read or when its ACL is queried.
This affects all normal local command execution. Restarting the Codex app, updating the app, and opening a new chat did not resolve the issue.
No project files, permissions, security settings, or Codex configuration were changed.
No matching Defender, Code Integrity, or AppLocker blocking event was found.
McAfee is installed, but there is currently no evidence that it caused the block.
What steps can reproduce the bug?
-
Open Codex desktop app on Windows.
-
Open any existing project or a new chat.
-
Ask Codex to run a simple command such as:
Write-Output 'LOCAL_EXEC_OK'
-
The command never starts.
-
Codex returns:
Failed to create unified exec process:
helper_unknown_error: setup refresh had errors -
Restart the Codex app and repeat.
-
Open a new chat and repeat.
-
The same failure occurs.
Additional observations:
- Current config references cua_node runtime 1b30f7d4d73226ca.
- Sandbox setup still validates old runtime f53823cd54b14f45.
- The new runtime file is readable.
- The old runtime node_repl.exe returns Access Denied.
- Parent directories are accessible.
What is the expected behavior?
Sandbox setup should use the current valid cua_node runtime referenced by the current Codex configuration.
Old or stale runtime versions should not prevent all local shell commands from starting.
A simple command such as:
Write-Output 'LOCAL_EXEC_OK'
should execute normally without the sandbox setup refresh failing.
Additional information
Additional diagnostics:
-
Current config.toml references the newer cua_node runtime:
1b30f7d4d73226ca -
The newer runtime's node_repl.exe is readable.
-
Sandbox setup still repeatedly validates the older runtime:
f53823cd54b14f45 -
The older runtime's node_repl.exe returns Access Denied even when its ACL is queried.
-
Parent directories are accessible and include inherited permissions for the current user, SYSTEM, Administrators, and CodexSandboxUsers.
-
Restarting Codex, updating Codex, and opening a new chat did not resolve the issue.
-
No matching Windows Defender, Code Integrity, or AppLocker block was found in the checked logs.
-
McAfee is installed, but it has not been confirmed as the cause.
-
No application configuration, project files, permissions, ACLs, or security settings were changed during diagnosis.
I also submitted the same diagnostic summary to OpenAI Support.
Possibly related to #46326, but this case specifically shows sandbox setup validating an inaccessible OLD cua_node runtime even though the current configuration references a newer readable runtime.
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
skyout457-cmyk commentedon Oct 1, 2026
Adding a corroborating reproduction with new build and recovery-test details. This matches the inaccessible
cua_node/.../bin/node_repl.exesymptom in this issue, but I have not established whether the affected runtime is stale or whether another runtime is currently configured.Environment and impact
Minimal reproduction
Get-Location.Top-level error:
The sandbox log reports:
The path above is sanitized. No native Win32 error code was included with the
CreateFileWfailure.Additional observations
node_repl.exeexists. File Explorer lists it as an Application, 33,250 KB.Continueprompt, Windows still says the object's permission settings cannot be viewed or edited.Recovery attempts
Requested help
Please provide a supported recovery or runtime-reprovisioning procedure that preserves conversations, local projects, and other user data. Please also preserve the native Windows error code in this failure so that inaccessible files, missing paths, and other causes can be distinguished.
Could the team investigate why inability to inspect one runtime file prevents even an unrelated read-only shell command from starting? We rely on these local capabilities for ongoing work and would appreciate a data-preserving workaround and a tracked fix.
This comment intentionally excludes usernames, computer names, email addresses, private project paths, and raw screenshots.
yktn3110 commentedon Oct 4, 2026
I encountered the same issue on Windows and found a workaround in my environment.
Restarting both Windows and the desktop app did not help.
My current configuration referenced cua_node runtime 45309f9050f7314b, but sandbox setup failed with Access Denied on node_repl.exe in an older runtime, b63ee7ee40c23b77.
I moved that old runtime directory to another location outside cua_node, keeping it as a backup rather than deleting it. The next test failed on another older runtime, 32a57e0f41f3a96a, with the same error.
After moving the second old runtime directory out as well, normal sandboxed shell commands and browser initialization succeeded. Reading an existing Chrome tab also worked.
This is only a workaround observed on my machine, not a confirmed root cause or general fix. I hope the sequence helps with the investigation.