OpenAI showed how it built a secure Codex sandbox for Windows

OpenAI revealed how it created a full-fledged sandbox for Codex on Windows, allowing an agent to execute commands locally without full system access. The goal was simple: preserve the convenience of autonomous coding while preventing the model from freely writing anywhere and accessing the internet without explicit user permission.

Why It Didn't Work

Initially, Windows users had two poor options. Either confirm almost every command, including simple file reads, or enable Full Access and essentially trust the agent with the same permission level as the developer themselves. For Codex, this is particularly sensitive: the agent works through CLI, IDE, and desktop applications, can run tests, edit code, create Git branches, and invoke regular development tools.

OpenAI initially checked standard Windows isolation mechanisms, but none fit without serious compromises. AppContainer provides a strong security boundary, but is designed for pre-defined applications rather than an open set of scenarios with Git, Python, package managers, and third-party binaries. Windows Sandbox turned out to be too separate a world: Codex needs to work with the user's real checkout, not a disposable virtual machine, plus this mode is unavailable on Windows Home. The integrity levels mechanism also looked good only on paper because it changed the trust model for the host's actual file system.

First Protection Scheme

OpenAI's first working prototype was built without admin rights requirements. It used a synthetic SID and write-restricted token—a special token that allows writing data only where both regular user permissions and a separate sandbox permission coincide. This allowed Codex to read almost anywhere but write only in strictly defined project roots.

• a separate SID `sandbox-write` was created
• this SID was granted write, execute, and delete permissions in the current working directory and in `writable_roots`
• within these directories, writes to `.git`, `.codex`, and `.agents` could be separately prohibited
• each command ran with a restricted token that accounted for `Everyone`, the current session's SID, and `sandbox-write`

The approach worked fairly well for files, but the network remained a weak point. The team tried to "break" typical network paths through environment variables like `HTTPS_PROXY`, `ALL_PROXY`, and `GIT_SSH_COMMAND`, as well as through stub binary substitution for `ssh` and `scp`. For regular Git commands and package installers, this often sufficed, but the protection was more of a recommendation: any process could ignore environment variables, bypass PATH, or open a socket directly.

How the Release Works

Due to network limitations, OpenAI abandoned the idea of a completely admin-free sandbox and moved to the current, stricter scheme. Now during setup, Codex creates two local users: `CodexSandboxOffline` for processes without network access and `CodexSandboxOnline` for scenarios requiring internet access. Commands still run with a restricted token, but no longer under the real user's name—instead under a special sandbox user to which Windows Firewall rules can be applied. This required a separate setup process.

It creates a synthetic SID, sets up sandbox accounts, encrypts their credentials through DPAPI, and configures firewall rules that block outgoing traffic for the offline user. In parallel, the system grants sandbox users read permissions in typical directories like `C:\Users\<real-user>`, `C:\Windows`, `C:\Program Files`, and `C:\ProgramData`—otherwise the agent couldn't even properly read user files and tools. Some ACL configuration is performed asynchronously to avoid delaying initial installation.

A separate problem arose at the process launch boundary. It turned out that `codex.exe` cannot reliably complete the entire path from logging in as a sandbox user to `CreateProcessAsUserW(...)` from the real user's context. Therefore, OpenAI moved command execution to a separate binary, `codex-command-runner.exe`: first `codex.exe` starts it as a sandbox user, and the runner within its own session creates a restricted token and launches the final child process.

In the final architecture, four layers are involved: `codex.exe` itself, an elevated setup binary, the command runner, and the target process.

What This Means

For Windows developers, this is an important shift: local coding agents become not only more convenient but also more predictable from a security perspective. OpenAI essentially showed that for agent-based coding on Windows, there is no single "magic" API, and the problem must be solved through a combination of ACL, tokens, separate users, firewall rules, and additional binaries. This increases implementation complexity but brings Codex's operational model closer to the real requirements of teams that want to automate routine work without completely surrendering control.