OpenAI built a Windows sandbox for Codex from scratch

OpenAI's Codex engineering team shipped a custom sandbox for Windows after concluding that none of the operating system's built-in isolation tools fit the job of constraining an autonomous coding agent. The engineering account, published by a Codex team member who joined in September 2025, details why AppContainer, Windows Sandbox, and Mandatory Integrity Control labeling were all rejected, and why the final design required elevated admin permissions to get one thing right: blocking network access.

The stakes are straightforward. Codex, OpenAI's coding agent, runs on developer laptops through the CLI, IDE extension, or desktop app, and it executes commands with the permissions of a real user by default. Without a sandbox on Windows, users faced what the post calls "two subpar options": approve nearly every command the agent wants to run, including file reads, or enable Full Access mode and let Codex run everything without restrictions. The first is inefficient; the second removes oversight entirely. Codex's default mode elsewhere allows the agent to read files almost anywhere, write files only within the workspace, and skip network access unless explicitly requested. Enforcing those bounds requires an operating-system-level sandbox, and Windows, unlike macOS with Seatbelt or Linux with seccomp and bubblewrap, does not provide one out of the box.

Three rejected approaches

The team evaluated three native Windows isolation mechanisms first, and each failed for different reasons.

AppContainer, Windows' native capability-based sandbox, offers a real OS boundary rather than best-effort restrictions. But the post explains the mismatch: "Codex is not one tightly scoped app." The agent drives open-ended developer workflows — shells, Git, Python, package managers, build tools — and AppContainer's strong isolation was built for "a much narrower class of workloads than 'let an agent operate like a developer.'"

Windows Sandbox, Microsoft's disposable lightweight VM, is more compatible with arbitrary software and a stronger box from a security perspective. But Codex needs to act directly on the user's actual checkout, tools, and environment, not inside a throwaway desktop requiring host/guest bridging. It also carried what the author calls "a fundamental product problem": Windows Sandbox is not available on Windows Home SKUs.

Mandatory Integrity Control labeling looked elegant on paper. Windows assigns integrity levels — low, medium, high — and blocks lower-integrity processes from writing to higher-integrity objects. Running Codex at low integrity and relabeling writable roots would have given the team a non-admin path with a real OS mechanism behind it. The problem is semantic breadth: marking a workspace as low integrity does not just mean "Codex can write here." It means low-integrity processes in general can write there. On a real developer machine, that turns the user's checkout into "a low-integrity sink for the host, which is much riskier than granting carefully targeted ACLs to one sandbox design."

The first prototype: an unelevated sandbox

The first working prototype combined two Windows building blocks to constrain file writes without administrator privileges. The first was the SID, or security identifier — the identity Windows ties to permissions, where users, groups, and login sessions each get one, such as S-1-5-5-X-Y for a session or S-1-5-32-544 for local administrators. Windows allows synthetic SIDs that correspond to no real user but can appear in access control lists, so the sandbox created a dedicated sandbox-write SID used by nothing else on the machine.

The second building block was the write-restricted token, a process token type that forces Windows to run an additional access check on every write. For a write to succeed, both the normal user identity must allow it and at least one SID in the token's restricted SID list must be granted access. The prototype granted sandbox-write write, execute, and delete access to the current working directory and any writable_roots configured in config.toml, explicitly denied that SID access to read-only-within-writable locations like <cwd>/.git, <cwd>/.codex, and <cwd>/.agents, and launched commands under a write-restricted token carrying Everyone, the logon session SID, and the synthetic SID.

