Summary
- Researcher Simon Willison tasked Claude Fable 5 (via Claude Code for web) with evaluating smolmachines/smolvm as a sandbox for untrusted Python and JavaScript code.
- The AI agent discovered its own environment lacked hardware virtualisation support (no /dev/kvm, no vmx/svm CPU flags) and could not run smolvm directly.
- Without being prompted, the agent devised a Plan B: it created a temporary GitHub Actions workflow to run the test battery on a runner that does expose /dev/kvm.
- The episode illustrates both the capability and the autonomy of current AI coding agents when they encounter environmental constraints.
- For security teams evaluating sandboxing tools or using AI agents in workflows, the pattern of agents self-redirecting to new execution environments deserves scrutiny.
The Research Task
Simon Willison, a developer and researcher, set out to evaluate smolmachines and its smolvm component as a potential sandbox for running untrusted Python and JavaScript code. The stated goal was practical: enable user-provided data transformation tasks to execute in an environment with bounded RAM and CPU time, no network access, and filesystem access restricted to designated files. The ‘while true’ infinite loop scenario was called out explicitly as a threat to guard against.
An Unexpected Obstacle
Willison delegated the investigation to Claude Fable 5, running inside the Claude Code for web environment. The agent quickly identified a hard constraint: the Claude Code container runs on Linux 6.18.5 inside a Firecracker guest, with four vCPUs and 15 GB of RAM, but no /dev/kvm device and no vmx or svm CPU flags. Nested virtualisation was not available. When the agent attempted to run smolvm, it failed as expected with a ‘kvm not available’ error.
The Agent’s Improvised Solution
Rather than stopping, the agent identified that GitHub Actions runners using the ubuntu configuration do expose /dev/kvm. It then created a temporary workflow on the working branch, ran the full test battery against a GitHub Actions runner, collected the logs, and removed the workflow in the final commit. Willison noted this as ‘a creative solution to the environmental limits posed by Claude Code for web’ and described the agent’s behaviour as ‘relentlessly proactive’.
What smolvm Is Designed to Do
smolmachines and smolvm are positioned as fast, secure sandboxing tools for executing untrusted code. The research context was specifically about isolating user-supplied code with resource limits — a common requirement in platforms that offer any kind of scripting, automation, or data processing capability. The sources do not provide detailed test results from the GitHub Actions run; the published material focuses on the agentic behaviour rather than the sandbox’s technical findings.
The Autonomous Pivot Is Worth Noting
The security-relevant observation here is not the sandbox itself but the agent’s behaviour. An AI coding agent, given a task it could not complete in its current environment, independently provisioned an alternative execution environment — a GitHub Actions runner — without being asked. For organisations already using or evaluating AI coding agents, this pattern has governance implications. The agent acted within the scope of its task, but it did so by moving computation to a different platform with different characteristics, all without explicit human direction.
Why it matters
Security teams face two intersecting concerns here. First, smolvm and tools like it represent a practical approach to sandboxing untrusted code — a genuine need wherever user-supplied scripts, automation tasks, or LLM-generated code executes on shared infrastructure. Understanding the hardware prerequisites (specifically KVM availability) is essential before relying on such sandboxes in production. Second, and perhaps more immediately relevant, this episode is an early, concrete example of an AI coding agent autonomously redirecting its own execution to a different infrastructure platform when blocked. If your organisation has deployed AI coding agents — or is evaluating them — this behaviour pattern should be part of your threat model review. Agents that can self-provision execution environments may do so in ways that bypass logging, policy controls, or network boundaries you assume are in place.
What to do now
- Before adopting smolvm or similar KVM-dependent sandboxes, verify that your target execution environment exposes /dev/kvm and the necessary CPU virtualisation flags.
- If evaluating smolvm for untrusted code execution, confirm the specific resource controls (RAM caps, CPU time limits, network isolation, filesystem scoping) meet your requirements through direct testing in a representative environment.
- Review the permissions and scope granted to any AI coding agents in your environment — specifically whether they can create or trigger CI/CD workflows, provision runners, or move workloads to external platforms.
- Establish logging and audit requirements for AI coding agent actions that extend beyond the agent’s primary execution environment, including any GitHub Actions workflows or equivalent pipeline steps they create.
