Windows sandbox refresh fails with helper_sandbox_lock_failed after SetNamedSecurityInfoW(ERROR_ACCESS_DENIED) on existing .sandbox-bin

Additional investigation completed since opening this issue.

I performed a read-only investigation without modifying Windows permissions, ownership, ACLs, Codex files, repositories, or project state.

Key observations:

• Initial Windows sandbox provisioning succeeds.
• Later sandbox refreshes consistently fail before repository initialization.
• The failure occurs on the existing .sandbox-bin directory.
• The recorded failure is:

helper_sandbox_lock_failed

SetNamedSecurityInfoW sandbox dir failed: 5

The investigation includes:

• preserved logs
• environment validation
• ACL and ownership inspection
• sandbox identity verification
• binary signature verification
• SHA-256 verification
• evidence matrix
• technical timeline
• root-cause summary
• regression test proposal

Current engineering hypothesis (clearly identified as a hypothesis):

The refresh path appears to unconditionally attempt a DACL update on .sandbox-bin during later launches instead of recognizing an already-valid security descriptor. This behavior is consistent with an idempotence issue combined with an ownership lifecycle mismatch, although confirmation would require maintainer-side symbols or a captured failing helper token.

If useful, I can provide the complete investigation package or run additional controlled diagnostics requested by the Codex engineering team.

Same failure with an empty, freshly-created .sandbox-bin — ownership is not the cause

We hit this on a centrally-managed deployment (Windows 11 25H2, x64) and ran a controlled experiment that I think rules out the idempotency/ownership theory.

Setup: codex sandbox setup --elevated --user <DOMAIN>\<user> --codex-home C:\Users\<user>\.codex, launched by our management agent as NT AUTHORITY\SYSTEM.

Versions: fails on OpenAI.Codex 26.818.8289.0 (codex-cli 0.149.0-alpha.4.3) and on 26.818.5229.0 / 26.818.5345.0 (0.149.0-alpha.4.1). Works on 26.814.5167.0 (codex-cli 0.148.0-alpha.15), same script, same machines, same SYSTEM context.

We scripted three attempts, re-running the setup after each:

1. As-is → helper_sandbox_lock_failed: lock sandbox bin dir ...\.sandbox-bin failed: SetSecurityInfo sandbox dir failed: 5
2. After icacls <dir> /setowner <DOMAIN>\<user> /T /C /Q → owner was already the target user (not CodexSandboxOffline/Online), so this was a no-op. Same failure.
3. After renaming .sandbox-bin out of the way, confirmed gone, so the helper creates it from scratch → same failure.

So the helper cannot apply the DACL to a directory it just created itself. That seems to rule out stale ownership from a previous provisioning run.

The pre-existing directory (from a successful run in July) was empty and carried these explicit ACEs, which may or may not be relevant:

<MACHINE>\CodexSandboxUsers:(OI)(CI)(RX)
NT AUTHORITY\SYSTEM:(OI)(CI)(M)
BUILTIN\Administrators:(OI)(CI)(M)
<DOMAIN>\<user>:(OI)(CI)(M)

Note SYSTEM gets Modify, not Full Control, on the explicit ACEs — and SetSecurityInfo needs WRITE_DAC. But that alone doesn't explain case 3.

Side effect worth flagging: when it fails, the run still creates the CodexSandboxOffline/CodexSandboxOnline local accounts, hides them under SpecialAccounts\UserList, and adds the three codex_sandbox_* firewall rules. It also leaves setup_marker.json as a 0-byte file. A provisioning script that checks "marker exists" will report success on a machine that has no working sandbox — and our EDR flags the hidden-account registry write, so the endpoint gets the security alert without getting the sandbox.

Happy to provide more detail if useful.

Additional reproduction evidence: this is still reproducible with Codex CLI 0.149.1.

Environment:

• Windows 11 Professional, build 26200, x64
• Codex CLI 0.149.1
• CODEX_HOME=D:\Governance\08-Runtime\Agent-Runtime-State\Codex
• Filesystem sandbox: unrestricted

codex doctor reports:

• “elevated Windows sandbox provisioning recorded a structured failure”
• sandbox provisioning: failed
• error code: helper_sandbox_lock_failed

I also ran the documented command from a real elevated Administrator PowerShell:

codex sandbox setup --elevated --current-user --codex-home <authoritative-home>

It still returns Win32 error 5 (Access Denied) while processing the trusted runner directory at the SetSecurityInfo / SetNamedSecurityInfoW stage.

Additional observations:

• The local CodexSandboxUsers group exists, but provisioning did not complete the ACL setup for the new CODEX_HOME.
• General icacls ACL operations on the same directory succeed.
• No old cap_sid was copied.
• The core Codex runtime is otherwise healthy: the new CODEX_HOME, SQLite databases, and authentication all report healthy.

This is a 0.149.1 reproduction supplement to #36475. It is intended to report the observed behavior only; I am not asserting an unverified implementation-level root cause. No tokens, API keys, auth files, MCP OAuth material, or configuration contents are included.

Independent reproduction: failure also occurs with .sandbox-bin absent before elevated setup

I can independently reproduce this failure on another Windows machine.

Environment:

• Windows 11 Professional Workstation, build 26200, x64
• Codex CLI 0.149.0 (windows-x86_64)
• PowerShell 7.6.5
• default CODEX_HOME under C:\Users\<user>\.codex
• elevated Windows sandbox

The relevant failure is:

helper_sandbox_lock_failed: lock sandbox bin dir C:\Users\<user>\.codex\.sandbox-bin failed: SetSecurityInfo sandbox dir failed: 5

I also tested with the previous .sandbox-bin moved completely out of the way.

Test sequence:

1. Inspected the existing .sandbox-bin ACL/ownership.
2. Renamed the existing .sandbox-bin to a backup name.
3. Confirmed that .sandbox-bin itself no longer existed.
4. Ran:

codex sandbox setup --elevated --current-user

1. The setup still failed immediately with:

Error: helper_sandbox_lock_failed: lock sandbox bin dir C:\Users\<user>\.codex\.sandbox-bin failed: SetSecurityInfo sandbox dir failed: 5

codex doctor --all then reported:

Codex Doctor v0.149.0 · windows-x86_64

sandbox  elevated Windows sandbox provisioning recorded a structured failure

For this reproduction I did not manually change the ACL or ownership of .sandbox-bin; the only state change was moving the previous directory aside before rerunning elevated setup.

I also performed a separate Microsoft Defender investigation. No Codex-related Defender detection, quarantine/remediation, ASR action, or Controlled Folder Access action was recorded around the failures. Controlled Folder Access was disabled, and no effective ASR rules were identified that would explain the failure.

This seems especially relevant because the failure does not require the previous .sandbox-bin directory to still be present when elevated setup is started.

This independently supports the observation in the other reproduction above that stale .sandbox-bin ownership alone does not appear sufficient to explain the failure.

I am not making an implementation-level root-cause claim here; this is intended as additional reproduction evidence. I can provide the corresponding ACL output and sandbox log excerpts if useful.