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
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
#32477 appears closely related, but this report adds two potentially useful distinctions:
apply_patchis effectively instant / approximately 1–2 seconds. Latency then increases with workspace and writable-root size: approximately 2–3 seconds for 5,111 entries, 4–5 seconds with two additional writable roots, and 45–55 seconds for the full 56.8 GB tree.Therefore these may share the same underlying pre-write stall, but the scaling and trace evidence point specifically toward repeated writable-root/ACL sandbox preparation. If this issue is merged as a duplicate, please preserve the uploaded session and ETW findings.