1. 凌晨两点那条 exec-approvals 弹窗到底在问什么OpenClaw 的 exec-approvals 是一套「命令执行前置审批」机制简单说就是 AI 助手要跑 shell 命令之前先弹一个框问你 allow-once、allow-always 还是 deny。它适合谁适合所有把命令行控制权交给 AI Agent 的开发者——你在用它部署服务、清理磁盘、装依赖、管服务器那这套审批就是你最后一道手动闸门。这次更新把 allowlist 和 safeBins 的边界讲清楚了我把它拆成能直接抄的配置和能复现的验证动作。先说清楚它解决的是什么问题。AI 会执行命令但它的「理解」和你的「意图」之间永远有条裂缝。你说「帮我清理日志」它理解成删掉所有带 .log 后缀的文件然后它用的是find / -name *.log。这条命令本身没毛病但作用域是全盘。exec-approvals 就是填在这条裂缝上的一层补丁命令落地前先让你看一眼原始文本再决定放不放行。很多人以为它就是个「执行前问你要不要批准」的弹窗。不对。它有两层守卫而且这两层是独立的。第一层是 Policy 层全局策略决定「哪些命令需要问」。模式有三种always是所有命令都问哪怕已经进了 allowlist 也照问on-miss是只在命令没匹配到 allowlist 时才问off是彻底躺平所有命令直接放行。注意off的危险性——只要进了 policy 层就没有任何阻拦等于把闸门焊死在打开状态。第二层是 Allowlist 层精确到命令的逐条审批。它管的不是「要不要问」而是「批准了之后能跑多久」。三个选项语义差别很大allow-once单次有效精确绑定到这一次命令 ID执行完立即失效allow-always永久有效下次遇到相同命令直接放行deny永久禁止进黑名单下次直接拒绝。关键问题来了——什么叫「相同命令」这就是 allow-always 最容易被低估的地方。系统记录的 command ID 是基于命令原始文本生成的。你批准了time npm test下次 AI 送来time rm -rf /文本不同command ID 不同系统认为这是两条完全不同的命令会走正常 ask 流程。看起来没问题。但换个更真实的例子你批准了curl https://api.example.com/upload -F filedocs.pdf下次 AI 送来curl https://api.example.com/upload -F filesecrets.zip。Command ID 不同因为文件路径不同但语义完全一致——都是往同一个 API 端点上传文件。第一次传的是普通文档第二次传的是敏感数据allow-always 不会拦你。这不是 bug是设计上的权衡。但它的安全含义必须说透allow-always 不是「授权这类操作」而是「授权这个 exact 字符串的命令」。理解了这个本质你就明白为什么很多安全工程师看到 allow-always 会血压升高。2. safeBins 和 allowlist 到底谁管谁别再把它们混成一件事先把结论放前面safeBins 是「默认信任」不需要你审批allowlist 是「我批准了」代表你主动做了授权决策。这两个机制协同工作才构成 exec-approvals 的完整权限体系。很多人把它们当成同一套系统的两个名字这是理解偏差的源头。safeBins 是一份免审批白名单由系统或管理员预先定义。它针对的是那些经过验证、风险可控的常见命令比如ls、cat、pwd。你用这些命令不需要任何审批流程因为它们本身就是只读或无害的。safeBins 的定位是「这些命令我提前替你信了」它不记录你的任何决策是配置层面的静态信任。allowlist 是你手动添加的审批记录。每一条记录都是你对某条具体命令的授权行为是动态的、有上下文的。你批准npm test进 allowlist是因为你验证过这个项目的测试脚本是安全的你批准某个curl上传命令是因为你知道那个端点和那个文件是可信的。allowlist 承载的是你的判断不是系统的预设。这两者的风险模型完全不同。safeBins 的风险在于「预设是否过宽」——如果管理员把rm塞进 safeBins那就是灾难。allowlist 的风险在于「授权是否过窄或过宽」——过窄导致效率低过宽导致 allow-always 把一次信任透支成永久信任。我实测下来一个比较稳的组合是policy 用on-misssafeBins 只保留真正只读的命令allowlist 里尽量用allow-once只有对高频且完全确定的命令才用allow-always。这样既不会每条命令都弹窗也不会把一次授权变成永久后门。还有一个容易踩的坑safeBins 命中的命令不会进 allowlist也不会留下审批记录。这意味着如果 safeBins 配置过宽你事后审计时根本看不到这些命令跑过。对于需要合规留痕的场景safeBins 要收得很紧宁可多问几次。allowlist 的命中逻辑也值得说清楚。当 AI 送来一条命令系统先看 policy如果是always直接弹窗allowlist 不参与如果是on-miss先查 allowlist命中就放行没命中才弹窗如果是off全部放行。所以 allowlist 只在on-miss模式下真正起作用。你如果配了always又指望 allowlist 减少弹窗那是白配。理解了这层关系你就能判断升级后的行为是否可控先看 policy 模式再看 safeBins 范围最后看 allowlist 里有多少条allow-always。这三个数字决定了你的实际安全边界。3. 可复制的 approvals 配置片段路径和字段都对齐下面这份配置我按 OpenClaw 的 approvals 结构写字段名和层级你可以直接对照自己的配置文件改。核心是三块policy、safeBins、allowlist。先给一份偏保守的 JSON 片段适合生产环境或共享服务器。{ execApprovals: { policy: on-miss, safeBins: [ ls, cat, pwd, head, tail, wc, grep ], allowlist: [ { command: npm test, decision: allow-once }, { command: npm run build, decision: allow-once }, { command: git status, decision: allow-always } ] } }如果你更习惯 TOML等价写法是这样[execApprovals] policy on-miss [execApprovals.safeBins] bins [ls, cat, pwd, head, tail, wc, grep] [[execApprovals.allowlist]] command npm test decision allow-once [[execApprovals.allowlist]] command npm run build decision allow-once [[execApprovals.allowlist]] command git status decision allow-always几个配置要点必须说清楚。第一policy我选on-miss而不是always因为always会让 allowlist 完全失效每条命令都弹窗效率低到你想关掉审批。第二safeBins我只放了只读命令grep严格说能读任意文件但在受控目录下风险可控如果你环境敏感把grep也拿掉。第三allowlist里高频只读的git status用allow-always构建和测试用allow-once因为构建脚本可能被改每次确认更稳。如果你用的是 Claude Code 那套 settings 结构思路一样把 approvals 段嵌进去{ permissions: { execApprovals: { policy: on-miss, safeBins: [ls, cat, pwd], allowlist: [ { command: npm test, decision: allow-once } ] } } }这里要提醒一句allow-always 的 command ID 绑定的是原始文本所以你在 allowlist 里写npm testAI 实际送来npm test -- --watch时文本不同不会命中还是会弹窗。这不是配置错了是机制如此。你要么把变体也加进去要么接受它每次问。配置改完记得重启 OpenClaw 的 agent 进程approvals 配置一般在启动时加载热改不一定生效。我踩过的坑就是改完没重启以为没生效折腾了半天。4. 一次 allowlist 命中与拒绝的验证动作配置写完不能只看得跑一次验证确认命中逻辑和拒绝逻辑都符合预期。下面这套动作你可以直接复现。第一步确认 policy 是on-missallowlist 里有git status且 decision 是allow-always。然后让 AI 助手执行git status。预期结果不弹审批框命令直接执行输出当前仓库状态。这一步验证的是 allowlist 命中路径。第二步让 AI 执行git status --short。预期结果弹审批框。因为 command ID 基于原始文本git status --short和git status文本不同不命中 allowlist走 ask 流程。这一步验证的是「allow-always 只绑定 exact 字符串」这个关键语义。第三步让 AI 执行rm -rf /tmp/test-*。预期结果弹审批框且你点 deny 后这条命令进黑名单下次再送同样的文本直接拒绝不再弹窗。这一步验证的是 deny 的持久化行为。第四步让 AI 执行ls -la。预期结果不弹框因为ls在 safeBins 里。这一步验证 safeBins 的免审批路径。跑完这四步你对当前配置的实际行为就有底了。重点看第二步——如果你以为 allow-always 是「授权这类操作」第二步的结果会纠正你它只授权那一个字符串。再补一个边界验证把 policy 临时改成always再执行git status。预期结果是弹框哪怕它在 allowlist 里。这验证了 policy 层优先级高于 allowlist。验证完记得改回on-miss。如果你在验证时发现 allowlist 没命中先检查三件事policy 是不是on-missallowlist 里的 command 字符串和 AI 实际送来的文本是否完全一致包括空格和参数顺序配置有没有重启加载。这三个查完基本能定位。5. 本篇常见报错排查401、local proxy failed、reading choices、OAuth接入和验证过程中报错基本集中在这几类。我按真实遇到的顺序列每条给排查方向。401 Unauthorized最常见的是 Key 没配对或过期。检查你的 Base URL 和 API Key 是否来自同一套环境别把测试 Key 用到生产端点。如果你用的是 TaoToken 这类统一接入层确认 Key 是在对应控制台生成的且没有多余空格。401 也可能是模型 ID 写错有些端点对模型名大小写敏感。local proxy failed本地代理层没起来或端口被占。先确认代理进程在跑再看端口有没有冲突。如果你在容器里跑注意容器网络和宿主端口映射。这个报错和审批机制无关是链路问题别往 approvals 上查。reading choices或cannot read property choices of undefined通常是响应体不是预期的 chat completion 结构可能端点返回了错误页或空体。先打印原始响应看内容再确认请求路径是不是/v1/chat/completions这类正确路径。模型 ID 不存在时有些端点会返回非标准结构也会触发这个错。OAuth相关报错多见于 Claude Code 或 Codex 这类需要登录态的客户端。如果你用 API Key 模式确认没有残留的 OAuth 配置覆盖了 Key。Codex 的auth.json里如果同时有 OAuth token 和 API Key可能优先走 OAuth 导致失败。清掉 OAuth 段只留 Key 配置。如果你同时用 CC Switch、Cline MCP 或 Codex记住三件套必须对齐Base URL、Key、Model ID。任何一件不匹配都会报错。Base URL 指向接入层Key 是接入层发的Model ID 是接入层支持的模型名。三者来自同一套配置别混用。排查顺序建议先看 HTTP 状态码再看响应体原文最后看配置三件套。大部分问题在第二步就能定位。6. 把审批边界握在自己手里回到最开始那个问题你点了 allow-always你真的知道自己在允许什么吗现在你应该清楚了——你允许的是那一个 exact 字符串的命令不是那一类操作。这个认知差就是安全边界的关键。我的建议是policy 用on-misssafeBins 只放只读命令allowlist 里高频确定的用 allow-always其余用 allow-once。定期审计 allowlist把不再需要的 allow-always 清掉。这样你既不会被弹窗淹没也不会把一次信任透支成永久后门。如果你想把接入层也统一管起来减少 Key 和端点散落各处的风险可以走 TaoToken 的 API Keys 页面生成和管理 Key接入文档里有各客户端的配置示例。需要验证模型连通性时用模型对话页面直接测一条请求比在客户端里反复试快得多。长期跑编码和 Agent 任务的话Coding Plan 更适合高频调用场景。工具是工具选择还是你的。审批机制的存在本身就是在承认一件事我们不完全信任 AI但我们在用它。把边界配清楚比争论站哪边更有用。