Network suppression was weaker. Windows Firewall could not be configured without admin permissions, so the team tried to make the child environment fail-closed by poisoning the obvious escape routes: proxy-aware traffic pointed at a dead endpoint (HTTPS_PROXY=http://127.0.0.1:9, ALL_PROXY=http://127.0.0.1:9, GIT_HTTPS_PROXY=http://127.0.0.1:9), GIT_SSH_COMMAND=cmd /c exit 1, and a prepended denybin directory on PATH with stub SSH and SCP scripts resolving before the real binaries via reordered PATHEXT.

The unelevated sandbox worked, but it had drawbacks the team judged disqualifying. Applying workspace ACLs can be expensive depending on directory topology. Changing sandbox semantics was costly — unlike macOS, where the team can dynamically regenerate the .sbpl file that configures Seatbelt, adjusting ACLs on Windows is "a slow and intense operation." Most importantly, the network suppression was "advisory": a process could ignore environment variables, bypass PATH, or open sockets directly.

Network suppression forced the redesign

Weak network controls were the dealbreaker. Beyond malicious agents circumventing environment-based suppression, the post notes that "plenty of good-intentioned code/binaries would also circumvent it simply if they didn't honor the environment proxy variables, or if they implemented their own socket-based network code." Without a sandbox, malicious code could exfiltrate data from the machine to the internet.

Windows Firewall could block outbound traffic per user or program, but the matching dimensions were the wrong shape. Windows cannot match a firewall rule to the non-principal identity of a restricted token, so the team could not target "any token that includes our synthetic SID." Binary-scoped rules would cover only codex.exe, not the Git or Python processes the agent spawns. Port- and address-based rules were the wrong policy entirely: "we didn't want to block port 443; we wanted to block arbitrary outbound access for this specific restricted process tree." The only way to aim a firewall rule precisely at sandboxed commands was to run them as a separate Windows principal.

The elevated sandbox

The current implementation, which the author calls the "elevated sandbox," requires admin permissions at setup time. Child processes still run under a write-restricted token with the same restricted SID list, but the token's principal is no longer the real user — it is one of two local users Codex creates: CodexSandboxOffline, which firewall rules target, and CodexSandboxOnline, which they do not.

That design imposed a first-class setup step, encapsulated in a dedicated codex-windows-sandbox-setup.exe binary: create the synthetic SID if needed, create the two sandbox users, encrypt their credentials with the Windows Data Protection API in a location the sandbox users cannot read, and create or validate firewall rules blocking all outbound access for the offline user. The sandbox users also need read access equivalent to the real user, which does not come free when the principal changes. The setup grants read ACLs to commonly used directories — C:\Users\<real-user>, C:\Windows\, C:\Program Files\, C:\Program Files (x86)\, C:\ProgramData\ — and runs that work asynchronously because applying ACLs to each directory is expensive and the blocking setup step should not wait for it.

A second new binary, codex-command-runner.exe, exists because of a privilege wall at CreateProcessAsUserW. The natural flow — codex.exe calling LogonUserW, then CreateRestrictedToken, then spawning the child — failed because codex.exe running as the real user could create a restricted token for the sandbox user but could not reliably launch a child with it. The flow is now split in two. codex.exe calls CreateProcessWithLogonW to start the runner as the sandbox user; inside the runner, the process opens its own token, extracts the sandbox logon SID via GetTokenInformation, builds the final restricted token with CreateRestrictedToken, and calls CreateProcessAsUserW to launch the real child. The final architecture has four layers: codex.exe, the setup binary, the command runner, and the child process.

Why it matters

The post closes with two lessons that extend beyond OpenAI. First, "Windows did not hand us one primitive that cleanly maps to 'safe autonomous coding agent'" — the team composed several tools and concepts, and some early ideas were dead ends. Second, security for a coding agent differs from classic application security because Codex has to work for real developer workflows; the engineering work was balancing compatibility with agentic workloads against real enforcement. That tension shaped every tradeoff in the final design, which the author — invoking Einstein's "Everything should be made as simple as possible, but no simpler" — describes as a system where "each piece of complexity was added out of necessity, to build a sandbox that is both safe and, as much as possible, not in the user's way." As coding agents gain permission to run commands on developer machines across every major OS, the gap between advisory and enforced isolation is likely to become a competitive differentiator, not just an implementation detail.