大家好，我是阿布，80 后程序员，践行OPC一人公司理念，专注分享AI 实战干货与个体创业思路。

最近收到不少朋友的反馈，说升级到 OpenClaw 2026.3.31 之后，体验完全变了。

以前执行命令一气呵成，现在动不动就弹确认框。有些 skill 甚至直接卡住，跑不起来。

说实话，我第一反应也是懵的。

但仔细研究了一下官方文档和 release 记录，发现这事儿没那么简单。

▲ 配图1

先说结论

这不是 bug，也不是你配置坏了。

是 OpenClaw 在 2026.3.31 这波更新里，把命令执行审批机制做得更严格了。

官方管这套叫 Exec approvals，控制的是本机、gateway 或 node 主机上的命令执行审批。

到底变了什么？

简单来说，OpenClaw 现在把"能不能执行命令"拆成了两层：

第一层：security（权限层）

• deny = 全拒绝

• allowlist = 只允许白名单

• full = 全放行

第二层：ask（确认层）

• off = 不提示

• on-miss = 不在白名单时提示

• always = 每条都提示

所以你升级后看到"每执行一条命令都要点允许"，本质上是因为现在的有效策略更接近：

它不是在"抽风"，而是在认真拦你。

▲ 配图2

官方为什么这么做？

我翻了 GitHub 的 release 记录，发现最近围绕 exec approvals 做了多项调整：

• 把 "always allow" 做成真正持久的信任记录

• WebChat 改成原生审批 UI，不再让 agent 提示你手动输入 /approve

• 节点侧的命令策略更清晰地由各自的 exec approvals 配置控制

这说明一件事：官方开始认真考虑安全问题了。

AI 执行命令太丝滑，用户反而容易失控。所以现在它默认更谨慎。

你觉得烦，官方觉得安全。你想一把过，它想先问你一句：这条命令，真要执行吗？

为什么有些 skill 不能用了？

很多人误判，以为是"skills 坏了"。

其实不一定。

skill 本质上还是要落到命令执行、脚本运行、插件调用这些动作上。只要其中某一步被 exec approvals 卡住，整条链路就可能断掉。

另外，2026.3.31 还涉及 bundled plugin runtime externalization 相关变更，后续版本又专门补了"恢复 bundled plugin runtime 依赖分发"的修复。

所以有些 skill 不能用，可能不只是审批弹窗的问题，也可能和这波运行时变化有关。

解决方案（适合本地开发环境）

如果你是在自己的开发机上用，最简单的办法就是把 exec approvals 改成默认全放行。

配置文件位置：

操作步骤：

1. 终端执行：

1. 重启 gateway：

这个方案的逻辑很简单：

• security: "full" → 允许完整执行权限

• ask: "off" → 不再一条条弹窗确认

• openclaw gateway restart → 让新配置生效

如果你是 macOS LaunchAgent 模式，也可以用：

▲ 配图3

风险提示

这个方案有安全风险，而且不小。

一旦你改成：

本质上就是把 OpenClaw 从"需要你点头的执行器"，改成了"默认直接干活的执行器"。

效率是上来了，安全边界也一起退了。

这套方案适合：

• 自己的电脑

• 本地开发环境

• 自己写的 skill

• 明确知道会跑哪些命令

不适合：

• 公共机器

• 不可信 prompt

• 来源不明的第三方 skill

• 帮别人代跑一堆自动化命令

最后说两句

很多人觉得 2026.3.31 之后 OpenClaw 变烦了。

但从官方文档和 release 记录看，事情本质不是"它坏了"，而是：它开始更认真地对待命令执行这件事。

以前是：能跑就跑。

现在是：先问一句，该不该跑。

所以如果你是开发者，追求效率，完全可以把审批关掉。

但你也要明白，你关掉的不是一个弹窗，而是一道安全门。

如果你只是想找回升级前那种"顺滑执行"的感觉，上面的方案够用了。

但如果你连 prompt 来源、skill 来源、执行范围都没想清楚，就直接把审批全关掉，那不是提效，那叫把自己的机器交给概率学。

好了，今天的分享就到此结束，咱们下回见；

如果觉得文章对你有帮助，记得点。赞。转。发。收。藏喔！

关住后+我 w～x（budian5221），免费领取30套热门工作流+OpenClaw常用命令