How OpenAI's Windows sandbox for Codex actually works

When you let a coding agent loose on your laptop, you are doing something genuinely strange. You are giving a program permission to write files, run other programs, and edit code, and you are trusting it to stay inside the lines you drew. On Linux and macOS, the lines are drawn with tools developers have used for years: namespaces, seccomp filters, sandbox-exec. Windows has never had a clean equivalent. If you wanted real isolation, you reached for WSL2 or a full container, which meant dragging a Linux subsystem along just to run a Windows-native tool.

Today OpenAI published the engineering post explaining how the Codex app sidesteps that on Windows. The sandbox is co-developed with Microsoft, it uses two old Windows security primitives most developers have never directly touched, and the whole thing is open-sourced so anyone building a Windows agent runtime can use the same approach. ¹

I want to walk through how it actually works, because the interesting bit is not the announcement, it is the mechanism. Once you see it, you can reason about what the sandbox protects against and, more importantly, what it does not.

The problem, stated plainly

A coding agent runs in a loop. It reads files, writes files, executes commands, reads the output, and decides what to do next. To do this well, it needs real access to a real filesystem and a real shell. To do this safely, it must not have access to your files, your credentials, or your network in any way you did not intend.

The classic answer is a container: spin up an isolated environment with its own filesystem and process tree, run the agent inside, and let it tear that environment apart all it wants. On Windows, containers exist but they are heavy. WSL2 exists but it is, fundamentally, a Linux virtual machine glued to the side of your operating system. Neither is ideal for a tool that wants to feel like a native Windows app starting up in milliseconds.

OpenAI's sandbox does not use either. It runs the agent as a normal Windows process, but a process whose hands have been tied at the OS level using two primitives: restricted tokens and ACLs.

Restricted tokens: stripping the process below standard user

Every process on Windows runs with an access token. The token is the thing Windows checks when the process tries to do something privileged: open a file, write to the registry, talk to another process. The token says, in effect, "this process is acting on behalf of this user, with these groups, with these privileges." Without a token, you cannot do anything. With the wrong token, the kernel says no.

A restricted token is a derived token with capabilities removed. You take the user's normal token, and you produce a new one where some of the user's group memberships are marked as "deny-only" (they can only be used to deny access, never to grant it), and some privileges are stripped entirely. The kernel still recognises the process as belonging to the user, but when it checks "can this token open C:\Users\me\Documents?", the answer flips to no. ²

This matters because it is below normal user level. A standard Windows process, run by you, can read most of your home directory by default. A restricted-token process, run by you, cannot, unless the integrator explicitly allows specific paths.

The codex agent process is launched with such a token. Its powers, at startup, are deliberately smaller than yours.

ACLs: permission lists on every object

The second primitive is ACLs — Access Control Lists. Every file, directory, registry key, and named object on Windows carries an ACL: a list of entries that say "this principal can do these things, this other principal cannot do these other things." When a process tries to open an object, the kernel walks the ACL and compares it against the process's token. If nothing matches, access is denied.

The Codex sandbox configures ACLs so that the agent's working directory is readable and writable, and almost nothing else is. The agent can churn through its project. It cannot wander into your SSH keys.

The two primitives compose. The restricted token narrows who the process can claim to be. The ACLs narrow what each object will accept. Neither is sufficient alone. A restricted token without careful ACLs still has access to anything ACLed for "everyone." Careful ACLs without a restricted token are still bypassed by anything the user themselves can do. Together, they form a boundary.

That is the entire security model, at the mechanism level. Two primitives, both shipped in Windows for over a decade, composed in a way that has not been standard practice for agent runtimes until now.

Where the jail metaphor breaks

It is tempting to call this a jail or a sandbox and move on. Both metaphors help, and both break in specific places worth naming.

The agent still has the CPU and memory of the host. A sandboxed process is not resource-isolated by default. It can spin a loop, fill RAM, and slow your machine to a crawl. Restricted tokens do nothing about this. If you want resource limits, you need job objects, a separate Windows primitive the sandbox can layer on but which is not the same mechanism.

