OpenAI’s coding agent, Codex, can read files on a user’s computer, but is deliberately restricted in where it can write them, limiting output to the user’s current workspace directory. The decision to prioritize this balance between access and constraint stemmed from a challenge the Codex engineering team first recognized in September: the lack of a robust sandbox implementation. This forced a choice between overly permissive access or severely restricted functionality. However, that convenience had to be balanced with security, explained David Wiesen, Member of Technical Staff. To achieve this, OpenAI built its own sandbox environment for Windows, launching commands with reduced permissions that propagate “down the process tree,” effectively limiting what the coding agent can do even as it runs with the permissions of a real user and preventing internet access unless explicitly requested.
Codex for Windows: Balancing Safety and Effectiveness
The initial deployment of OpenAI’s coding agent, Codex, on Windows presented a significant engineering challenge; the team discovered in September 2025 that a sandbox implementation was absent, immediately creating a difficult trade-off between usability and security. Rather than allowing the agent unfettered access to a user’s system or severely restricting its functionality, developers sought a nuanced approach to ensure both effectiveness and safety. Codex, designed to operate on developer laptops via command line interface, IDE extension, or desktop app, functions by mediating a conversation between a user and a cloud-based model for code inference, running with the permissions of a real user by default. This inherent power, however, necessitated careful constraint, forming the core of its safety strategy. This approach required a solution that didn’t demand administrator privileges to operate, a key design goal.
The team initially explored existing Windows tools like AppContainer, Windows Sandbox, and Mandatory Integrity Control (MIC) labeling, but found each inadequate for their specific needs. AppContainer, while offering strong isolation, was deemed too restrictive for the open-ended nature of developer workflows. Windows Sandbox, a disposable virtual machine, proved incompatible with directly modifying the user’s existing project environment. MIC integrity labeling, which alters filesystem permissions based on trust levels, presented a different set of risks. Ultimately, the team designed a custom solution granting write access only to the current workspace directory, with no internet access unless explicitly specified.
AppContainer Evaluation for Open-Ended Workflows
The pursuit of secure coding agent integration into developer workflows presented immediate challenges for the Codex engineering team; by September 2025, the absence of a suitable sandbox implementation became apparent, forcing a difficult trade-off between permissive access and stringent restriction for Windows users. Enabling a coding agent like Codex to operate effectively demanded a balance between minimizing user friction and safeguarding the system, a problem complicated by the agent’s inherent power. The team quickly realized that simply granting broad access, while convenient, was unacceptable from a security standpoint. Initial investigations focused on leveraging existing Windows capabilities, but none proved ideal. AppContainer, the native Windows sandbox, initially appeared promising due to its capability-based isolation model. However, its strength lay in controlling access for tightly scoped applications, a limitation that proved problematic for Codex.
Another avenue explored was Mandatory Integrity Control (MIC) integrity labeling, a system that assigns trust levels to processes and objects. The concept involved running Codex with low integrity, relabeling writable directories accordingly, and relying on Windows to enforce write restrictions. While MIC appeared promising, the team discovered that modifying filesystem integrity levels carried significant risks. Marking a workspace as low integrity would not only restrict Codex’s access but also expose the user’s entire checkout to potential compromise from any low-integrity process. “On a real developer machine, that turns the user’s actual checkout into a low-integrity sink for the host, which is much riskier than granting carefully targeted ACLs to one sandbox design,” Wiesen cautioned. This solution prioritized operation without requiring administrator privileges, focusing on limiting file writes within your workspace.
You get a fresh Windows desktop with a strong isolation boundary, and whatever you do inside it disappears when the session ends.
The team’s initial exploration of existing Windows tools revealed limitations in achieving this balance. While AppContainer offered a strong isolation model, its rigid structure proved unsuitable for Codex’s open-ended developer workflows, which require access to shells, Git, Python, and a variety of other tools. This approach aimed to limit file writes without requiring administrator privileges.
The normal user identity (the token “owner”) must be allowed to do it At least one SID in the token’s restricted SID list must also be granted access In practice, these checks let us use ACLs to define exactly where the sandbox could modify the filesystem, which offered the granularity we needed around write operations.
Mandatory Integrity Control: Risks to Workspace Trust
The implementation of robust security measures for AI coding assistants like Codex has revealed a trade-off between usability and system-wide trust, particularly concerning file access permissions. The core challenge lay in balancing the desire for a frictionless experience with the need to prevent malicious or buggy code from compromising the user’s system. This asymmetry is deliberate; the team sought to avoid the cumbersome process of requesting constant approval for every file operation, which would severely hamper productivity. David Wiesen, Member of Technical Staff, explains the importance of a smooth workflow. The team explored several options, including AppContainer and Windows Sandbox, but ultimately deemed them unsuitable. The selected method, utilizing Mandatory Integrity Control (MIC) integrity labeling, appeared promising.
The idea was to run Codex at a low integrity level, relabeling the writable workspace accordingly, and letting Windows enforce the restrictions. “MIC looked elegant on paper—run Codex at low integrity, relabel the writable roots as low integrity, and let Windows enforce no-writes everywhere else,” Wiesen details. However, this approach presented a significant risk. Marking a workspace as low integrity doesn’t simply limit Codex’s write access; it broadly lowers the trust level for all low-integrity processes. The resulting system, while effective in limiting file writes and network access, represents a complex compromise between convenience and the preservation of a secure, trustworthy development environment.
A major benefit of using Codex is that you don’t have to do all the tedious work yourself.
David Wiesen, Member of Technical Staff
Implementing Isolation with SIDs and Write-Restricted Tokens
The expectation that powerful coding agents require equally expansive system access is increasingly challenged by the design choices behind OpenAI’s Codex; rather than granting broad permissions, the engineering team prioritized a highly constrained environment, a decision solidified after recognizing the lack of a native sandbox implementation in September of 2025. Initially, Windows users faced a difficult trade-off: either approve nearly every command from the agent, creating inefficiency, or enable full access, sacrificing oversight. This necessitated a novel approach to security, one that didn’t demand administrator privileges to function effectively. Codex runs with the permissions of a real user by default, a characteristic that, while empowering, presented significant safety concerns. The coding model can instruct the system to perform actions ranging from running tests to modifying files and creating Git branches, demanding a careful balance between functionality and security.
To enforce this automatic constraint on file writing and network access, the team developed a sandbox environment that leverages existing Windows capabilities in a unique combination. The key to this implementation lies in the use of Security Identifiers (SIDs) and write-restricted tokens. A SID, or security identifier, is the identity Windows uses to manage permissions; each user, group, and even login session has one. The team created synthetic SIDs, allowing them to define access control lists (ACLs) without interfering with existing system permissions. Write-restricted tokens further refine this control. These tokens require two checks before a write operation can succeed: the user identity must be authorized, and at least one SID in the token’s restricted list must also have access. This allows for granular control over where the sandbox can modify the filesystem within your workspace.
The whole point of using Codex is to have agents be able to do work without your constant attention.
