›_ Codex Issues
Codex Issues / #40627

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

Open 💬 0 comments Opened Aug 25, 2026 by Epyov

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.

  1. 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.

  1. 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).

  1. 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.

  1. 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.

  1. Never raise interactive elevation from non-interactive codex exec

runs — fail with a typed error instead.

  1. 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.

(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.

View original on GitHub ↗