用 AI 写代码的人都遇到过同一个两难:要么每条命令都手动批一遍,几秒钟弹一次窗口,活活把自己盯成人肉审批机;要么干脆一句 --dangerously-skip-permissions 放开手脚,然后祈祷代理不会手滑一个 rm -rf,或者把哪个密钥顺手传出去。
一个刚在 GitHub 冒头的项目 clawk 给了第三条路:代理不再直接跑在你的电脑上,而是跑进一台一次性、默认断网的 Linux 虚拟机里。你的文件、钥匙串留在外面,VM 里出了事,clawk destroy 一下重来。
它是什么,解决什么问题
- 是什么.一条命令
clawk,在当前项目目录起一个虚拟机,里面预装 Claude Code / Codex / shell,代理在 VM 里拥有 root,可以装包、跑服务、执行测试,不用逐条审批。 - 解决什么.过去本地跑代理只有“全程盯着”和“裸奔”两个选项,clawk 想做的是把边界从“提示词里的一条规则”换成“一整台独立机器”。
- 谁受影响.重度用 Claude Code / Codex 的开发者,以及在意本地代码、密钥和供应链风险的工程团队。
- 现状.GitHub 约 54 星,18 次提交,项目仍是 pre-1.0,作者明说“接口和体验会经常变”。目前主打 macOS 14+ / Apple Silicon,Linux 走 firecracker,还在实验阶段。
隔离怎么做的,又留了哪些口子
代理进的是一台真正独立内核的 Linux 机器,不是共享内核加一层拒绝规则的容器。host 的文件系统从一开始就没挂进去,而不是“挂进去了但被规则挡住”——这个区别在安全上不算小。
网络默认全部拒绝,npm、PyPI、GitHub、Anthropic 这些常见目的地预先放行,其余出站连接一律被挡。仓库通过 virtio-fs 实时挂载进 VM,git 推送靠转发的 ssh-agent 完成,私钥本身从不进入 VM。
作者在文档里自己承认了边界:allow-list 挡的是未知服务器,挡不住已经放行的服务器。GitHub 在预允许名单里,ssh-agent 又能推送,代理能读到的任何内容,理论上都可能被它publish 出去。
- 风险.网络 allow-list 和挂载进去的代码,依然是潜在的外传通道,隔离不等于绝对安全。
老话说“害人之心不可有,防人之心不可无”,放在 AI 代理身上可能比放在人身上更贴切——它不是要害你,但它会照单全收你给的一切权限,然后毫无心理负担地用掉。
我的判断:这是权限模型的一次现实修正,不是花哨的 devcontainer
devcontainer 和普通容器的问题,clawk 说得很直白:共享宿主内核,文件系统靠“挂载减去拒绝规则”兜底,一个内核漏洞或一次误挂载就能捅穿到 host。很多 devcontainer 配置为了建镜像,还得把 Docker socket 绑给容器,相当于把宿主机的守护进程控制权也递出去了。clawk 反过来,把 Docker 塞进 VM 里,不碰 host 的 daemon。
跟纯进程级沙箱(比如 Anthropic 自己的 sandbox-runtime)比,clawk 的边界建在 hypervisor 上,而不是“把某条策略写对”。这个差别很实际:装系统包、跑后台服务、起数据库、甚至跑嵌套的 Docker/Kind,进程沙箱大多会跟你别扭,VM 天然支持。
安全边界从“说服代理别做什么”,换成了“给它一台够不到别处的机器”
代价也是真实的。VM 磁盘上的 apt 缓存、系统改动默认不持久,每次重启相当于重新来过,想要固化的工具必须写进镜像或者启动 hook,这对习惯了容器里随手装包的人是个门槛。项目还在 pre-1.0,主打平台是 macOS Apple Silicon,Linux 用户目前只能拿实验版凑合。硬件虚拟化、镜像构建、工作流迁移,每一项都是要真金白银投入时间的成本,不是装个插件那么轻。
- 结论.代理该不该放权限已经不是问题的核心,问题是你有没有一台可以随便牺牲的机器给它折腾。
这更像是行业在补一道早该补的课——本地 AI 代理的能力已经跑到了权限模型前面,这类项目是在把两者重新拉平。星数不多、提交不多,但方向站得住,值不值得现在就上手,取决于你愿不愿意为一层真隔离,多背一套虚拟机的运维成本。