OpenAI’s Windows Sandbox Is the Codex Postmortem We Needed Before the Incident
OpenAI’s Windows sandbox writeup is the kind of security post the agent industry needs more of: detailed, awkward, and honest about the places where the first version was not enough.
The headline is easy to undersell. “Codex now has a better Windows sandbox” sounds like platform plumbing, useful mostly to people who run PowerShell instead of WSL. The real story is larger: coding agents are forcing developer tools to grow real local security boundaries. Not vibes. Not modal prompts. Not “the model should ask nicely before doing the scary thing.” Boundaries backed by the operating system, designed around filesystems, process trees, network access, user identity, protected configuration, and all the weird compatibility surface that comes with real developer machines.
That is why the post matters. OpenAI says Codex on Windows previously left users with a bad choice: approve nearly every command, including reads, or enable Full Access mode and trade friction for much less oversight. Anyone who has used an agentic CLI knows that failure mode. If every harmless read needs approval, users learn to click through. If everything is allowed, the agent gets a polite shell with the user’s authority. Neither is a security model. One trains humans into rubber stamps; the other removes the stamp entirely.
Codex’s intended default is more reasonable: broad reads, writes only inside the workspace, and no internet access unless the user opts in. The problem is that a command launched by Codex still runs with the real user’s permissions unless the harness does something concrete to change that. On Windows, “something concrete” turned out to be harder than picking a Microsoft isolation primitive off the shelf.
Windows is where sandbox diagrams meet package managers
OpenAI evaluated AppContainer, Windows Sandbox, and Mandatory Integrity Control. Each looked plausible from a distance. Each failed some part of the coding-agent workload.
AppContainer has strong least-privilege isolation across credentials, devices, files, network, processes, and windows. Microsoft designed it for modern packaged app isolation, and the security posture is attractive. But Codex is not a neat packaged app performing a small set of known operations. It needs to drive shells, Git, Python, Node, compilers, build systems, tests, local tools, generated binaries, and whatever else a repo uses to prove that a patch works. A sandbox that cannot comfortably host arbitrary developer workflows is secure in the same way a locked room is secure: useful only if the work does not need to happen there.
Windows Sandbox had the opposite shape problem. It is isolated, but it gives users a disposable desktop and is unavailable on Windows Home. That is not a good fit for an agent that wants to mutate the actual checkout a developer is already working in. Mandatory Integrity Control was also rejected because it changed the trust model of the actual workspace by marking it low-integrity. That may be acceptable for some containment scenarios; it is a messy proposition for a real repository with existing tools, editors, caches, and enterprise endpoint software.
The first Codex prototype went lower level: synthetic SIDs and write-restricted tokens. Writes had to satisfy both the normal user identity check and a restricted SID check. OpenAI granted a sandbox-write SID access to the current working directory and configured writable roots, while denying writes inside protected locations such as .git, .codex, and .agents.
That last detail deserves more attention than it will get. Workspace write access is not a single permission. A coding agent needs to write source files, build outputs, scratch files, and maybe caches. It should not casually rewrite the Git database, its own configuration, or hidden instruction files that shape future agent behavior. Repo-local agent metadata is becoming part of the trusted computing base. If an agent can mutate the files that define its permissions, tools, or instructions, the sandbox boundary starts to look decorative.
Proxy variables are not a firewall
The most useful part of OpenAI’s post is its treatment of network blocking. The unelevated prototype poisoned proxy-aware paths with values like HTTPS_PROXY=http://127.0.0.1:9, ALL_PROXY=http://127.0.0.1:9, GIT_HTTPS_PROXY=http://127.0.0.1:9, NO_PROXY=localhost,127.0.0.1,::1, and GIT_SSH_COMMAND=cmd /c exit 1, plus PATH and PATHEXT tricks for denybin stubs.
OpenAI explicitly calls that advisory. Good. A process can ignore proxy variables and open sockets directly. That sentence should be pinned above every AI-agent security dashboard. A lot of “sandboxing” still relies on convention: hope the tool respects env vars, hope the agent stays inside the expected path, hope the user notices the suspicious command. Hope is not a boundary. It is a bug report waiting for a creative reproducer.
The final design moved toward dedicated sandbox Windows users, a setup binary named codex-windows-sandbox-setup.exe for elevated setup work, a runner binary named codex-command-runner.exe to launch restricted commands from the sandbox-user side of the boundary, and the normal codex.exe harness remaining unelevated. That split is boring in exactly the right way. Privileged setup should be explicit. Long-running harness logic should not carry more authority than it needs. Command execution should cross a narrow, inspectable boundary rather than smearing privilege across the whole app.
This is also why the post reads less like a finished announcement and more like a public postmortem written before the incident. OpenAI’s release notes show the Windows sandbox is still being maintained: the May 8/12 Codex release train includes a fix where Windows sandbox setup grants sandbox users access to the desktop runtime binary cache. That sounds tiny until you remember that compatibility is where local security boundaries go to die by a thousand exceptions. Binary caches, package managers, symlinks, junctions, endpoint security products, roaming profiles, corporate Windows images, WSL2 expectations — every one of these can become a reason a frustrated developer reaches for Full Access mode.
That is the actual product challenge. A sandbox that is secure but constantly breaks tests will be bypassed. A sandbox that never breaks anything is probably not enforcing enough. The only viable path is a boundary that is understandable, narrow, observable, and easy to extend intentionally rather than accidentally.
The rollout checklist is mostly questions
For practitioners, the action item is not to become a Windows token expert. It is to audit what your coding-agent setup assumes the operating system is enforcing.
Ask these questions on every platform: What can the agent read by default? What can it write by default? Are hidden agent instructions and Git metadata protected? Is network access actually blocked by the OS or merely discouraged by environment variables? Do child processes inherit the same boundary? Can package managers, test runners, spawned shells, and generated binaries escape the intended policy? Which approvals are human-reviewed, which are auto-reviewed, and which actions never surface because the default permissions are already too broad?
If the answer is “we trust the model not to,” you do not have a sandbox. You have a polite shell.
Teams rolling Codex out on Windows should be conservative for the next few release trains. Test native Windows and WSL2 separately. Test corporate endpoint security. Test unusual home-directory layouts, symlinks and junctions, package-manager caches, language-specific toolchains, and repos with large generated outputs. Keep Full Access mode exceptional. Treat sandbox setup prompts as infrastructure changes, not UI noise. If workflows need network access, approve narrowly: specific registry, specific command, specific time window. “The internet, because tests failed once” is not a policy.
The larger lesson is that coding agents are making local developer environments look more like production runtimes. They need identity, least privilege, network policy, protected configuration, auditability, and patchable harness components. OpenAI’s Windows sandbox is not just a Windows feature. It is a public admission that agent UX and OS security now have to be designed together.
Looks good to me — pending the usual Windows edge cases, which will file themselves as issues by morning.
Sources: OpenAI, OpenAI Codex Security, OpenAI Codex releases, Microsoft Learn