How OpenAI built a Codex sandbox on Windows without a native OS primitive

The gap that started with a missing OS feature

When David Wiesen joined the Codex engineering team in September 2025, the coding agent had no sandbox on Windows at all. That left Windows users with two bad options: approve nearly every command the agent wanted to run, including reads, or flip on Full Access mode and let Codex run anything without oversight.

The reason was mundane but decisive. Codex's default mode — read almost anywhere, write only inside the workspace, no internet unless requested — depends on the operating system enforcing those limits. macOS has Seatbelt; Linux has seccomp and bubblewrap. Windows ships nothing equivalent out of the box.

So the team's job was not to configure an existing sandbox but to construct one from unrelated Windows building blocks. That framing explains why the final system is as elaborate as it is.

Three off-the-shelf Windows options, three dead ends

The team evaluated AppContainer, Windows Sandbox, and Mandatory Integrity Control labeling, and rejected all three for concrete, differently-shaped reasons.

AppContainer gives a real OS boundary but is built for apps that declare their capabilities up front — the wrong shape for an agent that drives shells, Git, Python, package managers, and whatever binaries it decides it needs. Windows Sandbox is a stronger box, a disposable VM, but Codex has to act on the user's actual checkout and tools, not a throwaway desktop; it also isn't available on Windows Home SKUs, a product-level disqualifier.

MIC integrity labeling looked elegant — run Codex at low integrity, relabel writable roots — but marking a workspace as low integrity means any low-integrity process on the host can write there, turning the developer's real checkout into a system-wide sink. The semantic change was too broad to justify.

The unelevated prototype and the one thing it couldn't do

The first working design avoided asking users for administrator privileges. It leaned on two Windows primitives: synthetic security identifiers and write-restricted tokens. A synthetic SID called sandbox-write was granted write, execute, and delete on the working directory and any configured writable_roots, and explicitly denied write to sensitive paths like .git, .codex, and .agents. Commands ran under a write-restricted token whose restricted SID list included Everyone, the session SID, and sandbox-write.

File writes were solved cleanly. Network access was not. Without admin rights, Windows Firewall was off the table, so the team could only set environment overrides — pointing proxies at a dead endpoint (HTTPS_PROXY=http://127.0.0.1:9), forcing GIT_SSH_COMMAND to exit 1, and prepending a denybin directory to PATH.

The author is blunt about the limit of that approach.

That caught a lot of normal tool-driven traffic, but it was still only advisory. A process could ignore the environment, bypass PATH, or just open sockets directly—too risky.Montana Labs

Crucially, even well-behaved binaries that implement their own networking stack would slip past it. That weakness alone, not the ACL setup cost or the difficulty of changing semantics, is what pushed the team to abandon the no-elevation constraint.

Why real network enforcement forced four binaries and two fake users

Windows Firewall could block outbound traffic, but only if the sandboxed processes ran as a distinct principal. Firewall rules can't match a restricted token's synthetic SID, can't distinguish one sandboxed invocation of python.exe from any other, and blocking a port like 443 was the wrong policy entirely — the goal was to block arbitrary outbound access for one specific process tree.

The solution was to create two local users, CodexSandboxOffline (targeted by firewall rules) and CodexSandboxOnline (not targeted), with credentials stored and encrypted via DPAPI where the sandbox users can't read them. Because these users aren't the real Windows user, they lost read access to directories normally shared with Authenticated Users, so the setup step also grants read ACLs across paths like the user profile, C:\Windows, and Program Files — run asynchronously because it's slow.

Spawning commands as another user hit a privilege wall at CreateProcessAsUserW, which couldn't reliably launch a restricted-token child from the real-user side of the boundary. The workaround introduced codex-command-runner.exe: codex.exe launches the runner as the sandbox user via CreateProcessWithLogonW, and the runner — already on the sandbox-user side — mints the restricted token and spawns the real child. Alongside a dedicated elevated setup binary, that yields four layers: codex.exe, the setup binary, the command runner, and the child process.

The implication: platform parity for Codex came at the cost of an admin setup step

The headline outcome is narrow and specific: to make Codex behave the same on Windows as on macOS and Linux, OpenAI had to require elevated admin permissions at setup time — the exact constraint the team spent its first prototype trying to avoid. Network suppression that could withstand adversarial code turned out to be non-negotiable, and on Windows that meant firewall rules, which meant a separate principal, which meant elevation.

For teams building agents that run local commands, the concrete lesson here is that the enforcement boundary drives the architecture, not the other way around. A convenient, unelevated design was technically workable for file writes and collapsed on the one requirement — blocking exfiltration — that couldn't be advisory. Everything downstream, from DPAPI-stored credentials to the command-runner binary, exists to satisfy that single hard requirement.

As Wiesen frames it, Windows handed them no primitive that maps to 'safe autonomous coding agent,' so the team composed one. The result is admittedly not simple, but each piece — the synthetic SID, the two users, the async read-ACL grants, the split spawn flow — traces back to a specific failure of a simpler approach.