Windows sandbox: bundled 0.162.0-alpha.2 fails with sharing violation; separate stable 0.160.1 starts #51596

Environment

• Windows x64; exact Windows build and subscription tier not collected.
• Desktop package recorded in setup log: OpenAI.Codex_26.1002.6548.0_x64__2p2nqsd0c76g0.
• Bundled CLI, verified with --version: codex-cli 0.162.0-alpha.2.
• Separate official portable Windows CLI: codex-cli 0.160.1.
• Observed October 5–7, 2026; latest comparison October 7, 07:57 Europe/Berlin (UTC+02).

Actual behavior and reproduction

On the affected existing installation, ask the desktop chat or its programming subagent to run a normal PowerShell Get-Location. Execution fails before the command starts:

exec-server rejected request (-32603):
helper_unknown_error: setup refresh had errors

User-provided sandbox logs identify the fatal runtime-validation failure:

runtime read/execute validation failed
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: exited with status ExitStatus(ExitStatus(1))

The target was first VCRUNTIME140_1.dll under the bundled cua_node/sky Swift runtime, then node_repl.exe under the same runtime. A separate profile-directory error was marked continuing setup; executable validation was in the fatal errors list.

Repeated app updates and reported restarts/reboots did not restore this chat. A single targeted stop of codex-computer-use-swift did not restore it; a later instance was observed. No kill loop was performed. An earlier, distinct helper_sandbox_lock_failed on .sandbox-bin temporarily responded to a backed-up, directory-only SYSTEM-WDAC addition; setup removed that right again. This was not a lasting fix for the current sharing violation. No recursive ACL reset, owner change, runtime replacement or sandbox disabling was performed.

Separate stable comparison

The user ran the official portable 0.160.1 package:

codex.exe sandbox --permission-profile ':read-only' --include-managed-config --cd <test-directory> -- powershell.exe -NoProfile -Command Get-Location

Output: C:\; exit code: 0. Immediately afterwards, one normal probe each in the original chat and subagent still failed before execution. These are different execution contexts, not a controlled identical A/B test. No Git/compiler/engine readiness or permanent desktop repair is inferred. A separate programming chat has since resumed work according to the user; its runtime was not independently verified here.

Source hypothesis, not proven root cause

The exact 0.162.0-alpha.2 acl.rs contains a root-only open using MAXIMUM_ALLOWED before the DACL/no-op check and the matching error context. That additional branch is absent from the checked 0.160.1 acl.rs. Please investigate access requirements for live runtime files. The installed setup-helper binary has not been hash/debugger-matched to that source.

Impact and requested outcome

Basic commands are blocked, while repeated manual log collection and unsuccessful recovery consume substantial user time and chat context. Exact token/cost totals have not been measured. The user considers this burden unacceptable for routine tasks.

Please provide a supported desktop fix or stable-runtime route, surface the actual file/Win32 failure directly, and offer a single sanitized diagnostic export instead of repeated manual diagnosis and generic restart advice.

Related report: #51590. This report adds the separate stable comparison; the other reporter's measurements are not attributed to this installation. No clean-install reproduction established.

Personal paths, account identifiers, private project links, credentials and full chat transcripts are omitted.