OpenAI built a custom sandbox to run Codex safely on Windows!

Hey there, it's me, Shii-chan! Today I found one of my favorite kinds of stories: wrestling with the guts of an OS to build a safe little sandbox. It's the behind-the-scenes look at how OpenAI made Codex run safely on Windows.

OpenAI News openai.com

What was announced?

Over on OpenAI News, an engineer shared the design story of how they built a sandbox so Codex, the coding agent, can run safely on Windows.

Codex runs on developer laptops (via the CLI, the IDE extension, or the desktop app). But as of September 2025, the Windows build of Codex had no sandbox. That left Windows users with two so-so choices:

1. Approve nearly every command, even reads (tedious!)
2. Turn on Full Access mode and let everything run with no approval and no restrictions (zero oversight!)

The story so far

A sandbox is a constrained execution environment. Codex launches commands with reduced permissions, and those constraints propagate down the whole process tree. macOS has Seatbelt, and Linux has seccomp and bubblewrap, but Windows doesn't ship this kind of capability out of the box, so the team had to build their own.

They looked at existing Windows tools (AppContainer, Windows Sandbox, and Mandatory Integrity Control labeling), but none of them fit. AppContainer is built for apps that know exactly what they need up front, not for an agent that drives shells, Git, Python, and package managers. Windows Sandbox is a strong disposable VM, but Codex needs to act on your real checkout, and it isn't available on Windows Home. Integrity labeling would have turned the workspace into a place any low-integrity process could write to, not just Codex, so it was too risky.

What changes

So OpenAI built their own sandbox in two stages. The payoff: on Windows you now get a "just right" default mode instead of approval hell or a total free-for-all. By default, Codex can read almost anywhere, write only inside your workspace, and reach the network only when you say so, with the OS actually enforcing those lines.

Dive Deep

The first prototype was the "unelevated sandbox," which never asked for admin rights. The trick was to limit two things: file writes and network access.

For writes, they used SIDs (security identifiers) and write-restricted tokens. Windows lets you create synthetic SIDs that don't map to a real user, so they made one just for the sandbox called sandbox-write. That SID got write, execute, and delete access to the working directory and any writable_roots in config.toml, and was explicitly denied write access to .git, .codex, and .agents inside the working directory. Commands then ran under a write-restricted token whose restricted SID list included Everyone, the current session SID, and sandbox-write. With a write-restricted token, a write only succeeds when two checks pass: the normal owner is allowed, and at least one restricted SID is allowed too.

For the network, without admin rights they couldn't use Windows Firewall, so they blocked the obvious escape hatches with environment variables, pointing proxies at a dead endpoint and making Git over SSH fail instantly.

HTTPS_PROXY=http://127.0.0.1:9
ALL_PROXY=http://127.0.0.1:9
GIT_HTTPS_PROXY=http://127.0.0.1:9
NO_PROXY=localhost,127.0.0.1,::1
GIT_SSH_COMMAND=cmd /c exit 1

But this was only advisory: a program that ignores the environment and opens sockets directly slips right past it. Network suppression is the heart of a sandbox, so they went back to the drawing board.

That brought the current design, the "elevated sandbox." It needs admin rights at setup time, but in exchange the commands run as dedicated users created by Codex instead of the real Windows user:

• CodexSandboxOffline (blocked by firewall rules)
• CodexSandboxOnline (not blocked)

Now a firewall rule can target these dedicated users, so outbound traffic is cut off not just for codex.exe but also for the Git and Python child processes the agent spawns on your behalf. Setup creates the synthetic SID and these two users, stores their credentials encrypted with the Windows DPAPI (somewhere the sandbox users can't read), and adds firewall rules that block all outbound traffic for CodexSandboxOffline. Because the dedicated users can't read other users' profiles, setup also grants read ACLs asynchronously to directories like C:\Users\{user}, C:\Windows\, and C:\Program Files\.

The neat part is how commands actually launch as the dedicated user. Spawning a child with a restricted token directly from codex.exe hit a privilege wall at CreateProcessAsUserW(...). So they added a dedicated binary, codex-command-runner.exe. First codex.exe uses CreateProcessWithLogonW(...) to start the runner as the dedicated user, then inside the runner it builds a restricted token from its own token with CreateRestrictedToken(...) and launches the real child with CreateProcessAsUserW(...).

The final architecture has four layers: codex.exe itself, codex-windows-sandbox-setup.exe for elevated setup, codex-command-runner.exe for running restricted-token commands, and the child process. The article even quotes Einstein:

Everything should be made as simple as possible, but no simpler.

It's not a simple system, but every bit of complexity earned its place.

Wrap-up

• The Windows build of Codex had no sandbox, leaving only "approve everything" or "full access"
• Windows lacks a standard mechanism like Seatbelt or seccomp, so a custom sandbox was needed
• The first "unelevated sandbox" used SIDs and write-restricted tokens for writes, but its env-variable network block was weak
• The current "elevated sandbox" uses dedicated users CodexSandboxOffline / CodexSandboxOnline plus Windows Firewall to cut off traffic, including child processes
• It's assembled from multiple binaries: setup, a command runner, and DPAPI-protected credentials

It's a niche but meaty look at composing OS security primitives, so it'll click with Windows developers and anyone who loves how sandboxing and process isolation really work.