When folks talk about AI coding tools like Codex, the conversation usually revolves around productivity. Can it write code? Can it debug software? Can it save developers time?
What often gets ignored is the scary part: these tools are increasingly being trusted to run commands directly on people’s computers.
That reality was front and center in a new technical post from OpenAI engineer David Wiesen, who detailed the surprisingly messy process of building a secure sandbox for Codex on Windows. And frankly, one thing stood out immediately to me as a Linux guy — OpenAI basically admits Linux already had many of the tools it needed, while Windows forced the company to engineer a custom solution from scratch.
According to the post, Codex can execute shell commands, edit files, launch tests, create Git branches, and interact with development environments locally on a machine. In other words, this is not some harmless chatbot sitting in a browser tab. This is software capable of acting on a system with the permissions of a real user.
That creates an obvious problem. If an AI coding agent goes rogue, encounters malicious code, or simply makes a bad decision, the damage could extend far beyond a broken script.
On Linux and macOS, OpenAI says operating systems already provide useful sandboxing primitives. The company specifically mentions Linux technologies like seccomp and bubblewrap, alongside Apple’s Seatbelt framework on macOS. Windows, however, apparently lacked a straightforward equivalent that worked well for the sort of open-ended workflows Codex requires.
That sent OpenAI down a rabbit hole.
The company evaluated existing Windows technologies like AppContainer, Windows Sandbox, and Mandatory Integrity Control labeling, but rejected each for various reasons. Some approaches were too restrictive, others broke compatibility with real developer environments, and some required heavyweight virtualization that would have hurt usability.
OpenAI’s first attempt at solving the problem involved what it called an “unelevated sandbox.” The setup relied on synthetic SIDs, write-restricted tokens, ACL manipulation, and even environment variable tricks to try blocking outbound internet access.
But OpenAI eventually concluded the approach was too weak.
The company openly admits that programs could bypass the restrictions by ignoring proxy settings or implementing their own networking stack. That is not exactly the sort of sentence you expect to read from an AI company trying to reassure people about autonomous agents running local commands.
The final implementation became much more elaborate.
OpenAI says the current Windows sandbox now creates dedicated local users called CodexSandboxOffline and CodexSandboxOnline, applies outbound firewall restrictions, launches commands through restricted tokens, and relies on multiple helper executables to manage privilege boundaries correctly.
At one point, the company even had to create a dedicated command runner binary simply because Windows token handling got too complicated to manage cleanly from the main Codex process.
Honestly, the most fascinating part of the entire writeup is how clearly it exposes the collision between modern AI agents and traditional operating system security models. AI coding tools are quickly evolving into semi-autonomous software operators. They read files, spawn subprocesses, manipulate repositories, install packages, and potentially interact with sensitive information.
That changes the security conversation dramatically.
OpenAI effectively says Linux already had many of the sandboxing tools AI agents needed, while Windows required a complicated workaround involving firewall rules, custom identities, restricted tokens, and extensive permission management.
You know what? That is not the kind of accidental praise Linux gets every day.
