Windows elevated sandbox: root-only ACL grants open loaded runtime files for write (os error 32), so every setup refresh fails #51623

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

26.1002.6548.0 (bundled codex-cli 0.162.0-alpha.2). The issue started right after the auto-update from 26.930.

What subscription do you have?

ChatGPT account

What platform is your computer?

Windows 11 Pro, build 26200, x64. [windows] sandbox = "elevated".

What issue are you seeing?

Related: #51590 (same symptom). This issue adds a root cause in windows-sandbox-rs and a tested fix.

Every sandboxed local command fails before process creation:

exec_command failed: CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }

The sandbox log shows:

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

The same error appears for node.exe and node_repl.exe in the runtime. It also appears, non-fatally, for the user profile root (failed to grant non-inheriting read-attributes ACE on user profile).

Root cause. ensure_allow_mask_aces_with_inheritance_impl in codex-rs/windows-sandbox-rs/src/acl.rs opens root-only (non-inheriting) targets with MAXIMUM_ALLOWED before it checks whether an update is needed. This came in with #49690. For the file owner, that handle includes write access. Windows rejects write access to an image that a running process has loaded, so the open fails with ERROR_SHARING_VIOLATION. The app's own computer-use helpers (codex-computer-use-swift.exe, node.exe, node_repl.exe) keep these runtime files loaded, and the app restarts the Swift helper within milliseconds of a kill. Restarting the app does not help.

The ACL was already correct. The sandbox group already had inherited access, so no ACE needed to be written. With the app fully closed, the same setup refresh succeeds with errors=[] and leaves every runtime ACL unchanged.

A direct CreateFileW check against the loaded DLL:

What steps can reproduce the bug?

1. Use Codex App 26.1002 on Windows with the elevated sandbox, with computer use enabled so the runtime helpers are running.
2. Run any command in a sandboxed permission mode, or run codex sandbox -P :workspace -- cmd /c dir with the bundled CLI while the app is open.
3. The command fails with helper_unknown_error: setup refresh had errors.

What is the expected behavior?

When the ACL is already correct, setup refresh should not need write access to runtime files, and commands should run.

Additional information

Proposed fix (tested): erson@2bd3cd5

• Read the DACL through fetch_dacl_handle (a READ_CONTROL handle) for both root-only and inheriting grants.
• Open the MAXIMUM_ALLOWED handle only when at least one ACE must be written. That keeps the no-propagation behavior from Preserve PowerShell relative paths in the elevated Windows sandbox #49690.
• Add the regression test noninheriting_grant_skips_open_for_write_when_ace_is_present. It holds a read-only-sharing handle on the target, like a loaded image, and checks that an up-to-date root-only grant succeeds.

I tried to open a pull request, but the repository does not accept external PRs, so the commit is linked here instead.

Testing. The computer-use helper held the runtime files during all end-to-end runs. The baseline was the released 0.162.0-alpha.2.

• Unit: the new test fails on main with the same open ACL target for root-only update … (os error 32) error and passes with the fix. noninheriting_read_attributes_preserve_unprotected_child_dacl still passes. Across cargo test -p codex-windows-sandbox, the set of failing tests is identical with and without the fix, apart from the new test. The remaining failures on this machine are environment-specific (junction and live-sandbox tests). Clippy is clean.
• codex sandbox -P :workspace: cmd read and write, powershell.exe write and read, pwsh.exe write and read. Baseline: 4/4 fail with setup refresh had errors. Fix: 4/4 succeed, and setup refresh logs errors=[].
• Agent turn: codex exec -s workspace-write -c windows.sandbox="elevated" -c features.prefer_mxc=false, with the same model on both builds. Baseline: the error above, and no file is written. Fix: setup refresh logs errors=[], and the agent writes and reads back a probe file.

Limits.

• The agent-turn run used the released codex-code-mode-host.exe next to a locally built codex.exe, because the V8 prebuilt archive could not be downloaded.
• In that run, the first command waited about two minutes and exited 1 on both builds without reaching sandbox setup. It appears unrelated.
• The app later switched to the MXC backend (prefer_mxc). MXC does not use this code path, so I could not test the fix inside the app. Under MXC, the same test commands either hung or returned empty output. That may be a separate issue.