Windows sandbox: elevated setup for one CODEX_HOME rotates a machine-wide secret and UAC-storms every other home

Summary

The Windows restricted-token sandbox stores per-home setup state
($CODEX_HOME/.sandbox/setup_marker.json) but manages MACHINE-WIDE
sandbox accounts (CodexSandboxOffline / CodexSandboxOnline). An
elevated sandbox setup run for one CODEX_HOME rotates a machine-wide
secret and records it only in that home's marker, invalidating every
other home's marker. Any subsequent run under a different CODEX_HOME
logs sandbox setup required: sandbox users missing or incompatible with marker version and attempts elevated re-setup — which raises a UAC
consent prompt PER COMMAND for non-interactive exec runs. Two concurrent
codex exec sessions under different homes produce a continuous UAC
prompt storm on the user's desktop, and validity ping-pongs to whichever
home ran elevated setup last.

Reproduction (measured)

1. Three homes: ~/.codex, ~/.codex-overflow, ~/.codex-overflow2,
   each authenticated, same Windows user. Markers initially valid.
2. Run an elevated codex sandbox cmd /c exit 0 with
   CODEX_HOME=~/.codex-overflow2 (its first-time setup).
   → ~/.codex-overflow2/.sandbox/setup_marker.json created.
3. Start codex exec ... -s workspace-write runs under ~/.codex and
   ~/.codex-overflow.
   → both homes log sandbox setup required: sandbox users missing or incompatible with marker version on every command; each attempt
   raises a UAC prompt (observed ~9 s cadence; 30+ prompts in minutes).
4. Elevated re-setup per home (writing that home's marker with the new
   secret) ends its storm; refined measurement an hour later: once every
   home's marker holds the CURRENT secret, a marker-version mismatch
   self-heals silently and unelevated on the next run (marker rewritten,
   no prompt). The storm flavor occurs when a home's marker holds a
   ROTATED-AWAY secret: the unelevated refresh exits -1
   (ExitStatus(4294967295)) and the run escalates to a UAC consent per
   command.
5. Copying a valid setup_marker.json byte-identical to a sibling home
   does NOT directly revalidate it (sandbox setup required still
   logged once), but the next run self-heals it silently — consistent
   with per-home fields inside the marker plus a shared secret.

Log evidence (representative lines, ~/.codex-overflow/.sandbox/sandbox.2026-08-24.log):

[... codex.exe] sandbox setup required: sandbox users missing or incompatible with marker version
[...] read-acl-only mode: applying read ACLs
[...] read ACL run completed
[... codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(4294967295))

Healthy sibling in the same minutes:

[...] granting write ACE to C:\dev\wt\<worktree> for sandbox group and capability SID
[...] setup refresh: processed 2 write roots (read roots delegated); errors=[]
[... codex-windows-sandbox-setup.exe] setup binary completed

Impact

• A first-time sandbox setup for a NEW CODEX_HOME (which resets the
  shared accounts' secret) instantly breaks every other home on the
  machine until each is re-set-up elevated — during which any running
  codex exec sessions on those homes storm the desktop with UAC
  consents.
• Headless/automation runs on a stale home escalate to interactive UAC
  prompts — a prompt storm on whatever desktop is logged in, and the
  runs fail closed (Failed to write file ...) when declined.
• Read-only runs still pass on a stale home, so simple health probes
  report healthy while builds storm — the failure is invisible until
  write time.

Asks

1. Store the sandbox secret so multiple CODEX_HOMEs on one machine can
   share the accounts (machine-scoped state keyed off the accounts, not
   per-home markers), or namespace the sandbox accounts per home.
2. Never raise interactive elevation from non-interactive codex exec
   runs — fail with a typed error instead.
3. Document the one-home-at-a-time constraint if it is intended.

Environment

• codex-cli 0.149.0 (npm @openai/codex), Windows 11 Home 10.0.26200
• Sandbox binaries: codex-windows-sandbox-setup.exe,
  codex-command-runner-0.149.0.exe (vendored)
• One Windows user; homes provisioned per Codex-bank pattern; setup
  markers version 5.
• Related open issue: https://github.com/openai/codex/issues/36865
  (desktop app vs npm CLI ping-ponging one shared ~/.codex marker).
  This report is the multi-CODEX_HOME form of the same class: three
  CLI homes, one Windows user, machine-wide sandbox accounts, per-home
  markers. 36865 does not cover that repro.

Addendum 2026-08-25: elevated from-scratch recreate fails (CreateProcessAsUserW: 2)

Measured 2026-08-25 ~10:27 AM on the same machine, attended and
elevated. With one home (.codex-overflow2) reset to from-scratch
state (its setup_marker.json and deny_read_acl_state.json
deleted), an ELEVATED codex sandbox windows setup run from an
administrator PowerShell fails immediately:

windows sandbox failed: CreateProcessAsUserW failed: 2 (The system
cannot find the file specified.) | cwd=C:\dev\wt\worktree-reaper |
cmd=windows setup | env_u16_len=4506 | si_flags=256 |
creation_flags=525312

The home's own sandbox log records only START: windows setup and
nothing further. Read-only probes on the same home still pass
(cmd /c exit 0 spawns fine), so the failure is specific to the
setup path's spawn-as-sandbox-user. Practical consequence: on a
machine in this state there is NO working recovery path for a broken
home short of reinstalling the codex runtime — per-home state deletion
plus elevated re-setup, the documented recovery, cannot complete.
This compounds the marker-rotation defect above: any home that loses
the current machine-wide secret cannot be re-qualified.

Start with the codex sandbox windows setup and codex exec entry points, then trace how .sandbox/setup_marker.json and deny_read_acl_state.json interact with the machine-wide sandbox accounts and the vendored setup binaries. Reproduce with multiple CODEX_HOME values and inspect the reported UAC and CreateProcessAsUserW failures. Done means multiple homes remain valid without secret ping-pong, and non-interactive runs do not raise interactive elevation.