Windows Sandboxing for Coding Agents¶

No single Windows primitive sandboxes a coding agent cleanly; the working pattern composes a synthetic SID, write-restricted token, and dedicated principal user, or uses WSL2.

The four requirements¶

OpenAI's Codex Windows sandbox post (May 2026) lists four conditions a coding-agent sandbox on Windows must satisfy:

Open-ended binary execution. The agent picks binaries at runtime (Git, node, pip, MSBuild, user scripts).
Host workspace read-write. The agent edits the user's actual checkout, and editors, debuggers, and CI consume it live.
No admin elevation. Setup and per-task launch run as the standard developer user.
Policy propagates down the process tree. Spawned children inherit the same write and network restrictions.

No single Windows primitive satisfies all four, though each is still right for the workload it was designed for.

Why each primitive fails¶

AppContainer¶

AppContainer is "a capability-based isolation model built for apps that know, up front, exactly what they need to access" (Codex post, Microsoft Learn). That is wrong for an agent picking binaries at runtime. Windows also "doesn't allow matching a firewall rule to the non-principal identity of a restricted token" (aetos.ai mirror): a rule on codex.exe does not follow git.exe children. So OpenAI uses dedicated local users as the firewall-matchable principal. AppContainer fails requirements 1 and 4.

Windows Sandbox¶

Windows Sandbox is a Hyper-V-backed disposable VM with the highest pure-isolation strength here. It fails on workflow fit: "Codex needs to act directly on the user's actual checkout, tools, and environment, not inside a separate throwaway desktop" (Codex post). Mapped folders exist (config docs), but each launch pays a VM cold-start, and Hyper-V is absent on Windows Home (FAQ). Windows Sandbox fails requirement 2 and is SKU-limited.

Mandatory Integrity Control (MIC)¶

MIC blocks lower-integrity writes regardless of the DACL (Microsoft Learn). Confining the agent at Low integrity means labeling every workspace file's SACL with SYSTEM_MANDATORY_LABEL_ACE. Those labels persist on disk and apply to every Low-integrity process (Protected Mode browsers, sandboxed renderers, other agents), which leaks the boundary through the filesystem. MIC fails requirements 2 and 4.

The composition that works¶

OpenAI's shipped sandbox uses three Windows primitives Microsoft never bundled as a sandbox SKU (Codex post):

A synthetic SID (sandbox-write) granted write, execute, and delete on workspace paths via standard ACL entries.
A write-restricted token with restricted SID list [Everyone, Logon, sandbox-write]. Writes succeed only if both the user identity and a SID from the restricted list are granted access (Restricted Tokens).
Dedicated local users (CodexSandboxOffline, CodexSandboxOnline) as the token principal, giving Windows firewall a stable identity to match.

Why it works¶

The write-restricted token is an AND-gate. The user SID grants the baseline, the restricted SID list narrows it, and the synthetic SID on workspace paths is the only surviving credential. Children inherit the token, so the agent never enumerates its binaries, and firewall scoping falls to the principal user.

Where the AND-gate leaks¶

The AND-gate is not airtight. Because Everyone sits in the restricted SID list, the restricted-side check passes for any directory that already grants Everyone write access. So a broadly-permissioned workspace silently weakens the boundary (Codex post). The token also confines only the filesystem. Post-launch research describes Configuration-Based Sandbox Escape, where writing the CLI's own config from inside the sandbox turns startup into an escape primitive (Cymulate, 2026). Treat it as write-scoping, not containment.

When this backfires¶

Computer-use agent, not coding agent. GUI automation with no host workspace is what Windows Sandbox was built for (cua.ai).
WSL2 is the primary dev environment. OpenAI recommends WSL2 where available, because Landlock, seccomp, and bubblewrap isolate more strongly than restricted-token composition (Codex CLI on Windows, joecuevas.com). The cost is filesystem drift and slow small-file I/O.
Workspace on a network share, mapped drive, or OneDrive path. ACL Deny ACEs and SACL labels interact badly with remote replication. Codex CLI shipped a real instance where orphan-SID Deny ACEs produced .git/FETCH_HEAD: Permission denied (openai/codex#21304).
Read access matters as much as write. The token confines writes only, so combine it with dual-boundary sandboxing for read and network threats.

Selection rubric¶

Workload	Recommended
Coding agent on Windows Pro+, host checkout	Composed SIDs + write-restricted tokens + dedicated principal user
Coding agent with WSL2 available	WSL2 with Landlock/bubblewrap (stronger isolation; filesystem drift)
Coding agent on Windows Home	Composed SIDs + write-restricted tokens (no Hyper-V)
Computer-use agent (GUI, no host workspace)	Windows Sandbox
Packaged Win32 app with declared capabilities	AppContainer
Protect host OS from low-integrity process	MIC

Key Takeaways¶

A coding agent on Windows has four hard requirements — open-ended binaries, host workspace, no admin, child-process propagation — that no single primitive satisfies.
AppContainer fails on capability enumeration and firewall rules not following children; Windows Sandbox breaks host-workspace integration and is absent on Home; MIC mutates host SACLs and leaks the boundary to other Low-integrity processes.
OpenAI composes a synthetic SID, a write-restricted token, and a dedicated local user as the principal — the SID gates writes via the token's AND-check, the principal gives firewall rules something to match.
WSL2 is the strictly-stronger fallback when Linux-grade isolation matters more than native filesystem fidelity; the trade is filesystem drift.
Same primitive, different workload: Windows Sandbox fits computer-use agents, AppContainer fits packaged Win32 apps. Match primitive to workload shape.