OpenAI details Windows sandbox design for Codex local commands
OpenAI said Codex for Windows now relies on a custom elevated sandbox design using local sandbox users, firewall rules, restricted tokens, and separate setup and command-runner components. The disclosure explains why the company moved beyond an earlier unelevated prototype, but it should be treated as OpenAI's design account rather than independent validation.
OpenAI published a technical account on May 13 describing the Windows sandbox architecture behind Codex, its local coding agent. The company said Codex for Windows previously lacked a sandbox implementation, which left users choosing between approving nearly every command or giving the tool Full Access mode.
The post frames the problem as specific to local coding-agent workflows on Windows. Codex runs commands on a developer's machine while a model handles inference in the cloud. By default, those local commands can run with the permissions of the real user, so OpenAI said it needed operating-system-level constraints that allow useful work inside a project while limiting writes and network access.
OpenAI said existing Windows isolation options did not fit the Codex use case. AppContainer was too narrow for open-ended developer workflows involving shells, Git, Python, package managers, build tools, and arbitrary binaries. Windows Sandbox offered a stronger disposable environment, but not direct access to the user's real checkout, tools, and environment, and it is not available on Windows Home. Mandatory Integrity Control looked workable on paper, but OpenAI said relabeling real workspaces as low integrity would change the host filesystem's trust model too broadly.
The company first built an unelevated prototype using synthetic security identifiers, write-restricted tokens, and access-control lists. That approach let Codex restrict writes to the current working directory and configured writable roots, while denying writes to locations such as .git, .codex, and .agents inside otherwise writable areas. For network access, however, the prototype relied on environment variables, Git settings, and PATH changes that routed common tools toward failure.
OpenAI described that network approach as advisory. A process could ignore the environment, bypass PATH, or open sockets directly. The company said this limitation pushed it toward the current elevated design, where Windows Firewall rules can apply to a dedicated sandbox user rather than the real user or a synthetic restricted-token identity.
In the current design, Codex creates two local Windows users during setup: CodexSandboxOffline, which is targeted by outbound firewall rules, and CodexSandboxOnline, which is not. Commands still run under restricted tokens, but the principal is one of those sandbox users rather than the developer's normal Windows account. OpenAI said setup also creates or validates firewall rules, stores sandbox-user credentials locally using Windows Data Protection API encryption, and applies read access where needed so the sandbox users can inspect common directories.
The architecture also separates setup from command execution. A dedicated setup binary handles the elevated Windows-specific work. A separate command-runner binary starts as the sandbox user, creates the restricted token, and launches the child command. OpenAI said this split keeps the main Codex process unelevated while giving the sandbox-user side of the boundary the privileges needed to spawn restricted child processes.
For operators, the disclosure gives a checklist for evaluating local coding agents on Windows: which account actually runs commands, how write permissions are scoped, whether network limits are enforced by the operating system, whether restrictions propagate through child processes, and what administrative setup is required. It also shows why Windows support can carry different operational tradeoffs from macOS and Linux, where OpenAI points to Seatbelt, seccomp, or bubblewrap-style primitives.
The caveat is that this is OpenAI's own design disclosure, not an independent assessment of the sandbox's resistance to bypasses. The post does not establish that every Windows environment will support the same setup path, and enterprise device policies, admin restrictions, Windows edition differences, or WSL2/native choices may affect deployment. The update also concerns local Codex command execution, not model behavior or cloud-side security.
Source list
- OpenAI, "Building a safe, effective sandbox to enable Codex on Windows," May 13, 2026. https://openai.com/index/building-codex-windows-sandbox/
- OpenAI Developers, "Agent approvals & security - Codex." https://developers.openai.com/codex/agent-approvals-security
- OpenAI Developers, "Config basics - Codex." https://developers.openai.com/codex/config-basic
- OpenAI Developers, "Windows - Codex app." https://developers.openai.com/codex/app/windows
Known uncertainties and caveats
- The security and operational claims are vendor-stated by OpenAI and have not been independently validated in the cited sources.
- The earlier unelevated prototype's network controls were advisory; the current elevated design uses Windows Firewall rules tied to a dedicated offline sandbox user.
- Admin setup, local Windows users, stored sandbox-user credentials, DPAPI handling, and enterprise device management are operationally material.
- Availability and behavior may vary across Windows editions, policy-managed devices, native Windows setup, and WSL2 fallback paths.
- The scope is local Codex sandboxing for command execution, not model quality, cloud inference security, or all Windows AI-agent environments.