Creating a secure and efficient sandbox environment to bring Codex support to Windows

If you're curious how AI coding agents can execute code on your machine without putting your files at risk, this walkthrough is for you. OpenAI recently explained the engineering behind bringing Codex to Windows, and the way they solved the safety problem is genuinely interesting. In this article, we'll break down how the Windows sandbox works, why it was harder to build than the macOS version, and what it means for developers who want an AI agent that can actually edit files and run commands on a Windows PC.

Why Running AI Agents on Windows Was Tricky

Codex isn't just a chatbot that suggests code. It's an agent that reads your project, edits files, and executes commands to build and test software. That power comes with obvious risk: an agent with full access to your system could accidentally (or through a bad prompt injection) delete files, touch directories it shouldn't, or make network requests you never approved.

On macOS, OpenAI leaned on Seatbelt, Apple's built-in sandboxing technology, to give Codex a controlled environment with limited file access and restricted networking. Windows, however, doesn't have a direct one-to-one equivalent that fits Codex's needs, so the team had to design a different approach from the ground up.

The goal was simple to state but hard to implement: let Codex do useful work inside a project folder while blocking anything outside that boundary, and keep network access locked down by default.

The Approach: Restricted Tokens and Job Objects

OpenAI's solution on Windows combines two long-standing operating system features: restricted tokens and Job Objects.

A restricted token is a stripped-down security profile that the sandboxed process runs under. Windows uses a system of access control lists (ACLs) to decide who can read or write any given file or folder. By launching Codex's child processes with a restricted token, OpenAI ensures those processes only hold permissions for the workspace folder. Everything else on the drive, including your personal documents and system files, is effectively invisible or read-blocked from the agent's point of view.

Job Objects, meanwhile, act as a container for the processes Codex spawns. They let the system apply limits and kill entire process trees at once, so nothing the agent starts can outlive the session or escape oversight.

Together, these mechanisms create a boundary that matches what Seatbelt provides on macOS: the agent can work freely inside the project, but attempts to write outside the approved folder are simply denied by the OS itself, not by polite prompting.

Handling Network Restrictions

File access is only half the battle. Unrestricted network access would let a misbehaving process exfiltrate data or download something harmful. OpenAI's Windows implementation keeps networking locked down unless you explicitly allow it, mirroring the behavior on other platforms.

As on macOS, you can run Codex with network access disabled entirely, or grant it permission when a task genuinely requires it, such as installing dependencies. The default posture is restrictive: the agent has to ask, and you stay in control.

What This Means for Developers

For Windows users, this update removes a real barrier. Previously, developers on Windows who wanted to use Codex as a local coding agent had fewer options, often relying on workarounds like running inside WSL or a virtual machine. A native sandbox means Codex can run directly on Windows with the same safety guarantees that made it trustworthy elsewhere.

The key takeaway is that agent safety doesn't have to depend on the model "behaving well." By enforcing boundaries at the operating system level, OpenAI makes the safe path the only path. Even if the agent goes off script, the underlying sandbox prevents it from reaching anything outside its workspace.

It's also a good example of practical security engineering: rather than inventing a new security layer, the team composed features Windows already had, restricted tokens and Job Objects, into something that serves a modern use case.

The Bigger Picture

AI coding agents are becoming mainstream tools, and the question of how to run them safely on real machines with real data is one of the most important challenges in the field. OpenAI's Windows sandbox shows one credible answer: let the operating system do the enforcement, keep the agent's permissions minimal, and make dangerous actions impossible rather than discouraged.

If you work primarily on Windows and have been waiting to try Codex as a local agent, the sandbox work makes that a much more realistic proposition. Just remember the usual caveats: no sandbox is perfect, keep your OpenAI tooling up to date, and review what the agent does, especially when you grant it network access.

As agents grow more capable, expect sandbox design to keep evolving alongside them. For now, OpenAI's approach on Windows offers a solid template for how to give AI real access to your machine without handing it the keys to everything.