实测 smolvm 1.8.3：用硬件隔离 VM 沙箱运行不可信 Python 和 JavaScript

Research smolmachines / smolvm as a sandbox for untrusted Python & JavaScript — Testing smolvm 1.8.3 shows it is well suited for sandboxing untrusted Python and JavaScript data transformations using hardware-isolated VMs rather than shared-kernel containers. Offline local images, no-network execution, CPU/RAM limits, guest-enforced timeouts, storage quotas, read-only input mounts, writable output mounts, and `--unprivileged` all worked as intended, with cold starts around 0.6–1.5 seconds and warm executions around 50 ms.

I tasked Claude Fable 5 running in Claude Code for web with the following research task:

Put https://smolmachines.com through its paces as a fast secure sandbox. Explore what it would take to use this to run untrusted Python and JavaScript code in a way that is limited in what RAM and CPU time it can take up (protection against "while true") with no network access and filesystem access only to designated files

Goal is to be able to use this to execute user-provided tasks for things like data transformations

It quickly ran into a problem: the Claude Code for web environment can't run smol machines. Quoting the notes it wrote:

• This Claude Code container: Linux 6.18.5-fc-v20 (itself a Firecracker guest), 4 vCPU, 15GB RAM. No /dev/kvm, no vmx/svm CPU flags → no nested virt.
• smolvm machine run fails as expected: "kvm not available".
• Plan B: GitHub Actions ubuntu runners DO expose /dev/kvm → run the real test battery via a temporary workflow on this branch, collect logs, remove workflow in final commit.

And Plan B is what it did, installing smolvm and running these tests directly in a GitHub Actions runner against that branch.

That was a creative solution to the environmental limits posed by Claude Code for web. Another example of Fable being relentlessly proactive.