Windows Desktop elevated sandbox hangs after ACL setup and leaks setup helpers; unelevated works (0.145.0-alpha.18)

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

• #32855

Powered by Codex Action

Additional Windows observation showing the sandbox/Full Access differential:

• Codex/ChatGPT desktop: 26.715.10079.0
• Windows 11 Home 25H2, build 26200.8894, x64
• In workspace-write sandbox mode, ordinary process/system queries such as Get-Process and tasklist repeatedly remained stuck and had to be terminated.
• The same read-only diagnostics completed normally in Full Access/out-of-sandbox mode, generally within a few seconds.
• Simple shell output still worked in sandbox mode, so the failure was concentrated around process/system inspection rather than every command.
• Retrying sandboxed diagnostics was stopped to avoid accumulating leaked setup helpers.
• At the time of the final process check, the count of codex-windows-sandbox-setup.exe was 0. This occurrence therefore confirms the hang and Full Access workaround, but not a persistent helper leak in that particular sample.

The practical workaround remains switching affected tasks to Full Access/no-sandbox and avoiding repeated sandbox retries. Full Access is only appropriate for trusted workspaces.

Additional reproduction: App-session write-root accumulation predicts leaked Windows sandbox helpers

I can reproduce the helper leak described here on a newer Codex App and CLI. The newer evidence
suggests that the elevated sandbox symptom is driven by the write-root payload growing inside a
long-lived App session, rather than by PowerShell or the workspace alone.

Environment

• Codex App: 26.803.5235.0 (OpenAI.Codex, Microsoft Store package)
• Codex CLI: 0.147.0
• Windows: Windows 11 x64, build 10.0.26200
• Native Windows workspace, not WSL
• Elevated Windows sandbox through a named permissions profile
• Hooks disabled during this reproduction

New reproduction evidence

The App process started after the local permissions profile had been narrowed, so this was not a
stale pre-fix App process. By 22:40 local time, 38
codex-windows-sandbox-setup.exe processes were present; 31 were children of the live bundled App
codex.exe process.

Two setup attempts from the same packaged App directory occurred within one second:

| Attempt | Helper payload length | Result |
| --- | ---: | --- |
| 21:42:02.206 | 7,988 bytes | Completed; log reached processed 1 write roots and setup binary completed |
| 21:42:02.578 | 10,720 bytes | Stalled after the ACL-read phase; never logged setup binary completed |

The payload emitted by the same long-lived App parent grew monotonically:

7,628 -> 9,964 -> 10,664 -> 10,832 bytes

Stalls began when the payload crossed roughly 9.9 KB. In the day-long sample, payloads at or below
8,116 bytes normally completed, while payloads at or above 9,956 bytes stalled. This is an observed
boundary on one machine, not a proposed universal threshold.

The native CLI reading the same effective config emitted 2,512-2,708-byte payloads with 6-7 write
roots and completed sandbox refresh in roughly 30 ms. Multiple repo-rooted CLI tool runs completed
without leaking a helper.

At 23:04, before a separate blind-agent comparison, 16 setup helpers were already present. The count
remained 16 across three read-only child probes. At 23:14 all 16 were CPU-active during a two-second
sample; 12 were parented to the live App process, four had no live parent, and their combined working
set was about 291.5 MB. The child probes completed and left no processes, so they did not create or
worsen this backlog.

Why this looks App-specific

• The accumulating helpers use the sandbox binary bundled with the Store App.
• Most leaking helpers are direct children of the App's bundled codex.exe / app-server.
• A fresh App session starts with smaller payloads and works, then degrades as its per-session

payload grows.

• Repo-rooted native CLI sessions using the same profile remain small and complete normally.
• Narrowing a previously broad local write grant reduced the initial payload but did not prevent

the App-session payload from growing again.

The process working directory itself is not the differentiator: the same App directory produced
both the completed and stalled attempts above. Earlier home-rooted launches worsened the payload,
but they were a proxy for a larger write-root set, not the complete cause.

Expected behavior

1. The App should rebuild or deduplicate the effective write-root set instead of accumulating roots

across a long-lived session.

1. One tool request should not leave a CPU-spinning setup helper after the parent times out.
2. Setup refresh should be single-flight per App parent, with orphan cleanup on timeout.
3. If the root set is too large, Codex should fail promptly with the root count/payload size and an

actionable message rather than spawning another helper.

1. App acceptance should include a long-session accumulation test, not only a per-attempt completion

ratio.

Suggested regression test

• Keep one Codex App process open.
• Exercise 50-100 tool calls across several exact repo workspaces.
• Assert that the effective write-root count and serialized payload do not grow monotonically after

a workspace is released.

• Assert that every setup helper exits within a bounded interval and that the live helper count

returns to zero.

• Repeat with a named permissions profile containing :workspace_roots plus several explicit repo

grants.

Sanitized sandbox-log excerpts and a payload/root-count timeline can be supplied if helpful.