OpenAI explains how it built a secure Codex sandbox for Windows

OpenAI has explained how it built a full sandbox for Codex on Windows so the agent can run commands locally without full access to the system. The goal was simple: keep the convenience of autonomous coding without letting the model write anywhere it likes or go online without the user's explicit permission.

Why the existing options failed

At launch, Windows users had two bad choices. They could approve nearly every command, including simple file reads, or they could turn on Full Access and effectively give the agent the same privileges as the developer. That matters a lot for Codex: the agent runs through the CLI, the IDE, and the desktop app, and it can run tests, edit code, create Git branches, and call standard development tools.

OpenAI first evaluated Windows' built-in isolation mechanisms, but none worked without serious trade-offs. AppContainer provides a strong security boundary, but it is designed for a predefined application, not an open-ended mix of workflows involving Git, Python, package managers, and third-party binaries. Windows Sandbox proved too isolated: Codex needs to work with the user's real checkout, not a disposable virtual machine, and the feature isn't available on Windows Home. Integrity levels only looked good on paper, because they changed the trust model for the host's real file system.

The first protection scheme

OpenAI built its first working prototype without requiring administrator rights. It relied on a synthetic SID and a write-restricted token — a special token that allows writes only where the user's normal permissions and a separate sandbox permission both apply. As a result, Codex could read almost anywhere but write only to explicitly defined project roots.

• a dedicated `sandbox-write` SID was created
• that SID received write, execute, and delete permissions in the current working directory and in `writable_roots`
• within those directories, writes to `.git`, `.codex`, and `.agents` could be blocked separately
• every command ran with a restricted token that included `Everyone`, the current session SID, and `sandbox-write`

The approach worked reasonably well for files, but networking remained a weak spot. The team tried to break common network paths using environment variables such as `HTTPS_PROXY`, `ALL_PROXY`, and `GIT_SSH_COMMAND`, and by substituting stub binaries for `ssh` and `scp`. That was often enough for ordinary Git commands and package installers, but the protection was essentially advisory: any process could ignore environment variables, bypass PATH, or open a socket directly.

How the shipped version works

Because of these networking limitations, OpenAI dropped the idea of a sandbox that requires no admin rights at all and moved to the current, stricter design. During setup, Codex now creates two local users: `CodexSandboxOffline` for processes without network access and `CodexSandboxOnline` for scenarios that need it. Commands still run with a restricted token, but no longer as the real user. Instead, they run as a dedicated sandbox user that Windows Firewall rules can target.

This required a separate setup process. It creates the synthetic SID, provisions the sandbox accounts, encrypts their credentials with DPAPI, and configures firewall rules that block outbound traffic for the offline user. It also grants the sandbox users read access to common directories such as `C:\Users\<real-user>`, `C:\Windows`, `C:\Program Files`, and `C:\ProgramData`; otherwise, the agent couldn't even properly read the user's files and tools. Part of the ACL configuration runs asynchronously so it doesn't slow down initial installation.

Process launch created a separate problem. The team found that `codex.exe` cannot reliably go all the way from logging in as the sandbox user to calling `CreateProcessAsUserW(...)` from the real user's context. So OpenAI moved command execution into a separate binary, `codex-command-runner.exe`. First, `codex.exe` starts the runner as the sandbox user; then the runner creates the restricted token within its own session and launches the final child process. The final architecture has four layers: `codex.exe` itself, an elevated setup binary, the command runner, and the target process.

What it means

For Windows developers, this is a meaningful shift: local coding agents are becoming not just more convenient but also more predictable from a security standpoint. OpenAI has effectively shown that no single "magic" API covers agentic coding on Windows, and the problem has to be solved with a combination of ACLs, tokens, separate users, firewall rules, and additional binaries. That makes the implementation more complex, but it brings Codex's operating model closer to the real requirements of teams that want to automate routine work without giving up control entirely.