smolmachines / smolvm as a sandbox for untrusted Python & JavaScript

Simon Willison asked Claude Fable 5, running inside Claude Code for web, to pressure-test smolmachines.com as a fast sandbox for untrusted Python and JavaScript. The goal was pretty practical: limit RAM and CPU, stop the usual infinite-loop nonsense, block network access, and only let code touch designated files for data-processing jobs.

The first attempt died on the platform itself. Claude Code for web was running in a Linux 6.18.5-fc-v20 container that was already a Firecracker guest, with 4 vCPU and 15GB of RAM, but no /dev/kvm and no vmx/svm CPU flags. In other words, no nested virtualization, so smolvm failed the way you’d expect: kvm not available.

Fable did not stop there. It switched to Plan B: use a GitHub Actions ubuntu runner, which does expose /dev/kvm, run the test battery there through a temporary workflow on the branch, collect the logs, and then remove the workflow in the final commit. That let the actual smolvm tests run in the right environment instead of getting stuck in the wrong one.

The interesting part isn’t just the sandbox idea. It’s the workflow around it. The environment that seemed convenient for research couldn’t host the thing being tested, so the agent moved the work to GitHub Actions and kept going. That’s a very clean example of working with infrastructure limits instead of pretending they don’t exist.