photo_2026-04-02_11-46-40

OpenClaw 更新到 3.31，我照常升级，心想又不是什么大版本，能出什么问题。

结果当天晚上就给我上了一课。

我有一个跑新闻的定时任务。升级之前一切正常，tools.exec.ask 设成了 off，tools.exec.security 设成了 full，agent 自己就能干活，不用我盯着审批。

升级完，agent 第一次执行 ls 就弹出一个审批请求。

image-20260402114131360

我当时以为是缓存问题，重启了 gateway。没用。又检查了一遍配置文件，明明写得好好的。再试，还是弹审批。

然后我去 GitHub Issues 搜了一下，发现我不是一个人。

出了什么问题

说正经的，这事儿影响挺大。

从 GitHub issue 来看，不止我一个人踩坑。Issue #58691 里，用户反馈从 3.28 升级到 3.31 后，所有 exec 命令都需要手动审批，配置完全无效。官方 changelog 里有一句关键的话：

ACP/security: replace ACP's dangerous-tool name override with semantic approval classes

翻译一下：安全审批机制重构了。但问题是——重构完之后，配置项的名字和行为对不上了。

更坑的是 Windows 用户。Issue #58752 显示，Windows 上远程使用时审批弹窗无法绕过，直接报错 allowlist execution plan unavailable (unsupported platform)。意思就是：你想审批？抱歉，平台不支持，回家吧。

有位老哥忍不住了，直接在 Issue #59079 里开喷：

STOP SHIPPING BROKEN SECURITY FEATURES.

我理解他的心情。真的。

为什么会这样？

我折腾了半天，最终搞定了。分享一下，省得你们再踩一遍。

先搞清楚配置文件的优先级

OpenClaw 现在有两层配置跟 exec 审批有关：

  1. ~/.openclaw/exec-approvals.json — 专门管审批的配置文件
  2. ~/.openclaw/openclaw.json — 主配置文件里的 tools.exec 字段

3.31 之前，这两个写哪个都行。3.31 之后，必须在 openclaw.json 里显式声明，否则 gateway 用内部默认值，比你写的更严格。

具体操作

编辑 ~/.openclaw/openclaw.json，确保 tools.exec 这一段完整存在：

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

注意两个字段都要写。只写 security: full 不写 ask: off 是不行的，ask 字段缺失的话 gateway 会回退到内部默认值，也就是”每次都要审批”。

改完重启 gateway，agent 执行命令就不再弹审批了。

image-20260402114525724

还有一个坑

如果你之前在 exec-approvals.json 里配了具体的 allowlist（比如只允许某些命令），升级到 3.31 后建议检查一下。新的语义审批类可能会把你的 allowlist 里的命令重新分类，导致你以为允许的命令实际被拦了。

简单说，升级后把审批相关的配置都过一遍，别指望”以前能用升级后也能用”。

吐槽几句

说回正题。3.31 这个问题大概率会在后续版本修复，但在此之前，如果你还没升级，建议先别动。已经在用的，按上面的方法改一下 openclaw.json 基本能解决。

话说回来，你们现在还在用 OpenClaw 吗？日常跑什么 workflow？有没有其他踩坑经历？

我目前主要用它做 Telegram 机器人自动化，配合几个自定义 skill 做内容管理和定时任务。整体来说功能确实强大，就是每次大版本更新都得做好心理准备——你永远不知道哪个配置突然就不生效了。

评论区聊聊呗。技术圈有个好处——踩过的坑，大家一说出来，后来人就能少走弯路。