OpenAI explains Codex sandbox for Windows
OpenAI has detailed how it built the Codex Windows sandbox from scratch, after finding that Windows offered no built-in tool that fit what a coding agent actually needs. The final design uses two dedicated local accounts, restricted tokens, and firewall rules to keep file access and network activity within defined boundaries.
Why Windows Had No Ready-Made Solution
Before the sandbox existed, Windows users of OpenAI Codex faced two bad options: manually approve nearly every command the agent wanted to run, or switch to Full Access mode and remove oversight entirely. David Wiesen, a member of OpenAI's technical staff, wrote that neither choice matched what the product was designed to deliver.
The team evaluated three existing Windows isolation tools before building their own. AppContainer was too narrow for open-ended developer workflows involving Git, Python, shells, and package managers. Windows Sandbox required a separate throwaway environment disconnected from the user's real files, and is unavailable on Windows Home editions. Mandatory Integrity Control would have downgraded the trust level of the user's actual workspace, a tradeoff the team considered too risky for real developer machines.
Unlike macOS, which provides Seatbelt, or Linux, which uses bubblewrap, Windows has no built-in equivalent for this type of process-level isolation. That gap forced OpenAI to build its own system.
The Network Problem That Forced a Full Redesign
The team's first design ran without administrator privileges. It used synthetic security identifiers paired with restricted tokens to limit file writes to the active workspace, while keeping read access broad enough to avoid constant approval prompts. For developers, this meant fewer interruptions during normal coding tasks.
Network containment was the weak point. Without admin access, Windows Firewall was unavailable. The team rerouted common developer tools through dead endpoints and disabled standard Git transport methods to block outbound connections. Any process that ignored those environment settings could bypass the restriction entirely. That exposure was enough to justify starting over.
How the Current Sandbox Works and What It Means for Developers
The redesigned Codex Windows sandbox requires administrator permissions at setup time. During setup, Codex creates two dedicated local accounts: CodexSandboxOffline, the default execution identity blocked from outbound network access by firewall rules, and CodexSandboxOnline, used only when a user explicitly approves connectivity.
Sandboxed commands run under restricted tokens tied to these accounts, not to the real Windows user. That separation is what makes firewall rules apply to every agent-spawned process, including Git and Python, rather than to Codex alone. For developers on managed machines, a fallback unelevated mode is available when admin setup is blocked by company policy.
A dedicated setup binary handles account creation and firewall validation. A separate command-runner binary mints the restricted token and launches the requested process as the sandbox user. That split was necessary because Windows blocks a real-user process from spawning children directly under a different user's token.
[Analysis] For enterprise teams evaluating coding agents, this architecture matters beyond the technical details. A sandbox enforced at the OS level through dedicated user identities and firewall rules is meaningfully harder to bypass than one that relies on environment variables alone. As coding agents take on longer, less-supervised tasks, that enforcement gap becomes a real governance risk. OpenAI's approach signals that safe local AI tooling on Windows now requires deeper OS integration, not just application-layer guardrails. The full engineering breakdown is available in OpenAI's sandbox writeup.