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)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #34529
• #33737

Powered by Codex Action

Same here. Cleaning %TEMP% appears to resolve the slowdown.

Before cleanup:

• %TEMP%: 282,365 files / 79.94 GiB
• Elevated Codex Desktop sandbox refresh: consistently 89–98 seconds
• The delay occurred between read ACL run completed and setup refresh: processed 3 write roots ... errors=[]

After cleanup:

• %TEMP%: 17,002 files / 12.32 GiB
• Sandbox refresh: approximately 40–55 ms
• Minimal PowerShell tool call: 1.1 seconds end-to-end
• Node child_process: working without EPERM
• Warm apply_patch create/delete: 1.6–2.2 seconds

The sandbox configuration remained [windows] sandbox = "elevated".

One caveat: Codex Desktop also auto-updated between the measurements, from MSIX package 26.715.10079.0 to 26.721.3996.0, so this is not a perfectly isolated A/B test. However, the before/after timings and the very large reduction in %TEMP% file count strongly support the writable-root ACL traversal diagnosis described in this issue.

Additional real-world data point from a native Windows machine (Codex CLI 0.146.0):

Observed state

• A long-lived %USERPROFILE%\.codex\cap_sid contained workspace_by_cwd=31 and writable_root_by_path=158 (19,665 bytes).
• A minimal sandboxed cmd.exe /c echo failed with:

SetTokenInformation(TokenDefaultDacl) failed: 1344
(Windows: “No more memory is available to update security information.”)

• The failure reproduced with the legacy workspace-write path and with windows.sandbox="unelevated", so it was not specific to a custom permission profile or network policy.

Reset/rebuild behavior

• I moved cap_sid aside as a backup (no auth files were touched) and retried.
• Codex immediately regenerated 118 writable_root_by_path entries.
• codex-windows-sandbox-setup.exe then used roughly one CPU core continuously for more than six minutes.
• The sandbox log repeatedly appended applied deny ACE to protect %USERPROFILE%\.codex about every 7–8 seconds.
• The parent probe timed out after 64 seconds, but the setup helper remained alive and continued ACL work as an orphan until it was manually stopped.

Product impact

I eventually selected danger-full-access + approval_policy="never" with the unelevated fallback because safe mode imposed multi-minute opaque startup work and repeated authorization friction.

This is an important security UX failure mode: when the safe default is slow or blocks routine work, non-expert users are incentivized to disable the sandbox entirely.

Potential improvements:

1. Bound or compact cap_sid growth and avoid placing every historical path capability SID in a new token DACL.
2. Avoid recursive per-node ACL repair for broad writable roots; prefer root-level inheritable ACEs or incremental repair.
3. Make setup cancellable and ensure timed-out parents terminate their helper.
4. Surface progress and the exact root being processed.
5. Prefer capability-based protections for irreversible operations and credential use, while keeping routine reversible file/network work low-friction.

No SID values, credentials, or private paths are included here.

— Cola1018

Additional real-world confirmation: in my case, two custom uv writable roots were enough to make sandboxed terminal commands appear to run indefinitely, and removing those roots restored normal command execution.

Environment

• Windows 11 x64 (10.0.26200)
• Codex Desktop About version shown in the UI: 26.730.61309
• Installed MSIX package after today's update: OpenAI.Codex_26.730.7989.0
• Previous package recorded in the sandbox log on August 4: OpenAI.Codex_26.727.6591.0
• Sandbox log identified codex-command-runner-0.146.0-alpha.9.2.exe
• Legacy configuration path: sandbox_mode = "workspace-write", approval_policy = "on-request", and [windows] sandbox = "unelevated"

Symptom

The problem started suddenly on August 4 without any change to config.toml. In every permission mode except Full Access, even trivial terminal commands stayed in the UI as running indefinitely. Full Access worked normally.

During affected runs, the sandbox log showed:

START: ...\pwsh.exe ...
setup refresh: spawning ...\codex-windows-sandbox-setup.exe
...
read ACL run completed

but there was no corresponding setup binary completed or command SUCCESS entry.

Custom writable roots and A/B result

My configuration contained:

[sandbox_workspace_write]
network_access = true
writable_roots = [
    "C:\\Users\\<user>\\AppData\\Local\\uv",
    "C:\\Users\\<user>\\AppData\\Roaming\\uv",
]

%TEMP% itself was only about 5,840 files / 4.48 GiB and enumerated in about 1.3 seconds. By contrast, a recursive enumeration that proceeded into the first uv root did not finish within a 60-second diagnostic timeout.

After removing only these two writable_roots entries, terminal commands began succeeding again in the sandboxed/non-Full-Access permission modes. I did not need to reinstall Codex or change PowerShell.

I originally added these roots so Codex could directly launch or run scripts/tools using uv-managed dependencies. I no longer remember which specific tool first required it, so that historical reason is approximate, but the configuration change and recovery result above are confirmed.

This appears consistent with the issue's diagnosis, with large custom writable roots—not only %TEMP%—triggering the expensive ACL refresh path.

Retested on rust-v0.147.0 (be6e8eac02). Not fixed — plus new timing data that refines the attribution from my original report.

Code side: the explicit-ACE gate is still in place in 0.147.0 (acl.rs skips inherited-only ACEs via AceScope::Explicit, reached through path_write_aces_need_refresh → dacl_allow_mask_needs_refresh, which still triggers the full-tree ACL refresh in setup). The only commit touching acl.rs between v0.145.0 and v0.147.0 (a26f219f67, elevated-startup hardening) does not change this trigger.

Four-arm timing for unified_exec::legacy_non_tty_cmd_emits_output (same machine as the original report; debug build, single test, 60s budget):

| Arm | writable-root tree | Result |
|---|---|---|
| A. real %TEMP% | 111,207 files + 53,810 dirs = 165,017 objects, 10 levels deep | timeout 60s (×2 tries) |
| B. empty dir | 0 objects | PASS 7.6s |
| C. synthetic, flat | ~200,200 objects, 1 level deep | PASS 43.5s |
| D. synthetic, dir-dense | ~40,200 objects, 2 levels deep | PASS 30.8s |

Two takeaways:

1. The cost is a continuous curve in tree size (0 → 7.6s, 40k → 30.8s, 200k → 43.5s), not a threshold — any sufficiently large writable root will eventually cross whatever timeout sits above the setup path.
2. Object count alone underestimates the real cost. The real %TEMP% (165k objects) times out while a larger flat synthetic tree (200k objects) passes. Real trees carry per-object structural multipliers (depth, in-use handles, restricted subtrees). Correcting my own earlier framing ("~219k files"): the determining factor is total tree cost = scale × structure, so repro attempts built on flat synthetic trees will significantly underestimate what real machines hit.

The workaround from the original report still holds on 0.147.0: pointing TMP/TEMP at a clean directory makes the same test pass in seconds.