Building a safe and effective sandbox for Codex on Windows

Codex for Windows initially had no proper sandbox, forcing users to approve nearly every command or turn on Full Access. To secure both safety and usefulness on Windows, OpenAI designed its own sandbox.

First, they reviewed AppContainer, Windows Sandbox, and Mandatory Integrity Control (MIC), but none of them fit.

• AppContainer was too narrow for Codex, which needs to handle shell, Git, Python, and package managers across an open-ended development workflow.
• Windows Sandbox offered strong isolation on its own, but it didn't fit Codex's need to work directly with real checkouts and local tools, and it also wasn't available on Windows Home SKUs.
• MIC had the problem of turning the workspace into low-integrity, which meant not just Codex but other low-integrity processes could also write to that space.

The first prototype, the unelevated sandbox, controlled write scope using SIDs and a write-restricted token. It created a synthetic SID called sandbox-write, granted write, execute, and delete permissions on cwd and additional writable_roots, and blocked writes for the same SID on areas like /.git, /.codex, and /.agents. Execution was done with a token that placed Everyone, the current logon SID, and sandbox-write on the restricted SID list.

For networking, the approach blocked bypass paths using environment variables and denybin. It adjusted HTTPS_PROXY, ALL_PROXY, GIT_HTTPS_PROXY, NO_PROXY, GIT_SSH_COMMAND, and tweaked PATH and PATHEXT, but this approach was only advisory level, so it couldn't stop programs that opened sockets directly.

To properly block networking, Windows Firewall was needed, but rules couldn't be attached to the non-principal identity of a restricted token. In the end, Codex was redesigned as an elevated sandbox requiring administrator privileges.

The final design separates setup and execution.

• The setup binary creates a synthetic SID, creates local users CodexSandboxOffline and CodexSandboxOnline, and stores credentials encrypted with DPAPI in a location the sandbox user cannot read.
• CodexSandboxOffline has an outbound firewall rule applied to block networking, and the rule's correctness is verified when needed.
• Since the sandbox user by default cannot read other Windows user profiles and system directories, read ACLs are asynchronously appended for C:\Users\<real-user>, C:\Windows\, C:\Program Files\, C:\Program Files (x86)\, C:\ProgramData\, and others.

At the execution stage, codex-command-runner.exe is the core. codex.exe launches the runner as the sandbox user via CreateProcessWithLogonW(...), and the runner reads the logon SID from its own token to create CreateRestrictedToken(...), then executes the actual child process via CreateProcessAsUserW(...). Here too, the restricted SID list maintains Everyone, Logon, and Synthetic.

As a result, the final structure is organized into 4 layers: codex.exe, codex-windows-sandbox-setup.exe, codex-command-runner.exe, and the child process. OpenAI concludes that since Windows doesn't provide a single primitive for a safe autonomous coding agent, they combined multiple tools and concepts to achieve both safety and real-world usability.