Why

When an organization requires the elevated Windows sandbox, Codex launches an elevated helper to provision users, configure firewall and ACL rules, and lock persistent sandbox directories.

We observed that closing the helper after setup started could leave the machine partially initialized while the TUI still announced Sandbox ready. Model-only turns continued to work, but the first shell command retried setup and failed with Windows cancellation error 1223.

This was not an enforcement bypass; command execution continued to fail closed. The issue was a false readiness signal: setup_marker.json was written during user provisioning, before the remaining setup stages had completed.

What

Treat setup_marker.json as the commit record for Windows sandbox setup:

1. Before full or provisioning setup begins, remove the existing marker and create the final marker path with a protected ACL.
2. Keep the marker empty and therefore invalid while setup is in progress. Sandbox users cannot read, modify, or replace it.
3. Run every synchronous setup stage.
4. After setup succeeds, write the valid marker contents without changing its ACL.
5. After the helper exits successfully, verify the existing readiness check before enabling the sandbox.

If setup is canceled or fails, the marker remains invalid and Codex reports setup as incomplete instead of announcing readiness.

Refresh-only and read-ACL-only helper runs continue to leave the marker untouched. The setup version remains 5 to avoid forcing all existing Windows users through elevated setup again.

Verification

• Added coverage confirming sandbox users cannot read or modify the setup marker after elevated setup.
• Added coverage confirming a successful helper exit without complete setup artifacts is rejected.
• Ran just test -p codex-windows-sandbox.