Running a coding agent on Linux is a solved problem, more or less. You spin up a container, lock down the network, give it a scratch filesystem, and let it go. The agent writes code, runs it, fails, tries again. If it does something stupid, the container dies and nothing of consequence was lost.

Windows is a different story. There’s no Docker-for-Windows equivalent that gives you clean, fast, throwaway Linux-style containers with proper kernel isolation. The filesystem assumptions are different. The network stack is different. Windows processes have their tentacles in places that would make a Linux kernel dev visibly uncomfortable. Which is why OpenAI’s writeup on how they built a sandbox for Codex on Windows is worth reading carefully, even if you don’t use Windows yourself.

The Actual Problem

The core challenge with any coding agent sandbox isn’t just “can the agent break out of the box.” It’s more subtle than that. You need the agent to have enough access to actually do useful work, which means reading your project files, running your toolchain, maybe making network calls to fetch packages. But you also need to make sure it can’t wander into system territory, exfiltrate data through the network, or leave persistent side effects that survive beyond the session.

On Linux, containers handle this with a combination of namespaces, cgroups, and a constrained syscall surface via seccomp. The primitives are composable and well-understood. Windows doesn’t give you those primitives in the same form. Microsoft has Windows Sandbox, a lightweight VM-based isolation feature built into Windows 10 and 11, but “lightweight” is relative, and the controls for things like selective file access and network filtering require more careful construction than a Docker run flag.

OpenAI’s approach involves layered controls: managed file access that determines exactly which paths the agent can read or write, network restrictions that allow outbound calls for things like package installs while blocking arbitrary exfiltration, and careful scoping so the agent’s workspace is genuinely isolated from the rest of the system. The details matter here because the threat model for a coding agent isn’t just “what if the model goes rogue.” It’s also “what if a malicious prompt tricks the agent into doing something it shouldn’t.” Prompt injection through code comments or documentation is a real attack vector, and a well-constructed sandbox means that even if it works, the blast radius is limited.

Why This Matters Beyond Windows

The interesting thing about this work is that it signals OpenAI treating Codex as infrastructure rather than a demo. Building a proper sandbox for Windows is not glamorous engineering. It’s the kind of thing you do when you’re committing to a platform long-term, when you need it to be reliable and safe for developers who aren’t going to spend time auditing what the agent does to their system.

The Linux version of this problem was already handled. Windows represents a huge chunk of professional developers, though, particularly in enterprise environments, financial services, game dev, and anywhere that Microsoft’s ecosystem runs deep. If Codex can’t run safely on Windows, it’s a product that doesn’t exist for a significant portion of its potential users.

Willison Already Put It to Work

While OpenAI was writing up the architecture, Simon Willison was doing what Willison does, which is using new tools immediately on real projects and telling you exactly what happened.

He used Codex desktop to build the new Datasette blog, and the detail worth noting in his writeup isn’t just “the AI wrote some code.” It’s that he specifically called out the Markdown session transcript export as the feature he’d “always wanted.” That’s a developer noting something specific about their workflow, not a landing-page endorsement.

Session transcripts matter because they’re the diff of what the agent actually did. When you’re using an AI to build something, you’re not just getting the output, you’re implicitly trusting a process you didn’t fully observe. Being able to export a readable record of what Codex did, what decisions it made, what it changed and why, turns an opaque operation into something you can audit, share, or reference later. It’s the difference between “the agent built this” and “here’s exactly what the agent built and how.” For a project like Datasette, which is serious open source infrastructure used by thousands of developers, that kind of transparency isn’t optional.

Willison linked the actual session that built the blog, which is the kind of show-your-work move that makes his takes on AI tooling more credible than most. He’s not saying Codex is great. He’s saying here’s the specific thing I did, here’s the tool I used, here’s the artifact.

On Counting Agents

Boris Mann put something cleanly this week: “11 AI agents is meaningless as a phrase. If I said ‘I have 11 spreadsheets’ or ‘I have 11 browser tabs’ to do my work, it means about the same thing.”

This is worth sitting with. The current tendency to count agents, to announce “we’re using X agents in our pipeline” as a measure of sophistication, confuses quantity for architecture. What matters about a coding agent isn’t how many of them you have running. It’s whether they can actually do the work safely, reliably, in the environments where your code actually lives.

The Windows sandbox work is a good example of what actually hard agent infrastructure looks like. It’s not a flashy capability announcement. It’s the patient engineering work of making the thing trustworthy enough to use in production, on the operating system that a huge chunk of the industry actually runs.

The Takeaway

Coding agents are settling into something more like toolchain components and less like experimental demos. When OpenAI publishes detailed architecture writeups on Windows sandboxing, and when developers like Willison are using these tools for real projects and publishing their session transcripts, the technology is past the “should I pay attention to this” threshold.

The questions worth asking now are more practical: What does the sandbox actually cost in terms of performance overhead? How does selective file access interact with monorepos where your project has dependencies scattered across the filesystem? How does the network filtering handle the difference between “fetch this npm package” and “post this file to an external endpoint”?

Those are questions for testing, not theorizing. The good news is the sandbox exists on Windows now. You can actually run the experiment.