Windows elevated sandbox fails during runtime ACL refresh with error 32 on node_repl.exe and computer-use DLL #51906

What version of the Codex App are you using (From “About Codex” dialog)?

26.1002.52244 Build: 13536 Release channel: prod Installed Windows package: OpenAI.Codex_26.1002.7124.0_x64__2p2nqsd0c76g0 Bundled Codex: codex-cli 0.162.0-alpha.2

What subscription do you have?

Enterprise

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 Windows 11 Pro, build 26200

What issue are you seeing?

Browser control, Windows computer use, and sandboxed shell commands fail before they can perform any action.

The Windows sandbox setup fails while validating or updating read/execute access on files in Codex's shared cua_node runtime. Windows reports that those files are in use.

Browser-control error:

node_repl kernel exited unexpectedly
kernel_status: exited(code=1)
kernel_stderr_tail: windows sandbox failed: helper_unknown_error: setup refresh had errors
reason: stdout_eof

Sandboxed shell error:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

The issue affects even a trivial sandboxed PowerShell command:
Write-Output 'sandbox-ok'

A read-only PowerShell command run through approved unsandboxed execution succeeds. The failure occurs before browser navigation or authentication, so it does not depend on a particular website.

Redacted sandbox log excerpts:

runtime read/execute validation failed: validate runtime read/execute access on
C:\Users<user>\AppData\Local\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)

After terminating the node_repl.exe processes, the next failure was:

runtime read/execute validation failed: validate runtime read/execute access on
C:\Users<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_modules@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll:
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

Configuration:

[windows]
sandbox = "elevated"

Task permissions:
sandbox_mode = "workspace-write"
approvals_reviewer = "auto_review"

What steps can reproduce the bug?

On the affected installation:

1. Start Codex on Windows with windows.sandbox = "elevated".
2. Open a local chat.
3. Ask Codex to run a trivial sandboxed PowerShell command:
   Write-Output 'sandbox-ok'
4. Observe "helper_unknown_error: setup refresh had errors".
5. Ask Codex to inspect the available browser sessions.
6. Observe the browser-control/node_repl kernel exiting before a browser session can be inspected.
7. Read the sandbox log. It reports Windows error 32 while opening a cua_node runtime file for an ACL update.

The failure persists after restarting Codex and rebooting Windows.

Session / submitted feedback reference:
01a118ff-93bb-7610-a879-54f768a792c9

Token-limit and context-window usage:
Not captured. A trivial command fails before execution, so no large prompt or long-running browser operation is required.

These steps reproduce the issue on this installation; reproduction on a clean installation has not been verified.

What is the expected behavior?

Sandbox setup should complete, and the trivial PowerShell command should print "sandbox-ok".

Browser control and Windows computer use should initialize successfully.

Runtime ACL validation should handle files already loaded by Codex's own helper processes without preventing all new sandboxed commands and computer-use sessions from starting.

Additional information

Process observations:

• After a laptop reboot, 16 node_repl.exe processes were observed running from the exact cua_node runtime path.
• Eight were direct children of codex.exe; the others were children of node.exe from the same runtime.
• The user reported no other actively executing Codex task.
• Terminating all 16 node_repl.exe processes reduced their count to zero, but sandbox setup then failed on VCRUNTIME140_1.dll.
• A process-module inspection identified codex-computer-use-swift.exe as loading that exact DLL.
• Its parent was ChatGPT.exe from the OpenAI.Codex Windows package.
• After terminating that single helper, it automatically respawned within seconds under a new PID and loaded the DLL again.
• Stopping helpers therefore did not provide a lasting recovery.

Troubleshooting already performed:

1. Multiple Codex restarts.
2. Full laptop reboot.
3. Browser-control JavaScript session reset and retry.
4. Separate Windows computer-use runtime initialization attempt.
5. Trivial sandboxed PowerShell test.
6. Read-only unsandboxed PowerShell health check, which succeeded.
7. Targeted termination of the exact Codex node_repl.exe processes.
8. Targeted termination of the computer-use helper holding the DLL.
9. Windows Settings Terminate and Repair attempts.
10. Package re-registration using:

$pkg = Get-AppxPackage -Name OpenAI.Codex
Add-AppxPackage -Register (Join-Path $pkg.InstallLocation 'AppxManifest.xml') -DisableDevelopmentMode -ForceTargetApplicationShutdown -ErrorAction Stop

Windows Repair initially failed with 0x80073D02. The deployment log reported an active app service:
OpenAI.Codex_2p2nqsd0c76g0!App

The subsequent PowerShell package re-registration succeeded.
Windows AppXDeploymentServer event 400 confirmed:
"Deployment Register operation ... finished successfully."

Codex restarted automatically afterward. Both sandboxed commands and browser control were retested and still failed with the runtime file-lock error.

The Codex updater reported "up_to_date".

Relevant local diagnostic files:
%USERPROFILE%.codex.sandbox\sandbox.2026-10-07.log
%USERPROFILE%.codex.sandbox\sandbox.2026-10-08.log
%USERPROFILE%.codex.sandbox\setup_error.json

setup_error.json contained:
{
"code": "helper_unknown_error",
"message": "setup refresh had errors"
}

The evidence identifies a runtime file-sharing conflict during sandbox ACL setup. The underlying cause has not been confirmed.