If you’re building anything with AI agents that write and run code, you’ve probably hit the same wall everyone else has: how do you let the thing actually execute what it writes without worrying it’ll spin up an infinite loop, phone home to weird APIs, or eat your entire EC2 budget?

This isn’t theoretical anymore. Simon Willison spent part of this week putting smolmachines through its paces, specifically testing whether it could sandbox untrusted Python and JavaScript in a way that actually holds up. The constraints he’s looking for are practical: limit RAM and CPU time (so a while true doesn’t wreck your day), kill network access, and restrict filesystem access to specific files.

smolmachines (built on smolvm) is one of several projects trying to solve this right now. The pitch is fast, secure sandboxing with resource limits baked in. Willison tasked Claude with researching it, which is itself kind of meta, but the underlying question matters. If agents are going to write and test their own code, the sandbox can’t be an afterthought.

Why this matters now

The context here is that LLMs have gotten good enough at writing code that people are actually shipping tools where the AI writes something and then runs it. GitHub’s Copilot app just added a “My work” pane to help you track multiple sessions. Replit rolled out Free Mode powered by GPT-5.6 Luna so anyone can “turn ideas into working software” without worrying about token costs. OneCLI, a Y Combinator company, just launched as an open-source “sandboxed agent harness for teams.”

All of these need the same thing: a way to run code that doesn’t trust the code.

The traditional approach is spinning up containers or VMs, but that’s slow and expensive if you’re doing it thousands of times a day per user. WebAssembly sandboxes are faster but come with their own set of constraints. What people want is something that’s fast, actually secure, and doesn’t require a PhD in syscalls to configure.

The extensibility angle

There’s a related idea gaining traction: what if apps became radically extensible, and LLMs just wrote the extensions on the fly?

Jeremy Morrell wrote about this recently, arguing that “modern sandbox primitives lower the deployment cost and provide good security boundaries.” His thesis is that you can build a solid core app and let users extend it in any direction by having LLMs fill in the gaps. The sandbox is what makes this safe.

Someone even filed a feature request for Claude Code to support an AGENTS.md file, which would presumably let you define custom agent behaviors in a standardized way. It’s issue #6235 if you want to follow along.

The pattern here is clear: people want to give LLMs more freedom to write and run code, but only if there’s a fence around the playground.

What “good enough” looks like

A working sandbox for agent-generated code needs to handle a few things well:

Resource limits that actually work. If the agent writes while True: pass, the sandbox should kill it in milliseconds, not after your CPU fans start screaming. Same for memory. Same for execution time.

No network access by default. Unless you explicitly allow it, the code shouldn’t be able to phone home. This rules out a lot of supply chain attacks and data exfiltration.

Filesystem isolation. The code should only touch files you’ve designated. Not your .env file. Not your SSH keys. Just the specific directory or files you’ve allowed.

Fast startup. If it takes two seconds to spin up the sandbox, the agent workflow feels broken. It needs to be near-instant.

Some of this exists already. Browser-based sandboxes using Web Workers or iframes can handle JavaScript pretty well. Python is harder. Running actual system-level code is harder still.

Where this is heading

The next few months are going to be full of people trying different approaches. Some will use WebAssembly. Some will layer on seccomp filters and cgroups. Some will just say “run it in a Docker container and hope for the best.”

What’s interesting is that this isn’t an infrastructure problem disguised as an AI problem. It’s both. The better the sandbox, the more powerful the agent can be. And the more powerful the agent, the more you need a sandbox you can actually trust.

Right now, most people are still figuring out which tradeoffs they can live with. Speed vs. security. Flexibility vs. isolation. Ease of setup vs. actual guarantees.

If you’re building something in this space, the question isn’t whether you need a sandbox. It’s which one you’re going to pick, and whether it’ll still feel like the right choice six months from now when everyone’s agents are doing twice as much.