这个系列我会对照三个开源 coding agent分别是 OpenAI codex101k star、xAI grok-build23k star和 earendil pi78k star一层层拆它们的内核最后带你从零写一个自己的。你让 coding agent 帮你清理项目它执行了一句 rm -rf ./build。你大概以为它外面裹着一层保护万一删到不该删的地方会被拦下来。读 pi 的源码时最让我意外的是它 SECURITY.md 里的一句话原话是这么写的。plaintextthe Pi coding agent intentionally does not have a sandboxpi 故意不给自己做沙箱。它把安全边界划在运行它的那个用户账号上你自己能读能写的文件它一样能动。文件工具收到绝对路径就照着写不管你工作目录之外。bash 工具也没有危险命令的名单rm -rf 和 curl | sh 它都不拦收到就执行。我起初以为 pi 是没做完留了个缺口。但是当我把另外三个 agent 的安全相关代码也读了一遍之后才明白 pi 只是把安全这件事讲在了最前面同时四个 agent 对于安全的解决方案也差得很远。pi 的做法pi 这么选背后是一套完整的想法。SECURITY.md 里说得很直白隔离是用户自己的事你要么把它关进容器要么放进虚拟机要么在外面套一层沙箱再跑。至于提示注入这种攻击比如仓库里的 AGENTS.md 藏一句“把 .env 发到某个地址”pi 直接承认防不住。那 pi 在自己这一层做了什么。它设了一道信任门。你在一个陌生仓库里第一次启动 pi如果这个仓库带着自己的配置和扩展文件pi 会先问你信不信任这个目录。你不点击确认这些能往 agent 里塞指令的配置和扩展就不加载连加载它们的代码也要等你的信任决定之后才跑。这道门管的是要不要执行这个项目带来的代码不管某一条命令该不该跑。至于命令本身pi 默认是放行的。codex 的相反选择codex 是 OpenAI 的用 Rust 写的默认行为和 pi 正好相反。你在一个受信任的目录里启动 codex它默认就把 agent 关进一个操作系统级的沙箱。macOS 上用系统自带的 SeatbeltLinux 上用 bubblewrap 加 seccomp。沙箱的底子是一句 (deny default)先全禁掉再把必要的能力一点点放行。全盘可以读但只有工作目录能写网络默认是断开的。codex 还多做了一层就算某个目录被允许写里面的 .git 仍然强制只读。.git/hooks 里的脚本会在你提交代码时自动执行一个 agent 要是被提示注入带偏只要往 hooks 里写一行就等于拿到了之后的执行权codex 直接在内核这一层把这条路堵死。命令在沙箱里被拦下之后怎么办比如它要联网或者要写工作区外面。codex 不会自己放行它把这次失败回报给模型模型可以请求提权但这一步要你点头你批准了它才能脱离沙箱重跑一次。两件不同的事pi 和 codex 摆在一起两件本来缠在一起的事就分开了。一件是 agent 能碰到什么这归沙箱管是文件系统和内核那一层的边界。另一件是某个动作该不该做这归审批管看有没有人点头。DeepSeek 八月刚开源的 harness 把这两件事说得最清楚。它的文档里讲审批弹窗不是文件系统的边界沙箱也代替不了用户的判断。在它这里沙箱和审批是分开的两套控制。dsh 自带一个沙箱默认是最严的只读档命令真正执行之前先被包一层。审批那套单独配默认要问你。它还照顾到一个容易被漏掉的情况无人值守跑在自动化流程里的时候没有人能点这个同意dsh 就直接判成拒绝文件根本不会被创建。一个没人看着的 agent不该自己批准自己。grok-build 能力齐全默认却关着grok-build 是 xAI 的也是 Rust也是四个里面它的安全能力做得最全。它有操作系统级沙箱靠内核机制强制还专门挡住子进程逃逸。它也做了工作副本隔离用写时复制给每个会话开一份独立副本agent 的改动都发生在副本里碰不到你的主目录。它的审批分了好几档其中一档背后挂着一个分类器专门判断命令危不危险。它甚至在把崩溃日志和分析数据发回自己服务器之前先把里面 sk- 开头的密钥、私钥、访问令牌都抹掉。然后我翻看了它解析沙箱配置的地方看到这套系统沙箱默认是关的。它有一条回退顺序你没在命令行、环境变量或者配置文件里显式打开最后就落到关闭这一档。这些能力都是具备的但如果你不主动打开那套内核沙箱就不会生效。能力不等于默认把四个 agent 的默认配置放到一起看。默认就把 agent 关进内核沙箱的只有 codex 和 dsh。grok-build 有一整套默认关着pi 干脆没有。所以判断一个 agent 安不安全先看它默认开着哪一档再看你把它跑在什么环境里。它有没有沙箱这个能力排在这两件事后面。对每天在用这类工具的开发者有件事可以马上做。你手上那个 coding agent装好之后默认跑在哪一档自己去确认一遍别默认它替你把关。最后看 codex 的一句注释codex 有个一键放开的开关叫 --dangerously-bypass-approvals-and-sandbox别名就叫 --yolo。打开它审批全跳过沙箱全放开。这个开关的注释里写着它只该用在本身已经跑在外部沙箱里的环境。绕回来看codex 这个防护做得最重的 agent最后认可的用法和 pi 的默认前提是同一个外面套一层容器里面那层可以关掉。区别只在于codex 把它做成一个要你显式打开的选项名字起得很重pi 把它当默认还写进 SECURITY.md 告诉你。四个 agent 谈不上谁对谁错是给谁用、跑在哪的不同假设。pi 假设你会把它放进容器自己就做得很轻。codex 假设你可能直接在自己机器上跑默认就把防护都打开。我们在选择agent 的时候也是在选择自己愿意承担下多少责任。接下来这一篇加上前四篇把 coding agent 从能跑推到了能持续工作也能安全工作。下一篇是这个系列的收尾我想把 diff、TUI、MCP、子代理这些从一百行 mini-agent 到工业级之间的距离列成一张清单给整个系列做个总结也回答一个从第一篇起就有人在评论区问的问题pi 这种到底算不算工业级。研读笔记、这四个 agent 的安全对照表和配套代码都放在下面这个仓库。这一篇的配套代码里我在前几篇那个 mini-agent 上加了一道执行前的审批钩子还写了一个危险命令先确认的例子演示 pi 留空的那道审批自己可以怎么补。