​

执行审批

​

适用范围

• Gateway 网关主机 → Gateway 网关机器上的 openclaw 进程
• 节点主机 → 节点运行器（macOS 配套应用或无头节点主机）

• 通过 Gateway 网关认证的调用方是该 Gateway 网关的受信任操作员。
• 已配对节点会将这种受信任操作员能力扩展到节点主机。
• 执行审批会降低意外执行风险，但它不是按用户划分的身份验证边界。
• 已批准的节点主机运行会绑定规范化执行上下文：规范化 cwd、精确 argv、存在时的环境变量绑定，以及适用时固定的可执行文件路径。
• 对于 shell 脚本和直接解释器 / 运行时文件调用，OpenClaw 还会尝试绑定 一个具体的本地文件操作数。如果该绑定文件在审批之后、执行之前发生变化， 则该运行会被拒绝，而不是执行已漂移的内容。
• 这种文件绑定有意设计为尽力而为，并不是覆盖所有 解释器 / 运行时加载路径的完整语义模型。如果审批模式无法准确识别并绑定唯一的具体本地 文件，它会拒绝签发基于审批的运行，而不是假装已实现完整覆盖。

• 节点主机服务 通过本地 IPC 将 system.run 转发给 macOS 应用。
• macOS 应用 负责执行审批并在 UI 上下文中执行命令。

​

设置与存储

