1. 为什么你的 OpenClaw 脚本总在半夜被拦下来如果你正在用 OpenClaw 跑本地自动化脚本大概率遇到过这种场景白天手动执行一切正常挂到定时任务里凌晨三点跑结果第二天一看日志命令全卡在审批环节没执行。这不是脚本写错了而是 OpenClaw 的 Approvals 审批机制在起作用。OpenClaw 的 CLI 提供了一套执行审批Approvals体系用来管理本地主机、网关主机或节点主机上的命令执行权限。默认情况下openclaw approvals系列命令操作的是磁盘上的本地审批文件路径在~/.openclaw/exec-approvals.json。你可以通过--gateway参数把操作目标指向网关或者用--node指向某个具体节点。这套机制的设计初衷是安全任何可能产生副作用的命令都需要先被审批规则放行才能实际执行。问题在于很多从入门到应用的开发者只关注了 OpenClaw 的对话和编码能力忽略了审批配置这一层。结果就是本地交互式使用时手动点确认没问题一旦进入自动化脚本场景审批就成了拦路虎。这篇内容聚焦 OpenClaw CLI 的 Approvals 审批机制面向本地开发与自动化脚本场景把审批触发条件、放行策略、可复制的 config.toml 骨架以及 TaoToken 统一 Key 接入配置一次讲清楚最后给出 CLI 命令验证审批生效的具体动作。适合谁看已经在本地跑 OpenClaw、准备把命令执行接入自动化流程、或者被审批弹窗卡住过的开发者。读完你能自己配出一套「该放的放、该拦的拦」的审批规则并且用统一 Key 把模型调用和审批链路串起来。2. TaoToken 前置统一 Key 与 OpenClaw 的接入关系在讲审批配置之前先把 Key 的事情理清楚。OpenClaw 在执行命令、调用模型、跑 Agent 任务时需要一个统一的凭证入口。TaoToken 提供的就是这个入口一个 Key 覆盖模型对话、编码计划、API 调用等多种能力省去你在多个服务之间来回切换配置的麻烦。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。你需要先在控制台创建一个 API Key然后把它写进 OpenClaw 的配置文件里。这里有个容易踩的坑很多人以为审批配置和 Key 配置是两套独立的东西其实在 OpenClaw 里审批规则决定了「哪些命令允许执行」而 Key 决定了「执行时用哪个凭证去调用后端能力」。两者配合才能跑通完整链路。如果你只配了审批没配 Key命令放行了但模型调用会失败只配了 Key 没配审批命令直接被拦Key 根本用不上。所以正确的顺序是先拿 Key再配审批最后验证。拿 Key 的入口在控制台的 API Keys 页面创建后复制保存后面写进 config.toml。3. 可复制配置config.toml 骨架与审批规则OpenClaw 的配置文件通常放在项目根目录或用户配置目录下文件名config.toml。下面给出一份可直接复制的骨架包含 TaoToken 统一 Key 接入和 Approvals 审批规则两部分。# config.toml - OpenClaw 配置骨架 [provider] # TaoToken 统一 Key 接入 api_key sk-your-taotoken-key-here base_url https://taotoken.net/api model claude-sonnet-4-20250514 [approvals] # 审批文件路径默认 ~/.openclaw/exec-approvals.json file ~/.openclaw/exec-approvals.json # 默认策略deny 表示未匹配的命令一律拦截 default_policy deny # 是否允许通过 CLI 动态修改审批规则 allow_cli_override true [approvals.allowlist] # 允许列表匹配的命令直接放行不弹审批 patterns [ ~/Projects/**/bin/rg, /usr/bin/uptime, /usr/bin/uname, git status, npm run build ] [approvals.agents] # 按 agent 维度细分审批策略 main { policy allowlist } * { policy deny }这份配置的核心逻辑是default_policy deny保证默认拦截只有命中allowlist.patterns的命令才放行。agents段可以针对不同 agent 设置不同策略main走允许列表其他 agent 一律拒绝。审批文件本身是一个 JSON 结构存储在~/.openclaw/exec-approvals.json。你可以直接用 CLI 命令操作它也可以手动编辑。文件内容大致长这样{ version: 1, allowlist: [ ~/Projects/**/bin/rg, /usr/bin/uptime, /usr/bin/uname ], agents: { main: { policy: allowlist }, *: { policy: deny } } }注意--node参数使用的是与openclaw nodes相同的解析方式支持 id、名称、IP 或 id 前缀。--agent默认值是*适用于所有代理。节点主机必须声明支持system.execApprovals.get/setmacOS 应用或无头节点主机都满足这个条件。4. CLI 命令验证审批生效的具体动作配置写完之后必须用 CLI 命令验证审批是否真的生效。下面按操作顺序给出完整命令和预期结果。第一步查看当前审批规则openclaw approvals get这条命令读取本地审批文件并打印当前规则。如果你要查看网关或节点的审批规则加上对应参数openclaw approvals get --gateway openclaw approvals get --node node预期输出会列出 allowlist 和 agents 策略。如果输出为空或报错说明审批文件路径不对或文件不存在。第二步从文件替换审批规则openclaw approvals set --file ./exec-approvals.json这条命令用指定文件覆盖当前审批规则。针对节点或网关openclaw approvals set --node node --file ./exec-approvals.json openclaw approvals set --gateway --file ./exec-approvals.json第三步用 allowlist 辅助命令动态添加和移除规则# 添加允许规则 openclaw approvals allowlist add ~/Projects/**/bin/rg openclaw approvals allowlist add --agent main --node node /usr/bin/uptime openclaw approvals allowlist add --agent * /usr/bin/uname # 移除允许规则 openclaw approvals allowlist remove ~/Projects/**/bin/rg第四步实际触发一次命令执行观察审批行为。比如你允许了git status执行openclaw exec git status预期直接放行不弹审批。再执行一个未在允许列表里的命令openclaw exec rm -rf /tmp/test预期被拦截提示需要审批或直接拒绝。这一步是验证审批生效的关键动作能直观看到放行和拦截的差异。如果你在验证过程中需要确认模型调用是否正常可以用模型对话入口单独测试 Key 是否可用。长期跑编码任务或 Agent 的话建议走 Coding Plan 通道审批规则和 Key 配置可以复用同一套。5. 本篇常见错排查报错一approvals file not found审批文件默认在~/.openclaw/exec-approvals.json如果这个文件不存在openclaw approvals get会报错。解决办法是先执行一次openclaw approvals set --file ./exec-approvals.json初始化文件或者手动创建空 JSON 结构。报错二node does not support system.execApprovals.get/set说明目标节点主机没有声明支持审批接口。检查节点是否为 macOS 应用或无头节点主机其他类型的节点可能不支持这套审批机制。可以先用openclaw nodes确认节点状态。报错三命令放行了但执行失败提示 Key 无效这是审批和 Key 配置脱节导致的。审批只管放行Key 管调用。检查config.toml里的api_key和base_url是否正确base_url应该是https://taotoken.net/api不要带多余路径。报错四--agent参数不生效--agent默认值是*如果你在 allowlist 命令里指定了--agent main但实际执行命令的 agent 不是 main规则就不会命中。用openclaw approvals get确认当前 agents 策略再对照执行时的 agent 标识。报错五通配符匹配不符合预期~/Projects/**/bin/rg这种模式里**匹配多级目录*匹配单级。如果你写的模式太宽或太窄会导致该放行的被拦、该拦的被放。建议先用具体路径测试确认匹配行为后再改通配符。6. 把审批和 Key 串成一条可复用的链路审批配置不是一次性的它需要和你的 Key 管理、Agent 策略一起维护。我自己的做法是把config.toml和exec-approvals.json都纳入版本控制每次调整审批规则后跑一遍验证命令确认放行和拦截都符合预期。如果你还在本地开发阶段建议先用default_policy deny加白名单的方式把常用命令逐个加进去观察一段时间再放宽。如果已经进入自动化脚本场景重点检查定时任务执行时的 agent 标识和节点解析方式这两个地方最容易出问题。需要创建新的 API Key 或查看接入文档可以从控制台和文档入口进入。模型对话验证走模型对话通道长期编码和 Agent 任务走 Coding Plan审批规则和 Key 配置在三条链路里是通用的。把这篇的 config.toml 骨架和 CLI 验证命令跑一遍你就能从入门到应用把 OpenClaw 的审批链路完整跑通。
1. 为什么你的 OpenClaw 脚本总在半夜被拦下来如果你正在用 OpenClaw 跑本地自动化脚本大概率遇到过这种场景白天手动执行一切正常挂到定时任务里凌晨三点跑结果第二天一看日志命令全卡在审批环节没执行。这不是脚本写错了而是 OpenClaw 的 Approvals 审批机制在起作用。OpenClaw 的 CLI 提供了一套执行审批Approvals体系用来管理本地主机、网关主机或节点主机上的命令执行权限。默认情况下openclaw approvals系列命令操作的是磁盘上的本地审批文件路径在~/.openclaw/exec-approvals.json。你可以通过--gateway参数把操作目标指向网关或者用--node指向某个具体节点。这套机制的设计初衷是安全任何可能产生副作用的命令都需要先被审批规则放行才能实际执行。问题在于很多从入门到应用的开发者只关注了 OpenClaw 的对话和编码能力忽略了审批配置这一层。结果就是本地交互式使用时手动点确认没问题一旦进入自动化脚本场景审批就成了拦路虎。这篇内容聚焦 OpenClaw CLI 的 Approvals 审批机制面向本地开发与自动化脚本场景把审批触发条件、放行策略、可复制的 config.toml 骨架以及 TaoToken 统一 Key 接入配置一次讲清楚最后给出 CLI 命令验证审批生效的具体动作。适合谁看已经在本地跑 OpenClaw、准备把命令执行接入自动化流程、或者被审批弹窗卡住过的开发者。读完你能自己配出一套「该放的放、该拦的拦」的审批规则并且用统一 Key 把模型调用和审批链路串起来。2. TaoToken 前置统一 Key 与 OpenClaw 的接入关系在讲审批配置之前先把 Key 的事情理清楚。OpenClaw 在执行命令、调用模型、跑 Agent 任务时需要一个统一的凭证入口。TaoToken 提供的就是这个入口一个 Key 覆盖模型对话、编码计划、API 调用等多种能力省去你在多个服务之间来回切换配置的麻烦。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。你需要先在控制台创建一个 API Key然后把它写进 OpenClaw 的配置文件里。这里有个容易踩的坑很多人以为审批配置和 Key 配置是两套独立的东西其实在 OpenClaw 里审批规则决定了「哪些命令允许执行」而 Key 决定了「执行时用哪个凭证去调用后端能力」。两者配合才能跑通完整链路。如果你只配了审批没配 Key命令放行了但模型调用会失败只配了 Key 没配审批命令直接被拦Key 根本用不上。所以正确的顺序是先拿 Key再配审批最后验证。拿 Key 的入口在控制台的 API Keys 页面创建后复制保存后面写进 config.toml。3. 可复制配置config.toml 骨架与审批规则OpenClaw 的配置文件通常放在项目根目录或用户配置目录下文件名config.toml。下面给出一份可直接复制的骨架包含 TaoToken 统一 Key 接入和 Approvals 审批规则两部分。# config.toml - OpenClaw 配置骨架 [provider] # TaoToken 统一 Key 接入 api_key sk-your-taotoken-key-here base_url https://taotoken.net/api model claude-sonnet-4-20250514 [approvals] # 审批文件路径默认 ~/.openclaw/exec-approvals.json file ~/.openclaw/exec-approvals.json # 默认策略deny 表示未匹配的命令一律拦截 default_policy deny # 是否允许通过 CLI 动态修改审批规则 allow_cli_override true [approvals.allowlist] # 允许列表匹配的命令直接放行不弹审批 patterns [ ~/Projects/**/bin/rg, /usr/bin/uptime, /usr/bin/uname, git status, npm run build ] [approvals.agents] # 按 agent 维度细分审批策略 main { policy allowlist } * { policy deny }这份配置的核心逻辑是default_policy deny保证默认拦截只有命中allowlist.patterns的命令才放行。agents段可以针对不同 agent 设置不同策略main走允许列表其他 agent 一律拒绝。审批文件本身是一个 JSON 结构存储在~/.openclaw/exec-approvals.json。你可以直接用 CLI 命令操作它也可以手动编辑。文件内容大致长这样{ version: 1, allowlist: [ ~/Projects/**/bin/rg, /usr/bin/uptime, /usr/bin/uname ], agents: { main: { policy: allowlist }, *: { policy: deny } } }注意--node参数使用的是与openclaw nodes相同的解析方式支持 id、名称、IP 或 id 前缀。--agent默认值是*适用于所有代理。节点主机必须声明支持system.execApprovals.get/setmacOS 应用或无头节点主机都满足这个条件。4. CLI 命令验证审批生效的具体动作配置写完之后必须用 CLI 命令验证审批是否真的生效。下面按操作顺序给出完整命令和预期结果。第一步查看当前审批规则openclaw approvals get这条命令读取本地审批文件并打印当前规则。如果你要查看网关或节点的审批规则加上对应参数openclaw approvals get --gateway openclaw approvals get --node node预期输出会列出 allowlist 和 agents 策略。如果输出为空或报错说明审批文件路径不对或文件不存在。第二步从文件替换审批规则openclaw approvals set --file ./exec-approvals.json这条命令用指定文件覆盖当前审批规则。针对节点或网关openclaw approvals set --node node --file ./exec-approvals.json openclaw approvals set --gateway --file ./exec-approvals.json第三步用 allowlist 辅助命令动态添加和移除规则# 添加允许规则 openclaw approvals allowlist add ~/Projects/**/bin/rg openclaw approvals allowlist add --agent main --node node /usr/bin/uptime openclaw approvals allowlist add --agent * /usr/bin/uname # 移除允许规则 openclaw approvals allowlist remove ~/Projects/**/bin/rg第四步实际触发一次命令执行观察审批行为。比如你允许了git status执行openclaw exec git status预期直接放行不弹审批。再执行一个未在允许列表里的命令openclaw exec rm -rf /tmp/test预期被拦截提示需要审批或直接拒绝。这一步是验证审批生效的关键动作能直观看到放行和拦截的差异。如果你在验证过程中需要确认模型调用是否正常可以用模型对话入口单独测试 Key 是否可用。长期跑编码任务或 Agent 的话建议走 Coding Plan 通道审批规则和 Key 配置可以复用同一套。5. 本篇常见错排查报错一approvals file not found审批文件默认在~/.openclaw/exec-approvals.json如果这个文件不存在openclaw approvals get会报错。解决办法是先执行一次openclaw approvals set --file ./exec-approvals.json初始化文件或者手动创建空 JSON 结构。报错二node does not support system.execApprovals.get/set说明目标节点主机没有声明支持审批接口。检查节点是否为 macOS 应用或无头节点主机其他类型的节点可能不支持这套审批机制。可以先用openclaw nodes确认节点状态。报错三命令放行了但执行失败提示 Key 无效这是审批和 Key 配置脱节导致的。审批只管放行Key 管调用。检查config.toml里的api_key和base_url是否正确base_url应该是https://taotoken.net/api不要带多余路径。报错四--agent参数不生效--agent默认值是*如果你在 allowlist 命令里指定了--agent main但实际执行命令的 agent 不是 main规则就不会命中。用openclaw approvals get确认当前 agents 策略再对照执行时的 agent 标识。报错五通配符匹配不符合预期~/Projects/**/bin/rg这种模式里**匹配多级目录*匹配单级。如果你写的模式太宽或太窄会导致该放行的被拦、该拦的被放。建议先用具体路径测试确认匹配行为后再改通配符。6. 把审批和 Key 串成一条可复用的链路审批配置不是一次性的它需要和你的 Key 管理、Agent 策略一起维护。我自己的做法是把config.toml和exec-approvals.json都纳入版本控制每次调整审批规则后跑一遍验证命令确认放行和拦截都符合预期。如果你还在本地开发阶段建议先用default_policy deny加白名单的方式把常用命令逐个加进去观察一段时间再放宽。如果已经进入自动化脚本场景重点检查定时任务执行时的 agent 标识和节点解析方式这两个地方最容易出问题。需要创建新的 API Key 或查看接入文档可以从控制台和文档入口进入。模型对话验证走模型对话通道长期编码和 Agent 任务走 Coding Plan审批规则和 Key 配置在三条链路里是通用的。把这篇的 config.toml 骨架和 CLI 验证命令跑一遍你就能从入门到应用把 OpenClaw 的审批链路完整跑通。
