[Windows] Elevated sandbox blocked by MAXIMUM_ALLOWED on live runtime files; access-mask comparison and verified local recovery #51971

Summary

On this Windows installation, the bundled 0.162.0-alpha.2 sandbox helper rejected ordinary command execution while the desktop app's own runtime processes were running. Restarting the desktop app and rebooting Windows did not resolve it.

This report documents an independently tested installation and links the existing reports: #51634, #51601, #51596, and #51613. If this should be consolidated, please retain the access-mask measurements and end-to-end recovery evidence below.

Environment

• Windows 11 Home (Chinese edition), x64, version 10.0.22621, build 22621 (queried locally).
• Installed MSIX package: OpenAI.Codex 26.1002.7124.0 (package version; not an About-dialog version).
• Bundled CLI: codex-cli 0.162.0-alpha.2.
• Windows sandbox configuration: elevated.
• Runtime directory identifier: cua_node/3dd31cfff853001c.
• Observed and tested October 8, 2026, Asia/Shanghai.

Reproduction and impact

With the desktop app and its Node REPL / Computer Use helpers running, request a minimal ordinary sandboxed PowerShell command, such as:

Write-Output 'sandbox-check-ok'

The requested command does not start:

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

Sanitized log excerpt:

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

After stopping the Node REPL helpers, the failure moved to the runtime's @oai/sky/bin/windows/swift/x64/VCRUNTIME140_1.dll. The desktop app automatically restarted its Computer Use helper. A full computer reboot was verified at 13:03 local time; a new ordinary-command attempt at 13:55 reproduced the same node_repl.exe sharing violation. This was a newly launched process after reboot.

Controlled Win32 access-mask comparison

The same active file was opened with CreateFileW, with all other arguments fixed: FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE (7), OPEN_EXISTING (3), FILE_FLAG_BACKUP_SEMANTICS (0x02000000), and null security/template arguments. Handles were immediately closed; these probes did not write file data or modify ACLs.

Additional probes on node_repl.exe: FILE_WRITE_DATA returned error 32; FILE_APPEND_DATA, WRITE_DAC, and DELETE opens succeeded. No append, delete, or ACL-update operation was performed through these probe handles.

The existing ACL already granted CodexSandboxUsers Modify access. Ordinary permission-table reads and ACL-write handle opens succeeded, so the observed sharing conflict is specifically access-mask dependent.

Source correlation and limits

The source for rust-v0.162.0-alpha.2 requests MAXIMUM_ALLOWED for the non-inheriting/root-only path and contains the exact error context in the log. The installed helper contains the corresponding error strings.

This strongly supports unnecessary data-write access as the trigger on active runtime files. The installed helper was not debugger- or binary-hash-matched to published source, so the implementation-level diagnosis still needs maintainer confirmation. We are not proposing a blind replacement that could change intended directory ACL propagation semantics.

Reversible local recovery and validation

Following the narrowly scoped workaround described in #51613, original DACLs and SHA256 hashes were backed up. A non-inheriting deny ACE for the current user, covering only FILE_WRITE_DATA | FILE_APPEND_DATA (0x6), was added to six runtime files:

• 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. All six file hashes were unchanged. No executable was patched, no runtime directory was deleted, and the sandbox setting remained elevated.

After applying the restrictions, without restarting the app:

• Ordinary command execution in the existing desktop chat succeeded; whoami identified CodexSandboxOffline.
• An explicit elevated read-only sandbox whoami invocation succeeded, exit code 0.
• Create/read/delete of a fresh file inside the allowed workspace succeeded.
• Writing a fresh test file outside the allowed roots returned UnauthorizedAccessException; the normal host user could write to the same location, and the host control file was removed.
• The bundled Node executable ran successfully.
• The actual Node REPL MCP tool initialized and returned output successfully.
• New setup logs reported errors=[] and setup binary completed; setup_error.json was cleared.
• A host-user codex doctor --summary reported the sandbox as healthy and 0 failed checks, with unrelated warnings still present.

This is a measured local workaround, not an official fix or a general recommendation. It may interfere with in-place updates of the restricted runtime files; original DACL backups and a hash-checking restoration script were retained. Network isolation and full Browser/Computer Use operation were not exhaustively retested.

Requested resolution

Please provide a supported helper/desktop fix that avoids incompatible data-write requests for active runtime EXEs/DLLs while preserving ACL update and inheritance semantics. Please identify the fixed release, add regression tests for already-running bundled runtimes, and surface the underlying file and Win32 error in diagnostics.

Only sanitized evidence is included. Usernames, machine names, SIDs, credentials, private paths, raw logs, and chat transcripts are omitted.