{
  "version": 1,
  "socket": {
    "path": "~/.openclaw/exec-approvals.sock",
    "token": "base64url-token"
  },
  "defaults": {
    "security": "deny",
    "ask": "on-miss",
    "askFallback": "deny",
    "autoAllowSkills": false
  },
  "agents": {
    "main": {
      "security": "allowlist",
      "ask": "on-miss",
      "askFallback": "deny",
      "autoAllowSkills": true,
      "allowlist": [
        {
          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",
          "pattern": "~/Projects/**/bin/rg",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}

​

无审批 “YOLO” 模式

• OpenClaw 配置中的请求执行策略（tools.exec.*）
• ~/.openclaw/exec-approvals.json 中主机本地审批策略

• tools.exec.security: 在 gateway/node 上为 full
• tools.exec.ask: off
• 主机 askFallback: full

• tools.exec.host=auto 用于选择执行运行位置：如果有沙箱则在沙箱中，否则在 Gateway 网关上。
• YOLO 用于选择主机执行如何获批：security=full 加 ask=off。
• 在 YOLO 模式下，OpenClaw 不会在已配置的主机执行策略之上，再额外增加单独的启发式命令混淆审批门控。
• auto 不会让 Gateway 网关路由成为来自沙箱隔离会话的免费覆盖方式。单次调用的 host=node 请求在 auto 下是允许的，而 host=gateway 仅在没有活动沙箱运行时时，才允许从 auto 发起。如果你想要稳定的非 auto 默认值，请设置 tools.exec.host 或显式使用 /exec host=...。

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart

openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

openclaw exec-policy preset yolo

• 本地 tools.exec.host/security/ask
• 本地 ~/.openclaw/exec-approvals.json 默认值

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• openclaw exec-policy 不会同步节点审批
• openclaw exec-policy set --host node 会被拒绝
• 节点执行审批会在运行时从节点获取，因此面向节点的更新必须使用 openclaw approvals --node ...

• /exec security=full ask=off 只会更改当前会话。
• /elevated full 是一个紧急放行快捷方式，它也会为当前会话跳过执行审批。

​

策略旋钮

​

安全性（exec.security）

• deny：阻止所有主机执行请求。
• allowlist：只允许允许列表中的命令。
• full：允许一切（等同于提权）。

​

询问（exec.ask）

• off：从不提示。
• on-miss：仅当允许列表未匹配时提示。
• always：每个命令都提示。
• 当有效询问模式为 always 时，持久信任 allow-always 不会抑制提示

​

询问回退（askFallback）

• deny：阻止。
• allowlist：仅在允许列表匹配时允许。
• full：允许。

​

内联解释器 eval 加固（tools.exec.strictInlineEval）

• python -c
• node -e, node --eval, node -p
• ruby -e
• perl -e, perl -E
• php -r
• lua -e
• osascript -e

• 这些命令仍然需要显式审批；
• allow-always 不会自动为它们持久化新的允许列表条目。

​

允许列表（按智能体）

• ~/Projects/**/bin/peekaboo
• ~/.local/bin/*
• /opt/homebrew/bin/rg

• id：用于 UI 标识的稳定 UUID（可选）
• last used：上次使用时间戳
• last used command：上次使用的命令
• last resolved path：上次解析的路径

​

自动允许 Skills CLI

• 这是一个隐式的便捷允许列表，独立于手动路径允许列表条目。
• 它适用于 Gateway 网关与节点处于同一信任边界内的受信任操作员环境。
• 如果你需要严格的显式信任，请保持 autoAllowSkills: false 并仅使用手动路径允许列表条目。

​

安全二进制文件（仅 stdin）

• grep: --dereference-recursive, --directories, --exclude-from, --file, --recursive, -R, -d, -f, -r
• jq: --argfile, --from-file, --library-path, --rawfile, --slurpfile, -L, -f
• sort: --compress-program, --files0-from, --output, --random-source, --temporary-directory, -T, -o
• wc: --files0-from

​

安全二进制文件与允许列表

• safeBins 来自配置（tools.exec.safeBins 或按智能体划分的 agents.list[].tools.exec.safeBins）。
• safeBinTrustedDirs 来自配置（tools.exec.safeBinTrustedDirs 或按智能体划分的 agents.list[].tools.exec.safeBinTrustedDirs）。
• safeBinProfiles 来自配置（tools.exec.safeBinProfiles 或按智能体划分的 agents.list[].tools.exec.safeBinProfiles）。按智能体划分的配置键会覆盖全局键。
• 允许列表条目保存在主机本地 ~/.openclaw/exec-approvals.json 的 agents.<id>.allowlist 下（或通过 Control UI / openclaw approvals allowlist ...）。
• 当解释器 / 运行时二进制文件出现在 safeBins 中但没有显式配置文件时，openclaw security audit 会发出 tools.exec.safe_bins_interpreter_unprofiled 警告。
• openclaw doctor --fix 可以为缺失的自定义 safeBinProfiles.<bin> 条目生成 {} 骨架（之后请审查并收紧）。解释器 / 运行时二进制文件不会被自动生成骨架。

​

Control UI 编辑

​

审批流程

• 节点执行路径会预先准备一个规范化计划
• 审批记录会存储该计划及其绑定元数据
• 一旦获批，最终转发的 system.run 调用会复用存储的计划 而不是信任调用方后续的修改
• 如果调用方在审批请求创建后更改了 command、rawCommand、cwd、agentId 或 sessionKey，Gateway 网关会将转发的运行拒绝为审批不匹配

​

解释器 / 运行时命令

• 始终绑定精确的 argv / cwd / 环境变量上下文。
• 直接 shell 脚本和直接运行时文件形式会尽力绑定到一个具体的本地 文件快照。
• 仍然可以解析到单个直接本地文件的常见包管理器包装形式（例如 pnpm exec、pnpm node、npm exec、npx）会在绑定前被解包。
• 如果 OpenClaw 无法为解释器 / 运行时命令准确识别一个具体的本地文件 （例如包脚本、eval 形式、运行时特定加载链或有歧义的多文件形式）， 则会拒绝基于审批的执行，而不是声称具备它其实没有的语义覆盖。
• 对于这些工作流，建议优先选择沙箱隔离、单独的主机边界，或显式的 受信任允许列表 / full 工作流，由操作员接受更广泛的运行时语义。

​

后续投递行为

• 如果存在有效的外部投递目标（可投递渠道加目标 to），后续投递会使用该渠道。
• 在仅 webchat 或仅内部会话流程中，如果没有外部目标，后续投递会保持仅会话内（deliver: false）。
• 如果调用方显式请求严格外部投递，但没有可解析的外部渠道，请求会以 INVALID_REQUEST 失败。
• 如果启用了 bestEffortDeliver 且无法解析任何外部渠道，投递会降级为仅会话内，而不是失败。

• command + args
• cwd
• 智能体 id
• 已解析的可执行文件路径
• 主机 + 策略元数据

• Allow once → 立即运行
• Always allow → 添加到允许列表 + 运行
• Deny → 阻止

​

将审批转发到聊天渠道

​

插件审批转发

​

任意渠道中的同聊天审批

​

原生审批投递

• 主机执行策略仍然决定是否需要执行审批
• approvals.exec 控制是否将审批提示转发到其他聊天目标
• channels.<channel>.execApprovals 控制该渠道是否充当原生审批客户端

• 该渠道支持原生审批投递
• 可通过显式 execApprovals.approvers 或该 渠道文档说明的回退来源解析出审批人
• channels.<channel>.execApprovals.enabled 未设置或为 "auto"

• Discord：channels.discord.execApprovals.*
• Slack：channels.slack.execApprovals.*
• Telegram：channels.telegram.execApprovals.*

• Slack、Matrix、Microsoft Teams 和类似的可投递聊天会针对同聊天 /approve 使用正常的渠道身份验证模型
• 当原生审批客户端自动启用时，默认的原生投递目标是审批人私信
• 对于 Discord 和 Telegram，只有已解析出的审批人才能批准或拒绝
• Discord 审批人可以显式配置（execApprovals.approvers），也可以从 commands.ownerAllowFrom 推断
• Telegram 审批人可以显式配置（execApprovals.approvers），也可以从现有所有者配置推断（allowFrom，以及在支持时的私信 defaultTo）
• Slack 审批人可以显式配置（execApprovals.approvers），也可以从 commands.ownerAllowFrom 推断
• Slack 原生按钮会保留审批 id 类型，因此 plugin: id 可以解析到插件审批， 无需第二层 Slack 本地回退
• Matrix 原生私信 / 渠道路由和表情反应快捷方式同时处理执行审批和插件审批； 插件授权仍然来自 channels.matrix.dm.allowFrom
• 请求发起者不需要是审批人
• 当原始聊天本身已经支持命令和回复时，该聊天可以直接通过 /approve 审批
• 原生 Discord 审批按钮按审批 id 类型路由：plugin: id 会 直接进入插件审批，其余所有情况都会进入执行审批
• 原生 Telegram 审批按钮遵循与 /approve 相同的有限执行到插件回退逻辑
• 当原生 target 启用原始聊天投递时，审批提示会包含命令文本
• 待处理的执行审批默认会在 30 分钟后过期
• 如果没有操作员 UI 或已配置的审批客户端可以接受请求，提示会回退到 askFallback

• Discord
• Telegram

​

macOS IPC 流程

• Unix socket 模式为 0600，token 存储在 exec-approvals.json 中。
• 同一 UID 对等方检查。
• 质询 / 响应（nonce + HMAC token + 请求哈希）+ 短 TTL。

​

系统事件

• Exec running（仅当命令超过运行中通知阈值时）
• Exec finished
• Exec denied

​

审批被拒绝时的行为

​

影响

• full 权限很强；尽可能优先使用允许列表。
• ask 让你保持知情，同时仍然支持快速审批。
• 按智能体划分的允许列表可防止某个智能体的审批泄漏到其他智能体。
• 审批仅适用于来自已授权发送者的主机执行请求。未授权发送者无法发出 /exec。
• /exec security=full 是面向已授权操作员的会话级便捷方式，并且按设计会跳过审批。 如需强制阻止主机执行，请将审批安全性设为 deny，或通过工具策略拒绝 exec 工具。

• 执行工具
• 提权模式
• Skills

​

相关

• Exec — shell 命令执行工具
• 沙箱隔离 — 沙箱模式和工作区访问
• 安全性 — 安全模型和加固
• 沙箱隔离 vs 工具策略 vs 提权 — 何时使用各自方案