devvm：每个项目一台 VM，给 agent 一个干净沙箱

HN 上 120 分、51 条评论（"Devvm.dev: One VM for every project"）的一个新项目：devvm——给每个项目一台隔离的 VM 沙箱，预装该项目需要的工具链，官方定位一句话："ready for you or a coding agent to start coding"——给人或 coding agent 一个干净的编码环境。

先给体量一个准数：仓库 devvmhq/devvm，MIT 协议，2026 年 11 月 6 日创建——昨天；GitHub API 快照（11 月 7 日上午）176 星。非常早期，下文一切都按"刚出生的项目"来看。

它怎么做（仓库与官网可核验部分）

• 底层是 Lima 的 VM 后端——本地虚拟机路线，不是云端沙箱；
• CLI 动词：devvm start|stop|ssh|shell|agent|sync|doctor；
• agent 接入：项目内的 agent 命令（start/stop/attach）可以把 coding agent 挂进 VM 里跑；
• 文档站（devvm.dev/docs/）有 quickstart、security、internals、limitations、contributing；安装走 curl 脚本或 brew。

安全设计是这个项目的卖点

三道防线都写在 README 与文档里：

1. VM 内的网络访问走 allowlist 代理——VM 里跑的东西不能随意出网；
2. ~/.ssh、~/.aws、~/Documents 不进 VM——本机最敏感的几个目录与 VM 隔离；
3. .git 目录受保护——VM 内的写操作碰不到它，agent 在沙箱里跑飞了也不会弄脏你的版本历史。

这套思路对准的场景很明确：让 agent 在你的项目里放手干活，但它能碰的文件、能出的网络、能弄坏的东西都被围起来。

判断与边界

对想让 coding agent 在本地安全干活的开发者，devvm 提供的是"本地 Lima VM"那条路线——与云端沙箱（比如 Replit 的 microVM 方案、E2B 这类云沙箱）是两个方向：数据不出本机、环境跟着项目走，代价是吃本地资源、能力边界也受本机限制。三条提醒：① 176 星、创建于昨天，遇到问题大概率要自己修或等作者修，生产依赖前先想清楚；② 事实以仓库与文档可核验部分为准——支持平台、性能数据、用户量这些都没有官方数字，别替它吹；③ 文档自己就有 limitations 一节，上手前先读。

参考来源

• 仓库：https://github.com/devvmhq/devvm
• 官网文档：https://devvm.dev/docs/
• HN 帖：https://news.ycombinator.com/item?id=50395450