[Windows] Elevated sandbox setup helper is spawned once per command even when every refresh succeeds (1103 spawns/day, marker valid)

What version of Codex are you using?

codex-cli 0.151.0-alpha.7.2 (npm global), invoked as codex exec from a local
automation controller. ~/.codex/config.toml contains [windows] sandbox = "elevated".

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro). Single interactive user,
member of BUILTIN\Administrators, UAC enabled.

What issue are you seeing?

With [windows] sandbox = "elevated", codex.exe spawns
codex-windows-sandbox-setup.exe once per sandboxed command, not once per
session and not only on marker invalidation. Each spawn requires elevation, so a
working day of agent runs produced 1,103 elevated helper spawns on a single
machine.

The distinguishing fact: every one of those spawns succeeded. All 1,103 logged
errors=[], and 1,046 of them reported processed N write roots with N > 0 — i.e.
the helper re-applied ACLs for a write root that a spawn moments earlier had already
processed successfully.

Marker invalidation is not the driver here. In the same 11,879-line log,
sandbox users missing or incompatible with marker version appears only 15 times
against 1,103 spawns.

Measurements (single day, ~/.codex/.sandbox/sandbox.2026-09-02.log)

Inter-spawn gap distribution (1102 gaps):

Four consecutive spawns for the same cwd, ~90 ms apart, each preceded by a fresh
command-runner launch (paths redacted):

12:35:47.665 codex.exe] setup refresh: spawning …codex-windows-sandbox-setup.exe (cwd=C:\work\<projA>, payload_len=3832)
12:35:47.748 codex.exe] setup refresh: spawning …codex-windows-sandbox-setup.exe (cwd=C:\work\<projA>, payload_len=3832)
12:35:47.837 codex.exe] setup refresh: spawning …codex-windows-sandbox-setup.exe (cwd=C:\work\<projA>, payload_len=3832)
12:35:47.928 codex.exe] setup refresh: spawning …codex-windows-sandbox-setup.exe (cwd=C:\work\<projA>, payload_len=3832)

The repeating unit that precedes each spawn is always the same five lines:

codex.exe] helper copy: reused command-runner source=… destination=…\.sandbox-bin\codex-command-runner-0.151.0-alpha.7.2.exe
codex.exe] helper launch resolution: using copied command-runner path …
codex-command-runner-0.151.0-alpha.7.2.exe] hide users: failed to hide current user profile dir (C:\Users\Default): SetFileAttributesW failed for C:\Users\Default: 5 (access denied)
codex.exe] START: …\.sandbox-bin\codex.exe --codex-run-as-fs-helper
codex.exe] setup refresh: spawning …codex-windows-sandbox-setup.exe (cwd=…, payload_len=3832)

Impact

Each elevated spawn raises a UAC consent prompt on the interactive desktop. At the
observed rates (peak 41 spawns/minute; 630 of 1102 gaps under one second) the machine
becomes effectively unusable for the human at the keyboard — typing into other
applications is repeatedly interrupted for hours. We did not instrument the prompts
themselves, so we report the spawn count as measured and the prompt count only as
"one consent per elevated spawn" by mechanism, not by direct count.

Switching to [windows] sandbox = "unelevated" reduced setup-helper spawns to 0
across three subsequent verification runs (measured on four independent observation
paths over 31 minutes), confirming the elevated path as the source.

codex doctor --json reports checks.sandbox.helpers.status = "ok",
summary = "sandbox configuration is readable" throughout — the diagnostic does not
surface the loop.

Secondary observation

hide users: failed to hide current user profile dir (C:\Users\Default): SetFileAttributesW failed … 5 (access denied) occurs 1094 times, essentially once
per spawn. C:\Users\Default is a system-owned hidden profile template; the runner
appears to attempt an attribute change it will never be permitted to make from a
non-elevated context. It does not abort the run, but it is a per-command failed
privileged operation and may share a root cause with the unconditional refresh.

Relationship to existing reports

Filed separately because the observed mechanism differs from the nearby reports:

• #40627 — elevated setup for one CODEX_HOME rotates a machine-wide secret and
  invalidates other homes' markers. Different here: marker invalidation accounts
  for 15 of 1103 spawns; the other 1088 occur with a valid marker and a successful
  preceding refresh.
• #42213 — elevated sandbox re-provisions unconditionally every session and
  never persists rotated credentials. Different here: the cadence is per command
  (630 gaps under 1 s within single sessions), and every refresh reports success
  rather than leaving stale credentials.
• #36865 — Desktop and npm CLI alternate marker state. Different here: only
  the npm CLI is installed and running; no Desktop or VS Code surface is involved.
• #35407 / #30445 / #40217 — marker written but unreadable/rejected due to ACLs.
  Different here: the marker is readable and accepted; nothing is rejected — the
  refresh simply runs again on the next command.

Full log excerpts and per-cwd breakdowns available on request.

Start by tracing the elevated sandbox path from codex.exe and the command-runner launch to codex-windows-sandbox-setup.exe, using the repeated log sequence and the [windows] sandbox = "elevated" configuration as entry points. Compare refresh decisions with marker validation and inspect the hide-users handling around C:\Users\Default. Done means successful commands no longer spawn the elevated helper per command, while refreshes still occur when required; verify with the reported log events and codex doctor --json.