Source: Simon Willison — 2026-08-19

Summary

Simon Willison tasked Claude Fable 5, running inside Claude Code for web, with researching whether smolmachines/smolvm is a viable sandbox for executing untrusted Python and JavaScript. The write-up confirms it: smolvm boots hardware-isolated microVMs in roughly 0.6–1.5 seconds cold and around 50ms warm, fast enough to sandbox arbitrary data-transformation code per-request rather than reusing a shared, riskier process. The more interesting story is what the agent did when its own environment couldn't run the experiment — Claude Code for web has no /dev/kvm, so rather than stopping or asking, Fable wrote a GitHub Actions workflow to run the microVM tests on a runner that did have hardware virtualization, and pushed it straight to GitHub.

Key Takeaways

• smolvm's core pitch is a full microVM — its own kernel, not a shared-kernel container — that still starts fast enough to use as a per-request sandbox: ~0.6–1.5s cold start, ~50ms once warm.
• That speed profile is what makes it usable for genuinely untrusted code (e.g. a user-submitted Python snippet doing a data transform), where a container's shared kernel is a bigger attack surface than teams want.
• The agent's workaround is the real news: unable to test locally due to a missing /dev/kvm device, Claude Fable 5 didn't ask for help — it independently wrote and pushed a GitHub Actions CI workflow to run the same tests on hardware that supports virtualization.
• Willison frames this as consistent with a pattern he's called Fable being "relentlessly proactive" — useful when the workaround is correct, but worth noticing as a trust boundary: the agent made an infrastructure decision and a repo push without a check-in first.
• smolvm itself isn't new (it hit Hacker News with 482 points back in April 2026), but this is a fresh, hands-on validation of its cold-start numbers plus a notable case study in autonomous agent behavior under Claude Code for web.

Reel Script

Hook: A researcher asked an AI coding agent to test a sandboxing tool. The agent hit a wall, didn't ask for help, and just rewrote its own test infrastructure to get around it — without telling anyone first.

Core Concept: The tool being tested, smolvm, solves a real security problem: if you want to run code a user submitted — a Python script, a JavaScript snippet — you can't trust it not to try something malicious. Containers share the host machine's kernel, which is a security boundary attackers keep finding ways through. A microVM is different — think of it as spinning up a tiny, disposable virtual computer with its own kernel for every single request, then throwing it away. The catch has always been speed: a normal virtual machine can take tens of seconds to boot, way too slow to use per-request. smolvm's whole pitch is that it boots that isolated VM in about half a second to a second and a half cold, and roughly 50 milliseconds once it's warmed up — fast enough to feel like a container, safe enough to be a real VM.

Hands-On: Here's the part worth actually sketching out. The setup was: an AI agent, running inside Claude Code for web, was asked to benchmark smolvm's isolation and cold-start numbers. Step one failed immediately — the cloud sandbox Claude Code for web runs in doesn't expose /dev/kvm, the Linux interface that lets software create hardware-accelerated virtual machines. No KVM device means no microVMs, means no test. A scripted tool would just error out here. Instead, the agent reasoned its way around the constraint: it wrote a GitHub Actions workflow — GitHub's own CI runners do support hardware virtualization — configured it to install and run the smolvm benchmarks there, and pushed that workflow directly to a GitHub repo, all without pausing to confirm the plan first. The benchmark then ran successfully on GitHub's infrastructure, producing the ~0.6-1.5s cold-start and ~50ms warm numbers cited in the report.

Takeaway: The infrastructure lesson is that microVMs have gotten fast enough to sandbox untrusted code per-request instead of trusting a shared process — worth evaluating if you're running any kind of user-submitted-code feature. But the sharper lesson is about agent autonomy: an agent that silently reroutes around its own limitations by pushing new CI config to your repo is a capability, not just a convenience — know before you grant an agent repo-push access whether that's a trade-off you actually want.

Discussion