OpenAI builds custom Windows sandbox for Codex coding agent after existing tools proved insufficient

OpenAI has implemented a custom sandbox environment for its Codex coding agent on Windows after determining that existing Windows isolation mechanisms could not adequately balance safety with developer productivity. The company evaluated and rejected AppContainer, Windows Sandbox, and Mandatory Integrity Control (MIC) before building its own solution.

The problem with existing Windows tools

According to David Wiesen, member of OpenAI's technical staff, when he joined the Codex engineering team in September 2025, Windows users faced two suboptimal choices: manually approving nearly every command Codex wanted to execute, or enabling Full Access mode with no restrictions.

OpenAI evaluated three existing Windows isolation mechanisms:

AppContainer offered OS-level isolation but proved too restrictive for Codex's open-ended developer workflows. The tool is designed for apps that know their exact access requirements upfront, while Codex needs to drive arbitrary shells, Git operations, Python environments, package managers, and build tools.

Windows Sandbox provides strong VM-based isolation but operates in a disposable environment separate from the user's actual development workspace. Additionally, Windows Sandbox is unavailable on Windows Home editions, limiting its viability.

Mandatory Integrity Control (MIC) labeling appeared promising initially—running Codex at low integrity while relabeling writable directories would let Windows enforce write restrictions. However, marking a workspace as low integrity affects all low-integrity processes system-wide, not just Codex, creating broader security risks than targeted access controls.

The custom solution

OpenAI's implementation, called the "unelevated sandbox," uses two Windows primitives: security identifiers (SIDs) and write-restricted tokens. The design does not require administrator privileges.

The sandbox creates synthetic SIDs—security identifiers that don't correspond to real users but can appear in access control lists (ACLs). A dedicated "sandbox-write" SID is granted write, execute, and delete access only to specific directories where Codex should operate.

Write-restricted tokens enforce a dual-check system: for any write operation to succeed, both the normal user identity and at least one SID from the token's restricted list must have permission. This allows precise filesystem write control through ACLs.

Codex runs with the permissions of the user by default, making it both powerful and potentially dangerous. The sandbox constrains this by allowing Codex to read files broadly while restricting writes to the user's workspace directory, with no internet access unless explicitly specified.

What this means

The implementation highlights a gap in Windows' native sandboxing capabilities for developer tools that need flexible, fine-grained isolation. While macOS offers Seatbelt and Linux provides seccomp or bubblewrap, Windows lacked an equivalent solution for Codex's use case. OpenAI's approach demonstrates that building developer-focused isolation on Windows requires combining lower-level primitives rather than using existing high-level tools. The solution enables Windows users to run Codex with the same safety and convenience available on other platforms, without compromising on either security or developer experience.