OpenAI builds a custom Windows sandbox for Codex
OpenAI just detailed how it built a custom Windows sandbox for its Codex coding agent to solve a major usability headache. Without native OS isolation like macOS or Linux offer, the team used synthetic SIDs and write-restricted tokens to lock down file writes and network access without requiring admin privileges. Why it matters: Windows developers no longer have to pick between approving every command or blindly giving the agent full machine access.

Giving an AI agent access to your terminal is a lot like handing your unlocked laptop to a stranger. On macOS and Linux, the operating system gives you solid fences out of the box. But on Windows, users have long faced a brutal dilemma: either click to approve every single command the model wants to run, or give it totally unrestricted access to your entire hard drive.
OpenAI engineer David Wiesen recently broke down how the company solved this dilemma for Codex, building a custom Windows sandbox from scratch. When Wiesen joined the Codex team in September 2025, Windows lacked any native sandboxing whatsoever, leaving developers stranded between agonizing friction and sheer security risk.
Why Microsoft's native tools missed the mark
To make a coding agent safe, you need an operating system mechanism that limits file writes strictly to the workspace and prevents unauthorized outbound network calls. While macOS has Seatbelt and Linux has bubblewrap or seccomp, Windows does not offer an equivalent general-purpose developer tool out of the box.
Wiesen evaluated three built-in Windows isolation mechanisms, and all three proved to be dead ends.
First was AppContainer, the native Windows isolation boundary. While powerful, AppContainer expects applications to declare upfront exactly what resources they will ever touch. Codex drives dynamic developer workflows, executing arbitrary shells, Git, Python runtimes, and build tools. It was fundamentally the wrong shape for an open-ended coding agent.
Next came Windows Sandbox, Microsoft's lightweight disposable virtual machine. It provides a rock-solid security boundary, but it boots into a completely isolated guest environment separated from the user's actual files and local toolchains. Bridging host and guest added massive complexity, and more practically, Windows Sandbox is entirely missing from Windows Home editions.
Finally, the team explored Mandatory Integrity Control, or MIC. Running Codex at a low integrity level and labeling the project folder as low integrity sounded tidy on paper. However, doing so would allow any other low-integrity malware on the computer to write into the developer's repository, turning the actual project checkout into an insecure sinkhole.
Building an unprivileged sandbox from scratch
Faced with no good native choices, OpenAI decided to construct its own unelevated sandbox, deliberately avoiding any requirement for administrator privileges.
To control file writes, the team combined two Windows primitives: synthetic security identifiers and write-restricted process tokens. When Windows evaluates a write request under a write-restricted token, it enforces a double-check. The standard user must have write permissions, and at least one identifier on the restricted list must also have permission.
By creating a synthetic identifier named sandbox-write, Codex grants write permissions only to the active workspace and explicitly configured folders. Crucially, the setup explicitly denies write permissions to critical internal folders like .git, .codex, and .agents, preventing the model from corrupting the repository under the hood.
Restricting network traffic without administrator privileges proved trickier, because configuring the Windows Firewall requires elevation. As a working prototype, the team chose to poison standard escape hatches. They directed all proxy environment variables to a dead local port, forced Git SSH commands to immediately terminate with an error code, and shadowed system SSH binaries with dummy scripts.
While this advisory approach effectively blocks well-behaved developer tools like package managers and Git, Wiesen acknowledged that it remains soft security, since a rogue process could theoretically open raw network sockets directly.
Why it matters
For developers building software on Windows, this update removes a massive layer of friction. Until now, using Codex locally meant either babysitting an endless stream of confirmation dialogs or recklessly trusting a cloud model with full local permissions. Getting seamless, automated execution inside an unprivileged boundary finally brings Windows to parity with macOS.
Across the broader AI landscape, this engineering story highlights that the biggest roadblock for autonomous agents is no longer just model intelligence, but local runtime safety. Modern operating systems were designed for human users, not semi-autonomous software driving developer shells. Windows in particular lacks modern, lightweight unprivileged containment mechanisms.
We think OpenAI's decision to avoid administrator prompts was essential for user adoption, as constant UAC dialogs would kill developer momentum. That said, relying on environment variables to block network egress looks like a temporary compromise rather than a permanent security fortress. Until Microsoft introduces first-class unprivileged isolation APIs into Windows itself, coding agents will likely remain caught in this tricky balance between safety and convenience.
Sources (1)
- openai.com(opens in a new tab)Originalopenai.com