OpenClaw 升级3.31后老弹审批?真正该改的是这两个配置

大家好，我是凯哥。

说实话，最近很多人升级完 OpenClaw，第一反应不是“新版本真强”，而是——怎么干点活就让我复制一条 /approve？

装个 skill 要批，抓个链接要批，跑个命令还要批。看上去像是 agent 变笨了，但真相其实没那么玄乎：不是它不会干活了，而是新版把执行权限拆得更细了。

一句话先说结论：你遇到的不是“命令坏了”，而是“审批层”和“执行层”被分开了。只关掉审批，不代表命令就真的能跑。

把重复的交给系统，把判断留给自己。

01 为什么升级后，OpenClaw 突然开始疯狂要你审批？

这个坑特别像“产品改坏了”，但本质上它其实是安全策略变严了。

以前很多动作在你眼里是一句话的事：装一个 skill、跑一个 CLI、拉一个 GitHub 仓库、解析一个网页链接。但在 OpenClaw 新版本里，这些动作会被单独识别成几类风险操作：shell 执行、外部 CLI 调用、网络访问、安装行为，以及可能改系统状态的动作。

于是你就会看到一种很烦的现象：明明只是干活，系统却把它当成“要不要放行”的决策题。很多人第一反应是去改 prompt，或者怀疑 agent 退化了。其实都不对，因为这个问题根本不在对话层，而在 Gateway 的执行配置层。换句话说，agent 想干，系统没让它干。

02 为什么我明明已经把 ask 关了，还是跑不动？

这里最容易踩坑。

很多人看文档，先找到的是这个配置：

tools: {
  exec: {
    ask: "off"
  }
}

一看很合理：“别问了，直接干。”

然后你改完一测，发现确实不再弹审批了，但命令还是跑不了，报的是：exec denied: allowlist miss。

这时候就很懵。不都已经 off 了吗，怎么还不行？原因很简单：ask 管的是“要不要先问你批准”，不是“命令能不能执行”。

也就是说，OpenClaw 里至少有两层。第一层是审批层，决定要不要弹 /approve；第二层是执行层，决定这个命令本身有没有资格跑。

所以你把 ask: "off" 改掉之后，只是解决了第一层。系统不问你了，但第二层如果还是 deny 或 allowlist，那命令照样死。

不弹窗，不等于放行。这俩根本不是一回事。

03 真正要改的是哪两个配置？

这次实测下来，关键就是这两个：

tools: {
  exec: {
    ask: "off",
    security: "full"
  }
}

先拆开说。

1）`tools.exec.ask`

这个决定要不要频繁让你批准：

always：基本每次都问
on-miss：没命中规则时才问
off：不问

如果你的目标是“别让我每干一件事都复制命令批准”，那这里就得是：

ask: "off"

2）`tools.exec.security`

这个决定 exec 到底能放多开。

常见理解可以粗暴记成：

deny：最严，基本不给跑
allowlist：只跑白名单
full：全开

如果这里没放开，就会出现那种最烦的情况：审批没了，命令还是死，你以为系统抽风了。其实不是抽风，是还卡在第二层。

所以真正要让 exec 恢复成“像以前那样能直接干活”，通常要同时满足：

ask: "off"
security: "full"

04 配置改完，为什么还得重启？

这个也是大坑。

很多人改完 ~/.openclaw/openclaw.json，就立刻开始测试。如果这时候还跑不通，就会得出一个错误结论：文档是错的、配置没用、新版本有 bug。

但更常见的真实原因是：配置文件改了，运行中的 Gateway 还没完全吃到新策略。

稳妥流程就四步：

第一步：改配置

文件位置一般是：

~/.openclaw/openclaw.json

第二步：校验配置

openclaw config validate

看到这句就说明 JSON 没写坏：

Config valid: ~/.openclaw/openclaw.json

第三步：重启 Gateway

openclaw gateway restart

第四步：拿最轻的命令实测

比如：

pwd

如果这时候命令能直接返回工作目录，说明才是真的生效了。这一步非常关键。不要只看“配置文件改了没”，要看“运行态是不是已经换过去了”。

改配置只是开始，跑通命令才算结束。

05 这个改法适合所有人吗？

不适合。

如果你这个 OpenClaw 只给自己用，而且你本来就希望它是一个真能干活的个人助理，那把 exec 放开，体验会顺非常多。

但如果你的使用场景是多人共享一个 bot、群里很多人都能直接使唤它、机器上还挂着敏感账号和敏感文件，那你直接把：

ask: "off"
security: "full"

全开，风险会明显变大。因为这时候你放开的已经不是“方便”，而是工具权限本身。

所以更准确的说法是：

适合放开的场景

自己单人使用
明确知道自己在做什么
机器和账号都在自己控制范围内
追求效率优先

不适合直接全开的场景

群聊共享
团队多人共用
有外部用户可直接触达
机器上有高敏感数据

别把“方便”误当成“无代价”。

06 最后给你一个最省事的判断标准

如果你升级 OpenClaw 后出现下面这些症状：动不动就弹 /approve，改了 ask: off 还是不能执行，命令报 exec denied: allowlist miss，配置明明合法，但运行还是像旧策略。

你就按这个顺序排：

看主配置文件是不是 ~/.openclaw/openclaw.json
检查是不是改了：tools.exec.ask、tools.exec.security
跑 openclaw config validate
再跑 openclaw gateway restart
用一个最轻的命令做实测

这套下来，基本就能把问题从“玄学”拉回“配置”。

说在最后：

很多人以为 AI 助手不好用，是因为模型不够聪明。但真到落地阶段你会发现，拦住它干活的，很多时候不是模型，而是权限链路。

模型负责想，配置决定它能不能动手。

你想要的是助理，不是一个只会道歉的审批转发器。