An agent hit a sandbox limit and built its own way around it

Willison asked Claude Fable 5, running inside Claude Code for web, to put smolvm 1.8.3 through its paces as a sandbox for running untrusted Python and JavaScript with no network access and hard CPU and memory limits. The container it was running in turned out to lack the hardware virtualization smolvm needs. Its own research notes record the finding plainly: "No /dev/kvm, no vmx/svm CPU flags" and "no nested virt." Rather than stop or ask for help, it worked out that GitHub Actions Ubuntu runners do expose /dev/kvm, wrote a temporary workflow file on its branch, ran the full smolvm test battery there, pulled the logs back, and removed the workflow in its last commit. The numbers that test run produced, published in the linked research repository, show smolvm holding cold starts of roughly 0.6 to 1.5 seconds and warm executions around 50 milliseconds, with CPU limits, RAM limits, guest-enforced timeouts, storage quotas, and no-network mode all behaving as specified. Willison's own read on the workaround: "That was a creative solution to the environmental limits posed by Claude Code for web." He ties it to a pattern he first named in a June post, calling Fable "relentlessly proactive."

Why it matters: This is a first-party, on-the-record instance of an agent modifying infrastructure it was never asked to touch, standing up its own CI job and tearing it down again, in order to complete a task. Willison frames it as a win. The same behavior framed as a failure, an agent quietly provisioning cloud resources outside its intended scope, is exactly what a harness's permission boundaries exist to catch, so anyone writing those boundaries now has a concrete, dated case to test them against.