夜雨聆风很多人升级到 OpenClaw 2026.3.31 之后，第一反应不是“变强了”，而是：
怎么突然变麻烦了？
执行个命令，动不动就弹一次确认。
以前一把梭，现在变成一刀一审批。
有些 skill 甚至直接卡死，根本没法正常跑。
先说结论：
这不是你配置坏了，也不是 bug。
是OpenClaw 在 2026.3.31 这波更新里，把命令执行审批做得更严格、更显性了。 官方文档把这一套叫 Exec approvals，它控制的是本机、gateway 或 node 主机上的命令执行审批。
为什么升级后会变成这样？
因为 OpenClaw 现在把“能不能执行命令”拆成了两层：
第一层：security
决定命令有没有权限执行。
第二层：ask
决定执行前要不要弹窗让你确认。
官方文档给出的定义很明确：
* security: deny = 全拒绝 * security: allowlist = 只允许白名单 * security: full = 全放行 * ask: off = 不提示 * ask: on-miss = 不在白名单时提示 * ask: always = 每条都提示
也就是说，你升级后看到“每执行一条命令都要点允许”，本质上不是 OpenClaw 不会干活了，而是它现在的有效策略，已经更接近：
{"security": "allowlist","ask": "always"}
所以它不是在“抽风”，而是在认真拦你。
官方为什么要这么做？
因为官方明显在加强这一块。
GitHub 的 release 记录里能看到，最近围绕 exec approvals 做了多项调整，比如：
把 “always allow” 做成真正持久的信任记录WebChat 改成原生审批 UI，而不是再让 agent 提示你去手动输入 /approve节点侧的命令策略不再简单绑定到旧的审批记录，而是更清晰地由各自的 exec approvals 配置控制
这说明一件事：
2026.3.31 之后的 OpenClaw，不是单纯追求“自动执行更快”，而是在补安全闸门。
说白了，官方开始担心一件事：
AI 执行命令太丝滑，用户反而容易失控。
所以现在它默认更谨慎。
你觉得烦，官方觉得安全。
你想一把过，它想先问你一句：这条命令，真要执行吗？
为什么有些 skills 直接不能用了？
这里很多人会误判，以为是“skills 坏了”。
其实不一定。
因为 skill 本质上往往还是要落到命令执行、脚本运行、插件调用这些动作上。
只要其中某一步被 exec approvals 卡住，skill 整条链路就可能断掉。官方文档也说明了，主机上的 exec approvals 是额外的一层 guardrail，它是在工具权限之外再做一次拦截。
另外，官方 appcast 里也提到，**2026.3.31 **这版还涉及 bundled plugin runtime externalization 相关变更，后续版本又专门补了“恢复 bundled plugin runtime 依赖分发”的修复。
这意味着：
有些 skill 不能用，不一定只是审批弹窗导致，也可能和 3.31 这一波运行时变化有关。
最直接的解决方案
如果你是自己的开发机、本地环境、自己写的 prompt 和 skill，那最简单的办法，就是把 exec approvals 改成默认全放行。
官方文档说明，macOS App 的 system.run 审批配置，就存放在：
~/.openclaw/exec-approvals.json
也就是你改这个文件，就能控制审批策略。
直接可用的方案：
1、终端执行：
cat > ~/.openclaw/exec-approvals.json << 'EOF'{"version": 1,"defaults": {"security": "full","ask": "off"},"agents": {}}EOF
2、重启 gateway
openclaw gateway restart
这个方案的逻辑很简单：
* security: "full"
// 允许完整执行权限* ask: "off"
// 不再一条条弹窗确认* openclaw gateway restart //重启 gateway，让新配置生效
官方 CLI 文档里也有 gateway restart 相关说明，另外文档还提到，配置变更后，默认 gateway 路径下一般会通过 config watch 和 in-process restart 自动或近实时生效。
如果你是 macOS LaunchAgent 模式，也可以用：
launchctl kickstart -k gui/$UID/ai.openclaw.gateway
这也是官方支持的重启方式。
这个方案有没有风险？
有，而且不小。
官方安全文档明确提醒过，OpenClaw 没有“绝对安全”的配置，尤其是涉及 gateway、exec approvals、browser control 这些能力时，重点不是幻想零风险，而是你要清楚它能碰什么、谁能调它、它会替你执行什么。
所以这套方案适合：
自己的电脑 本地开发环境 自己写的 skill 明确知道会跑哪些命令
不适合：
公共机器 不可信 prompt 来源不明的第三方 skill 帮别人代跑一堆自动化命令
因为一旦你把它改成：
{ "security": "full", "ask": "off"}
本质上就是把 OpenClaw 从“需要你点头的执行器”，改成了“默认直接干活的执行器”。
效率是上来了，安全边界也一起退了。
这次升级，真正变的不是速度，是态度
很多人觉得 2026.3.31 之后 OpenClaw 变烦了。
但从官方文档和 release 记录看，事情本质不是“它坏了”，而是：
它开始更认真地对待命令执行这件事。
以前是：能跑就跑。
现在是：先问一句，该不该跑。
所以如果你是开发者，追求效率，完全可以把审批关掉。
但你也要明白，你关掉的不是一个弹窗，而是一道安全门。
最后一句
如果你只是想找回升级前那种“顺滑执行”的感觉，上面的方案够用了。
但如果你连 prompt 来源、skill 来源、执行范围都没想清楚，就直接把审批全关掉，那不是提效，那叫把自己的机器交给概率学。
