srt-win acl stamp is deterministically ~30s/path when the parent directory is a Windows system-managed directory (user profile root, %TEMP%) — breaks Windows sandbox initialize()

[Julyscheme]

Environment

• OS: Windows 11 Pro, build 26200 (24H2+)
• sandbox-runtime 0.0.67 (vendored srt-win 0.0.1, x64)
• Node host calling initialize() with denyWrite including a direct child of the user profile root (e.g. C:\Users<user>.claude)

Summary
srt-win acl stamp takes 27-33s per path — deterministically, every run — when the parent of a deny target is a Windows system-managed directory: the user profile root (C:\Users<user>) or a Known Folder such as %LOCALAPPDATA%\Temp. The same operation on ordinary directories (D:\ root, C:\nvm4w, C:\ProgramData, a user-created directory inside %TEMP%) completes in <0.3s. Because the CLI's denyWrite list always contains ~/.claude (a direct child of the profile root), Windows sandbox initialize() reliably exceeds the 60s stamp timeout and fails closed, making the Windows sandbox unusable when enabled.

Measured timings (srt-win acl stamp, single deny target, holder-pid = test process)

• Parent = C:\Users<user>\AppData\Local\Temp (Known Folder): 32.7s, 27.1s (repeat) [stamp]; restore also ~24-28s
• Parent = a fresh directory created under %TEMP% (same volume, same inherited DACL shape): 0.25s
• Parent = D:\ root / C:\nvm4w / C:\ProgramData / user dirs: 0.25-0.7s

Reproduction

1. Create C:\Users<user>\AppData\Local\Temp\probe-child (a fresh dir; parent = %TEMP%)
2. Run: echo {"denyWrite":["C:\Users\\AppData\Local\Temp\probe-child"]} | srt-win acl stamp --holder-pid --sandbox-user-sid
3. Observe ~30s runtime (timeoutMs in the JS helper is 60s).
4. Control: same command against a dir whose parent is a fresh dir under D:\ — ~0.3s.

Notes on what was ruled out (all verified on the same machine, AV (HuoRong + Windows Defender real-time) fully disabled):

• NOT parent DACL size/complexity: a directory with an injected package SID ACE (S-1-15-3-65536-...), or with a mixed explicit+inherited DACL, on D:\ is still fast.
• NOT the presence of a sandbox-user DENY ACE on the parent: a fresh dir under %TEMP% inherits the same srt-sandbox DENY(FILE_DELETE_CHILD) ACE as %TEMP% itself and is still fast.
• NOT directory contents: D:\ root has far more entries and is fast.
• Deterministic (repeats at 27-33s), not a first-write effect.

Hypothesis (to be confirmed upstream/Microsoft)
srt-win acl stamp writes, for each deny target, a (D;OICI;FILE_DELETE_CHILD;;;) ACE on the target's parent via SetNamedSecurityInfoW. When the parent is a system-managed user-profile / Known-Folder directory, the OS applies extra handling (profile ACL guarding / Known-Folder DACL maintenance) that makes the write take ~30s. This is outside srt-win's control.

Suggested fix directions

1. Skip the parent FILE_DELETE_CHILD ACE when the sandbox user has no write access to the parent anyway (user-private dirs) — the ACE is then pure defense-in-depth with zero semantic loss; keeps it for world-writable parents (e.g. %TEMP%).
2. Batch: when multiple deny targets share one parent, write the parent ACE once instead of per-target.
3. If a fast path is needed for system-managed parents, consider documenting/measuring the OS-level behavior and possibly using a different primitive than full SD rewrite.