0.145.0: Windows sandbox setup re-runs ACL repair when writable-root rights are inherited-only; large %TEMP% makes spawn hang >60s (windows-sandbox tests deterministically time out)

Start with acl.rs and the setup_main logic in the codex-windows-sandbox-setup binary, then trace spawn_windows_sandbox_session_legacy. Reproduce with the named cargo nextest filter using a large or empty TEMP directory, and inspect the legacy_non_tty_cmd_emits_output test and its siblings. Done means inherited-only writable-root rights do not trigger an unbounded tree repair, and sandbox spawn completes or reports a bounded error.

Summary

At rust-v0.145.0, the in-repo test codex-windows-sandbox unified_exec::tests::legacy_non_tty_cmd_emits_output (and siblings sharing the legacy spawn path) deterministically times out (nextest 60s terminate) on a Windows dev machine. The same test passed in isolation at rust-v0.144.6 on the same machine three days earlier.

Root cause appears to be the new explicit-ACE verification in sandbox setup: writable roots whose rights come only from inherited ACEs are now treated as needing repair, and the repair propagates ACLs across the entire writable-root tree. With the user''s %TEMP% (a default writable root) containing ~219k files, that repair exceeds 60s, and the spawn path awaits setup with no timeout.

Deterministic reproduction

# Windows 11, non-elevated, developer mode on
$env:__COMPAT_LAYER = "RunAsInvoker"
cargo nextest run -E "test(legacy_non_tty_cmd_emits_output)" --no-capture

• 2 runs x 2 tries: 4/4 timed out at exactly 60s on an idle machine (CPU ~2%).
• Test checkpoint output: cmd codex_home=... prints, but cmd spawn returned never appears → the hang is inside spawn_windows_sandbox_session_legacy(...), before process creation; the test''s own 5s command / 10s collect timeouts are never reached because spawn itself blocks.
• Leftover sandbox log in the temp CODEX_HOME contains only the START: C:\Windows\System32\cmd.exe /c echo LEGACY-NONTTY-CMD line; cap_sid was written → hang occurs after capability-SID creation, during setup.

Control experiment

Same test with TMP/TEMP redirected to a freshly created empty directory: PASS in 11.7s (all checkpoints fire).

The user %TEMP% on this machine: 218,980 files / 6.9 GB — realistic for a long-lived dev box.

Code-level analysis

• acl.rs in 0.145.0 adds AceScope::Explicit / path_mask_has_explicit_allow_ace with the rationale: "SET_ACCESS cannot replace an ACE inherited from an ancestor, so it cannot make an explicit-only repair converge when that inherited ACE contains stale rights."
• setup_main (the codex-windows-sandbox-setup binary) uses path_mask_has_explicit_allow_ace to decide whether a writable root needs repair. Roots whose rights are inherited-only (the normal state of %TEMP% and most user directories) now always trigger repair.
• Repair cost scales with tree size (see also #33158). For fresh CODEX_HOMEs (new capability SIDs — every test run, and every new install/home), repair re-triggers from scratch.
• spawn_windows_sandbox_session_legacy awaits setup with no timeout, so callers observe an indefinite hang rather than an error.

Impact

• Test suite: codex-windows-sandbox legacy tests fail deterministically on dev machines with real-world %TEMP% sizes (they pass on clean CI temp dirs), which makes local baseline comparison noisy for anyone developing on Windows.
• Product: the first sandboxed exec for a given CODEX_HOME on such machines stalls for minutes with no feedback. This looks like the same family as user reports #32477 / #33158, but 0.145.0''s inherited-ACE handling re-triggers the cost even where effective rights were already sufficient.

Environment

• Windows 11 Pro for Workstations 10.0.26200, non-elevated user, developer mode on
• rust-v0.145.0 tag, debug build, cargo-nextest default profile, __COMPAT_LAYER=RunAsInvoker
• Passed at rust-v0.144.6 in the same environment (isolated run, 2026-07-19)

Possible directions

• Accept inherited allow ACEs when the effective rights already match (pre-0.145.0 behavior), reserving explicit repair for genuinely stale/insufficient rights;
• Or scope the repair to the root directory with inheritable ACEs instead of per-node propagation;
• Or make setup asynchronous/bounded with a clear log line, and add a timeout to the spawn path so failures surface as errors instead of indefinite hangs.

Related: #33158 (setup scales poorly with writable-root size), #32477 (user-facing 40-60s stalls on 0.144.1).