[Windows] Elevated sandbox refresh blocks command execution: MAXIMUM_ALLOWED causes error 32 on active runtime files #51613

Summary

After the October 7 update, the Windows app repeatedly failed to complete Windows setup and blocked sandboxed command execution. Initially I also could not change the chat's permission mode normally. A local recovery restored the UI, but actual elevated sandbox execution still failed, including after rebooting Windows.

This report adds controlled Win32 access-mask measurements and a tested, reversible local workaround to the existing reports. It is not a claim that this bug first appeared on October 7 or affects every installation.

Environment

• Windows 11 Home, 24H2, build 26100.4946, x64.
• Desktop package version reported by codex doctor: 26.1002.6548.0.
• App update checker reported 26.1002.51308, build 13417, production channel, up to date.
• Bundled core: codex-cli 0.162.0-alpha.2.
• Windows sandbox setting: elevated.
• Report and tests: October 7, 2026, Asia/Shanghai.
• Runtime: cua_node/2c9e75c4e9c71beb.

Impact and frustration

I appreciate the new features and the pace of development. However, continuing to ship new features while recurring Windows sandbox failures interrupt basic development work is unacceptable for a development tool. Reliability is a core feature too.

Users should not have to spend hours collecting logs, restarting processes, rebooting Windows, and manually changing runtime file permissions just to restore command execution after an update. Please give these existing reliability problems, regression tests, and supported recovery procedures the same priority as new capabilities.

The related reports below have different details; I am not claiming they all have an identical root cause. They do show a recurring Windows sandbox reliability problem.

Reproduction on this installation

1. Open Codex on Windows with its runtime processes running.
2. Select the elevated sandbox.
3. Run a harmless command through the bundled CLI, with an existing directory as the working directory:

& "<bundled-core>\codex.exe" sandbox -C "<test-directory>" -P ':read-only' -c 'windows.sandbox="elevated"' 'C:\Windows\System32\whoami.exe'

4. The command fails before it starts:

windows sandbox failed: helper_unknown_error: setup refresh had errors

5. The new sandbox log identifies the fatal error:

runtime read/execute validation failed:
validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime>\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

The same error also occurred on loaded Microsoft runtime DLLs, including VCRUNTIME140_1.dll.

Rebooting Windows did not resolve this. The reboot was verified at 15:44, and a new attempt at 15:47 failed with the same error. An earlier, separate helper_sandbox_lock_failed on .sandbox-bin was recovered first; it should not be conflated with this subsequent sharing violation.

Controlled diagnostic evidence

The sandbox group already had ReadAndExecute access to node_repl.exe. Using CreateFileW on the same active file, with identical sharing flags (FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE), OPEN_EXISTING, and FILE_FLAG_BACKUP_SEMANTICS:

The same comparison produced the same results on the loaded VCRUNTIME140_1.dll.

I then temporarily added a non-inheriting deny ACE for the current user covering only FILE_WRITE_DATA | FILE_APPEND_DATA (mask 0x6) on node_repl.exe. The MAXIMUM_ALLOWED open immediately succeeded. The original ACL was restored after this initial comparison.

Source evidence and suspected cause

The published source for the matching core version contains the corresponding open:

acl.rs at rust-v0.162.0-alpha.2, lines 548–556

ensure_allow_mask_aces_with_inheritance_impl uses access_mode(MAXIMUM_ALLOWED) for the root-only path and the exact error context shown in the log. Runtime validation calls the read/execute grant path for files.

The measurements strongly support unnecessary data-write access causing the sharing violation. I have not debugger- or hash-matched the installed helper binary to the published source, so the proposed source-level diagnosis still needs maintainer confirmation.

Tested local recovery

After backing up the original security descriptors, I applied the same narrow, non-inheriting current-user deny ACE to six runtime files that produced sharing conflicts:

• node_repl.exe
• node.exe
• codex-computer-use-swift.exe
• VCRUNTIME140_1.dll
• VCRUNTIME140.dll
• MSVCP140.dll

Read, execute, and ACL-management access were retained; file contents were not modified. The configuration remained elevated.

Afterwards:

• whoami ran successfully under <MACHINE>\CodexSandboxOffline.
• Creating, reading, and deleting a file inside the allowed working directory succeeded.
• Writing a fresh test file outside that directory was denied; the host process could write to the same location.
• The bundled Node runtime executed inside the elevated sandbox.
• Direct external TCP access that worked from the host returned EACCES inside the sandbox. Local loopback remained reachable; this is not a claim of complete network isolation.
• codex doctor reported sandbox.helpers.status=ok, backend=elevated, and provisioning=complete.

This is a local workaround, not an upstream fix or a general recommendation. It can interfere with in-place runtime file updates, and replacement runtimes may require reapplication. Original ACL backups and a rollback script were preserved.

Requested resolution

Please investigate using the minimum necessary handle access for live runtime files: inspect ACLs with read-security access and request ACL-write access only when necessary, while preserving deny entries, non-inheriting update semantics, and sandbox security checks.

Please add regression coverage for already-running EXEs and loaded DLLs, provide a supported recovery that preserves projects and chat history, and show the actual file and Win32 error in the setup UI.

Related reports: #51601, #51596, #50520, and #49025. This report adds the controlled access-mask comparison and measured recovery; other reporters' observations are not attributed to my machine.

Personal usernames, device names, SIDs, credentials, sandbox secrets, private project data, and full chat transcripts are omitted.