用 smolvm 隔离运行不可信 Python 与 JavaScript

目标：给用户代码一个受控执行环境

这项实验考察了 smolmachines / smolvm 是否适合充当快速、安全的代码沙箱，用于运行用户提交的 Python 和 JavaScript，例如执行数据转换任务。

希望实现的隔离条件包括：

• 限制可使用的 RAM；
• 限制 CPU 执行时间，避免 while true 等无限循环持续占用资源；
• 禁止网络访问；
• 文件系统只能访问明确指定的文件。

第一个障碍：测试环境没有 KVM

实验最初由运行在 Claude Code for web 中的 Claude Fable 5 执行，但很快遇到了基础设施限制。

当时的容器环境为 Linux 6.18.5-fc-v20，本身运行在 Firecracker 虚拟机中，配置为 4 vCPU、15GB RAM，但没有 /dev/kvm，CPU 也没有暴露 vmx 或 svm 标志，因此无法进行嵌套虚拟化。

结果，执行 smolvm machine run 时如预期失败，并提示 kvm not available。

这意味着问题并非 smolvm 本身已经被证明不可用，而是当前测试环境缺少运行它所需要的虚拟化能力。

替代方案：把测试搬到 GitHub Actions

面对这一限制，实验改用了 GitHub Actions 的 Ubuntu runner，因为该环境可以提供 /dev/kvm。

具体做法是在测试分支中临时加入 GitHub Actions workflow，在 runner 内安装 smolvm，然后直接运行准备好的测试脚本并收集日志，最终再移除临时 workflow。

这种处理方式绕开了 Claude Code for web 无法使用 KVM 的限制，让原本无法在当前容器中执行的 smolvm 测试得以继续。

值得关注的工程思路

这次记录的重点不仅是 smolvm 的沙箱能力，也展示了代码 Agent 面对执行环境限制时的一种处理模式：当本地执行环境缺少必要的底层能力时，将测试迁移到具备对应能力的 CI 基础设施。

不过，仅凭这段记录还不能得出 smolvm 已经满足所有不可信代码执行安全要求的结论。这里能够确认的是：研究目标覆盖了 CPU、内存、网络和文件访问限制，并且在发现原环境缺少 KVM 后，测试被迁移到了支持 /dev/kvm 的 GitHub Actions runner。