smolvm 1.8.3 passes sandbox test for untrusted Python and JavaScript
Testing of smolvm 1.8.3 shows the hardware-isolated VM tool can reliably sandbox untrusted Python and JavaScript code with enforced CPU, RAM, network, and filesystem limits.

👁 114 reads
Testing of smolvm 1.8.3 published on 19 August 2026 confirms the tool is well suited for sandboxing untrusted Python and JavaScript data transformations, with cold starts between 0.6 and 1.5 seconds and warm executions around 50 ms.
- smolvm 1.8.3 cold starts run 0.6-1.5 seconds; warm executions around 50 ms
- All tested controls worked: no-network execution, CPU/RAM limits, storage quotas, read-only input mounts, and guest-enforced timeouts
- Claude Fable 5 in Claude Code for web hit a nested virtualisation wall and independently routed tests through GitHub Actions runners that expose /dev/kvm
The evaluation, documented by Simon Willison, put smolvm through a battery of security-relevant controls: offline local images, no-network execution, CPU and RAM limits, guest-enforced timeouts, storage quotas, read-only input mounts, writable output mounts, and the --unprivileged flag. All worked as intended. The tool uses hardware-isolated VMs rather than shared-kernel containers, which is the architectural choice that makes the isolation credible for genuinely untrusted code.
The test was driven by Claude Fable 5 running inside Claude Code for web, which was given a research task: establish whether smolmachines could run user-provided data-transformation tasks with strict resource limits and no network or unrestricted filesystem access. The agent quickly found an obstacle. Claude Code for web runs inside a Firecracker guest - a Linux 6.18.5 environment with 4 vCPU and 15 GB RAM - that exposes no /dev/kvm and no vmx or svm CPU flags, making nested virtualisation impossible. Attempting smolvm machine run failed with the error “kvm not available”.
Rather than stopping, the agent devised a workaround: GitHub Actions ubuntu runners do expose /dev/kvm. It created a temporary workflow on a branch, ran the full test battery there, collected the logs, and removed the workflow in the final commit. The approach succeeded, producing the benchmark figures quoted above.
Another example of Fable being relentlessly proactive.
For developers building AI tools that execute user-supplied code - data pipelines, no-code automation, agent tool use - smolvm now has concrete numbers behind its security claims. The 50 ms warm-execution figure is fast enough for interactive use, and the agent-driven workaround is a practical reminder that coding agents can route around environment limits when given sufficient autonomy, which is worth accounting for in your own sandboxing designs.
Google · Your sourcesQuantslant higher in your Google - one clickAdd to preferred sources →More on this from QUANTSLANT
ai tools·Google Adds Student Hub, Deep Research, Free AI Pro for Students

