OpenAI’s Codex Windows Sandbox Is the Rare Security Post Worth Reading Because It Admits the First Design Was Not Enough.

The useful thing about OpenAI’s Windows sandbox post is not that Codex now has a safer path on Windows. That matters, but it is table stakes. The useful thing is that OpenAI admits the first design was not enough.

That is rare in vendor security writing. Most posts turn architecture into a victory lap: here is the box, here is the diagram, please clap. This one is more interesting because it shows the false start: a plausible unelevated Windows sandbox built from synthetic SIDs, ACLs, write-restricted tokens, and environment-variable network blocking — then rejected because the network boundary was advisory. In coding-agent security, “advisory” is a synonym for “the attacker gets a vote.”

Codex’s default mode is meant to let the agent read broadly, write inside the current workspace, and avoid internet access unless the user asks for it. That is the right product shape. A coding agent that needs approval for every harmless read becomes a modal-dialog generator. A coding agent with full access to the host becomes an intern with your SSH keys and too much confidence. The hard part is making the middle path real on Windows.

Windows did not have the sandbox shape Codex needed

OpenAI says it evaluated AppContainer, Windows Sandbox, and Mandatory Integrity Control before building its own implementation. Each option failed for a different reason, and the failures are a useful checklist for anyone trying to secure local agents.

AppContainer provides a real Windows isolation model, but it is designed for apps that know their access needs up front. Codex is not that. It drives arbitrary developer workflows: shells, Git, Python, package managers, build tools, and whatever project-specific executable the repository requires. A capability model that works for a tightly scoped app does not map cleanly onto “let this agent behave like a developer inside a messy repo.”

Windows Sandbox had the opposite problem. It gives a strong disposable environment, but Codex needs to operate on the user’s actual checkout, tools, and local development context. A throwaway desktop with host/guest bridging is a much heavier product than an agent sitting in the terminal or IDE. It also is not available on Windows Home SKUs, which matters if the goal is broad developer adoption rather than a security architecture demo.

Mandatory Integrity Control looked elegant: run Codex at low integrity, mark writable roots accordingly, and let Windows enforce the boundary. The catch is that integrity labels mutate the trust semantics of the real host filesystem. Marking the checkout low integrity does not merely say “Codex can write here.” It says low-integrity processes generally can write there. For a real developer machine, that is a broad and uncomfortable change to make just so an agent can edit files.

The first prototype was clever. OpenAI created a synthetic sandbox-write SID, granted it write/execute/delete access to the working directory and configured writable roots, explicitly denied writes to sensitive paths like .git, .codex, and .agents, and launched commands under a write-restricted token. Windows would require both the normal user identity and one of the restricted SIDs to pass write checks. That gives fine-grained filesystem control without requiring every developer to be an admin.

Then came network access. The unelevated design tried to poison the obvious routes: 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. OpenAI also describes PATH tricks to make stub SSH/SCP commands resolve before the real binaries.

That catches normal tool behavior. It does not stop adversarial behavior. A process can ignore proxy variables, bypass PATH, or open sockets directly. If the threat model includes malicious dependency scripts, prompt-injected commands, or compromised build tools, “most package managers will probably behave” is not a boundary. It is a preference expressed through environment variables.

The real lesson is layered control, not one magic sandbox

OpenAI’s final architecture moves to dedicated offline and online sandbox users, elevated setup through codex-windows-sandbox-setup.exe, a separate codex-command-runner.exe, restricted-token spawning from inside the sandbox-user boundary, Windows Firewall policy, and DPAPI separation. That is less convenient than the unelevated prototype. It is also closer to the kind of boring security engineering coding agents require.

For practitioners, the takeaway is to stop collapsing three different controls into one word: approvals, filesystem isolation, and network isolation. Approval policy decides when a human is interrupted. Filesystem isolation decides what the process can mutate if the model or toolchain goes sideways. Network isolation decides whether a compromised process can exfiltrate secrets. You need all three, and they fail in different ways.

This matters beyond Codex. Copilot CLI, Claude Code, Gemini CLI, Cursor-style agents, local MCP tools, and CI-based agent automation all face the same shape of problem. Once an agent can run commands, the model is no longer the only thing in scope. The package manager, test runner, shell scripts, postinstall hooks, MCP servers, repo instructions, and generated commands all become part of the execution environment. The sandbox has to constrain the process tree, not just the chatbot.

The protected .git, .codex, and .agents paths are especially telling. Agent metadata is now control-plane infrastructure. If an agent can rewrite the instructions that guide its future behavior, mutate Git state in subtle ways, or alter its own local configuration, you have a governance loop with no adult in the room. Teams should treat agent instruction files, MCP configuration, workflow definitions, and sandbox policy as sensitive code. Require review. Assign owners. Log changes. Do not leave the steering wheel in the back seat.

For Azure and Microsoft-heavy shops, this post also raises the bar for procurement. “Runs on Windows” is not sufficient. Ask how the tool constrains writes, how network access is blocked, whether rules are OS-enforced or advisory, how credentials are stored, what approval modes exist, what gets logged, whether telemetry can export through OpenTelemetry or your SIEM path, and whether CI automation uses a stricter policy profile than interactive developer sessions. If the answer is mostly vibes and a settings page, keep asking.

The uncomfortable truth is that coding agents are becoming developer tooling infrastructure faster than the security model is becoming common knowledge. OpenAI’s post is useful because it shows the work underneath the demo: rejected primitives, prototype tradeoffs, advisory controls thrown away, and a final design that accepts Windows sandboxing as product-specific systems engineering. That is what serious agent tooling looks like. Not perfect. Not magical. Just honest enough to be useful.

Sources: OpenAI, OpenAI Running Codex Safely, Codex changelog, OpenAI Codex GitHub