Native Windows sandbox setup scales poorly with writable-root size, making apply_patch take 45–55 seconds

Summary

Native Windows Codex sandbox performance appears to scale badly with writable-root filesystem entry count. Even a trivial one-line apply_patch becomes extremely slow in a large workspace.

Results

• Empty folder on local NVMe: approximately 1–2 seconds
• 5,111-entry, 464 MB workspace: approximately 2–3 seconds
• Same workspace with two small additional writable roots: approximately 4–5 seconds
• 56.8 GB full-tree workspace: approximately 45–55 seconds

All tested paths are on local NVMe drives, not network shares.

Trace findings

ETW tracing of the full-tree case showed approximately 43.7 seconds spent in four serial sandbox filesystem-helper setup sequences. The actual command runners consumed only approximately 0.47 seconds.

Defender exclusions, drive performance, malformed ACLs, and problematic third-party software were investigated and did not explain the behavior.

Raw enumeration of the 5,340 entries in the smaller configuration takes only approximately 113 ms. This suggests repeated ACL/security-boundary preparation rather than storage I/O.

Expected behavior

Sandbox initialization should be cached or avoid recursively processing unchanged writable trees for every filesystem helper invoked by a single apply_patch operation.

Environment

• Windows 11
• Codex desktop app
• Native Windows workspace-write sandbox
• Local NVMe workspace volumes

Uploaded session

019f618d-eb64-7c52-8617-2bd7c4c6d616