Glonce

Claude Fable 5 finds no /dev/kvm, routes sandbox tests through GitHub Actions

agentsThe Glonce editorsSimon Willison🔥62Glonce rating62Impact55Novelty50Relevance85Surprise45Players65Credibility85

The author set Claude Fable 5, running inside Claude Code for web, a research task: put smolmachines.com through its paces as a fast, secure sandbox, and work out what it would take to run untrusted Python and JavaScript code inside it with limits on RAM and CPU time (protection against a runaway 'while true' loop), no network access, and filesystem access restricted to designated files. The stated goal was to use such a sandbox to execute user-provided tasks, for example data transformations.

Claude Fable 5 ran into an obstacle right away. Its own Claude Code for web container turned out to be a Firecracker virtual machine itself, running Linux 6.18.5-fc-v20, with 4 vCPUs and 15GB of RAM, but with no /dev/kvm device and no vmx or svm CPU flags, meaning the container has no nested virtualization available. Since smolvm, the command-line tool used to test smolmachines.com, needs to create its own virtual machine to run a sandboxed job, the attempt failed straight away with the error 'kvm not available'.

Rather than stop at that error, Claude Fable 5 worked out a Plan B on its own: GitHub Actions' Ubuntu-hosted runners do expose /dev/kvm. It pushed a temporary GitHub Actions workflow to the branch it was working on, used that runner to actually run the real smolvm test battery, collected the resulting logs, and then removed the temporary workflow again as part of its final commit.

The author, who watched the process, called it 'a creative solution to the environmental limits posed by Claude Code for web' and cited it as another example of Fable being 'relentlessly proactive': faced with an infrastructure wall inside its own sandbox rather than a bug in the task itself, the model found a different environment that could do the job and used it, instead of just reporting back that the test could not be run.

Key facts

  • The author asked Claude Fable 5, running in Claude Code for web, to evaluate smolmachines.com as a sandbox for running untrusted Python and JavaScript with capped RAM and CPU time, no network access, and filesystem access limited to designated files, with the eventual goal of running user-provided tasks such as data transformations.
  • Claude Fable 5's own container turned out to be a Firecracker VM running Linux 6.18.5-fc-v20 with 4 vCPUs and 15GB of RAM, but with no /dev/kvm device and no vmx or svm CPU flags, so it could not run nested virtualization and smolvm failed immediately with 'kvm not available'.
  • As Plan B, Claude Fable 5 pushed a temporary GitHub Actions workflow to its branch to use Ubuntu runners, which do expose /dev/kvm, to run the actual smolvm test battery, then collected the logs and removed the workflow in its final commit.
  • The author called the workaround 'a creative solution to the environmental limits posed by Claude Code for web' and described it as another example of Fable being 'relentlessly proactive'.

Why it matters

The episode is a small, concrete case of how an AI coding agent handles a hard infrastructure wall rather than a plain logic bug. Claude Fable 5 was set a task that needed nested virtualization, found that its own sandbox could not provide it, and instead of stopping there it identified a different environment, GitHub Actions, that could, then ran the real tests there and reported back. The person who set the task calls the move 'a creative solution to the environmental limits posed by Claude Code for web' and 'another example of Fable being relentlessly proactive', framing it as the kind of self-directed problem solving expected from an agentic coding assistant.

Who it affects

Anyone using Claude Fable 5 or a similar coding agent inside Claude Code for web to research or configure infrastructure tools that themselves need virtualization runs into the same wall: no /dev/kvm, no vmx or svm CPU flags, so nothing that needs nested virtualization can run directly in that container. It also affects anyone evaluating smolmachines and smolvm specifically as a sandbox for untrusted code, since a human trying the same setup inside Claude Code for web would hit the identical 'kvm not available' error.

How to use it

The workaround itself is a reusable pattern rather than a product feature: when an agent's own container cannot provide the virtualization a tool needs, it can push a temporary CI workflow to the branch it is working on, run the real test on a runner that does have /dev/kvm (GitHub Actions' Ubuntu runners, in this case), pull the resulting logs back, and then delete the temporary workflow as part of its final commit so nothing extra is left behind in the repository.

How solid is it

The account is first-person: the person who set the task watched Claude Fable 5 work and quotes its own notes verbatim, including the exact kernel version, vCPU and RAM figures, and the literal 'kvm not available' error, which reads like genuine debug output rather than a summary. It is a single source with no independent confirmation. The text does not say whether the RAM, CPU, network and filesystem restrictions actually held up once the tests ran under GitHub Actions' kvm-enabled runners, only that the workflow was used to run them and that logs were collected.

Risks and caveats

The text does not give a version number for smolmachines or the smolvm tool, and it does not spell out the exact relationship between the smolmachines.com service and the smolvm command-line tool used to test it. It also does not describe a specific data-transformation task or other concrete user-provided example beyond the general goal stated at the start of the task.

“That was a creative solution to the environmental limits posed by Claude Code for web.”

— the author