The agent has the network unless you take it away. A restricted token does not, by itself, remove network access. A coding agent that can make outbound HTTP requests can talk to anything its DNS resolver can reach. If you care about exfiltration, the sandbox alone does not solve it; you need firewall rules or a separate network namespace equivalent.

ACLs are only as good as the integrator's configuration. This is the honest part. Windows ACLs are powerful and notoriously fiddly. A path you assumed was blocked can be writable because of an inherited permission on a parent directory, or because of a group membership you forgot about. ³ Open-sourcing the sandbox is, in part, a way of pushing this complexity into the open, where it can be audited rather than assumed.

The metaphor that holds up better than "jail" is "a process with a smaller passport." It can still walk around, but most doors will not open for it, and the ones that do were specifically left unlocked.

Why open-sourcing the sandbox is the real news

OpenAI did not just ship the Codex app on Windows. They open-sourced the sandbox itself. ¹ That is a different kind of move than a product launch.

A closed sandbox asks you to trust a vendor's claim about isolation. An open sandbox lets a security researcher read the code, find the gap between the restricted token configuration and the ACL setup, and report it. More usefully, it lets other agent tools, competing coding agents, internal enterprise tools, niche developer utilities, adopt the same isolation primitive without reinventing it. The cost of building a safe Windows agent runtime drops from "design your own security model" to "use the open-sourced one."

This is how an interface becomes a standard. Not by being mandated, but by being the first decent option that is free.

What to watch

A few things I would keep an eye on over the next six months.

Audit history. Restricted tokens and ACLs have been in Windows for twenty years. Using them as the isolation layer for an agentic workload is new. Expect security researchers to probe the configuration; expect at least one published gap.

Whether other agent vendors adopt it. If Cursor, Windsurf, or smaller Windows-native coding tools pick up the open-sourced sandbox, it becomes the de facto Windows agent isolation layer. If they stay on WSL2 or roll their own, it stays an OpenAI-specific thing.

The network story. The sandbox handles filesystem and process capabilities cleanly. Network is the gap. Watch for whether OpenAI or Microsoft layers a network policy primitive on top, or whether they leave it to integrators.

Contrast with cloud-resident agents. Anthropic's Claude Code runs across AWS Bedrock, GCP Vertex, and Azure Foundry — the agent lives inside the enterprise's existing cloud trust boundary rather than on the endpoint. ⁴ That is a structurally different answer to the same problem, and some security teams will prefer it precisely because endpoint sandboxing is hard. Both approaches will coexist; the interesting question is which workloads each one wins.

The mechanism is the story. Two old primitives, composed carefully, shipped openly. That is how a quiet piece of plumbing becomes the thing everyone else builds on.

---

Footnotes and links

Further reading

• [Paper / post] OpenAI: Building a safe, effective sandbox to enable Codex on Windows — https://openai.com/news/
• [Docs] Microsoft Win32 Security: Restricted Tokens — https://learn.microsoft.com/en-us/windows/win32/secauthz/restricted-tokens
• [Docs] Microsoft Win32 Security: Access Control Lists — https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists
• [Coverage] Windows Report: OpenAI Brings the Codex App to Windows With a New Native Sandbox — https://windowsreport.com/openai-brings-the-codex-app-to-windows-with-a-new-native-sandbox

Footnotes

1. OpenAI Engineering Blog, "Building a safe, effective sandbox to enable Codex on Windows", 13 May 2026: https://openai.com/news/ ↩ ↩²

2. Microsoft Docs, "Restricted Tokens": https://learn.microsoft.com/en-us/windows/win32/secauthz/restricted-tokens ↩

3. Microsoft Docs, "Access Control Lists": https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists ↩

4. Anthropic Claude Code availability on AWS Bedrock, Google Cloud Vertex AI, and Azure AI Foundry, per public model pages, 2026. ↩

¶