同一个删除命令，三个编程智能体给出了三种答案

“Full access”这个选项在 Codex 上随处可见，甚至一些根本不在虚拟机里跑智能体的人也在用——对他们来说，那条臭名昭著的 rm -rf ~/ 似乎构不成什么担忧。

这不是假设。今年 7 月，OpenAI 确认 Codex 中的 GPT-5.6 在少数案例里删除了用户的主目录。在 Full access、没有沙箱的情况下，模型试图把 $HOME 指向一个临时文件夹，结果删掉的是 $HOME 本身。中间没有任何环节出来拦一下。

人们放任智能体为所欲为，原因主要有两个：不知道智能体可能造成多大破坏，以及权限疲劳。

自 Prokop 诞生第一天起，一套像样的权限系统就是必需品。但说起来容易做起来难。某天作者发现自己第十次对同一个无害的搜索点击“Allow Once”，才意识到自己已经不再读允许的内容了。

那条命令是 grep -rl foo src | xargs grep -L bar，只读操作。Prokop 每次都询问，还把它标成 Destructive。这个 bug 是作者自己的，它把人训练成了无脑点击——而这恰恰是权限系统本该防止的事。

三个智能体，三种危险观

Prokop 在三种执行环境上跑会话：你安装的 Claude Code、你安装的 Codex，以及 Prokop 自己的。Claude Code 和 Codex 各自带着自己的审批模型和对“什么危险”的判断，作者认为两者都不够用，也不想依赖模型本身足够好。

想象三个承包商在你家干活，各有各的签字规则。一个碰任何东西前都问，另一个只问电路问题。你需要的是确定性和可预测性。

于是每一次工具调用都走同一道检查，不管来自哪个执行环境。Prokop 的运行时直接调用它；Claude Code 走 Agent SDK 的 canUseTool 回调；Codex 跑一个 PreToolUse 钩子，通过一个只存在一轮的私有套接字与 Prokop 通信。Prokop 不碰你的 Codex 配置，Codex 也保留自己的 workspace 沙箱。

一个数字说不清原因

第一版给每条命令一个风险等级，用户选阈值：Off、none、low、medium、high，五档一个数。这个设计两个方向都错了。密钥靠子串匹配，于是 password-reset.ts 也被当成密钥；而 git reset --hard 从来不问，因为归一化步骤在检查看到之前就把标志剥掉了。

更大的问题在数字本身。风险分数回答的是“我该多害怕”，你真正需要知道的是“这到底会做什么”。同事审你的 PR 时不会说“风险 7”，而会说“这会删掉 build 文件夹并读取你的 .env”。

先摆事实，再做决定

重建后的系统把工作拆成两半。分析器只看命令或文件操作并报告事实，不做任何决定。事实就是“关注项”：工作区之外、密钥（.env、keys、.ssh/、.aws/，这次按名称匹配）、破坏性操作（强制删除、硬重置、强制推送）、不透明（看不透的东西），外加一个针对灾难性操作的标记：rm -rf /、rm -rf ~、对设备 dd、shutdown。

关注项会叠加。rm -rf ~/.ssh 同时是破坏性、工作区之外和密钥。然后恰好一个函数根据你选的模式把事实变成决定：灾难性操作即使在 Full access 下也会询问。所以在 Prokop 里，开头那条 rm -rf ~/ 无论什么模式都会停下来等你。

这不代表 Full access 变安全了。它仍会不问就执行破坏性操作、读取你的密钥。建议是：永远不要高于 Extended，除非 Prokop 服务器跑在虚拟机里，丢光一切也不心疼。系统里没有“凡事都问”模式——一个什么都问的模式，不过是把 xargs 那个 bug 做成了设置项，午饭前你就会回到不读就点的状态。

像人一样读 shell 命令

大部分工作花在像人一样读 shell 命令上。提交信息里写“rm old file”你不会慌，那只是文本；但同样的话放进 sh -c '...' 就会真的执行。所以分析器会拆开 shell 包装、理解引号和替换，只筛查真正会执行的文本。它跟踪 cd，所以 cd build && rm -rf . 会解析到正确的文件夹。

判断不了时，它按最坏情况算。把下载的代码管道进 shell（curl ... | sh）算破坏性，除 Full access 外所有模式都会询问。带无法解析目标的破坏性命令，比如 rm -rf $DIR，算灾难性，否则 Full access 就直接跑了。唯一例外是同一命令前面明确把 $DIR 设成了某个路径，那就按那个值判断。

这正是 GPT-5.6 的模式：主目录路径放进变量，然后对变量执行 rm -rf。在 Codex 的 Full access 下没有任何东西拦它；在 Prokop 里它是灾难性，所有模式都会询问。

xargs 那个 bug 正是这类读取的失败。xargs 会把参数当命令执行，所以参数要筛查危险词；但筛查列表里也包含了 xargs 这个词本身，于是它匹配了自己。修法是像人一样判断 xargs——看它运行什么命令，而不是看它的名字：

• ls | xargs wc -l：执行
• ls | xargs rm -rf：破坏性，询问
• ls | xargs -n1 cat .env：密钥，询问
• xargs --arg-file=.env echo：密钥，询问

有些东西永远不该“总是允许”

你可以允许一次、允许本会话、或允许整个工作区。但破坏性或灾难性的操作除外，它们只提供“一次”。“总是允许 rm -rf”不是任何人在晚上 11 点该顺手做出的决定。

新系统上线时还清空了所有已保存的批准。旧批准是在旧规则下做出的，本可以翻译过来，但一次授权重建只需一次点击，不值得把旧错误带过来。

让我看到该读的那部分

即使询问是对的，审起来也难。长命令显示成一大段，你得自己找出哪些部分被标记、它们到底做什么。这太累，会把人推回“yolo，批准，祈祷”。

现在每个关注项都指向命令中确切的部分，并用大白话给出理由。git reset --hard HEAD~1 标注“丢弃未提交的更改”，/etc/hosts 标注“工作区之外”。这在 sh -c 和其他 shell 包装下也成立——分析器读的是拆开后的命令，高亮却要落在你看到的那条上，这是最麻烦的部分。

卡片把每个管道阶段单独成行，标出被标记的部分，其余变暗。颜色告诉你哪种模式会放行：琥珀色是工作区之外，Extended 会跑；红色是密钥和破坏性，只有 Full access 会跑；灾难性用最深的红和独立徽章，因为没有你它什么都跑不了。

等待也是其中一环

批准是一次暂停，而暂停本身也有 bug。等你花的时间曾被算进工具自己的时限，一分钟后批准，命令就以超时失败；现在等待时时钟停走。如果笔记本休眠时 Claude Code 会话需要批准，请求曾被立即拒绝；现在它会等你回来。另一台机器上的会话需要你时，你正在用的机器会通知你。

这些都不是分类问题，但都决定你是否真的能做出决定。

它不是什么

这不是沙箱。它在命令运行前读取命令，无法知道脚本跑起来之后会做什么，会有缺口。除非模型带着所需全部上下文评估每条命令，否则总有智能体运行那个无辜的 ./nuke-computer.sh 的风险。

它做的是：对不需要问的事少问，让剩下的问题快速可答。作者此前写过，当智能体删掉你的生产数据库，责任仍在你，因为你构建了它运行的环境。权限系统是这个环境的重要部分。最安全的系统不是问得最多的那个，而是你仍会认真读它问题的那个。