Exec 审批 — 高级

​

安全二进制（仅 stdin）

​

argv 验证与被拒绝的标志

• 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
• tail: --follow、--retry、-F、-f
• wc: --files0-from

​

可信二进制目录

​

Shell 串联、包装器与多路复用器

​

安全二进制与 allowlist 的对比

• safeBins 来自配置（tools.exec.safeBins 或每个代理的 agents.entries.*.tools.exec.safeBins）。
• safeBinTrustedDirs 来自配置（tools.exec.safeBinTrustedDirs 或每个代理的 agents.entries.*.tools.exec.safeBinTrustedDirs）。
• safeBinProfiles 来自配置（tools.exec.safeBinProfiles 或每个代理的 agents.entries.*.tools.exec.safeBinProfiles）。按代理的配置文件键会覆盖全局键。
• allowlist 条目存放在主机本地的 approvals 文档中，位于 agents.<id>.allowlist 下（或通过 Control UI / openclaw approvals allowlist ...）。
• 当 safeBins 中出现解释器/运行时二进制但没有显式配置文件时，openclaw security audit 会以 tools.exec.safe_bins_interpreter_unprofiled 发出警告。
• openclaw doctor --fix 可以将缺失的自定义 safeBinProfiles.<bin> 条目脚手架化为 {}（之后请复查并收紧）。解释器/运行时二进制不会自动脚手架化。

{
  tools: {
    exec: {
      safeBins: ["myfilter"],
      safeBinProfiles: {
        myfilter: {
          minPositional: 0,
          maxPositional: 0,
          allowedValueFlags: ["-n", "--limit"],
          deniedFlags: ["-f", "--file", "-c", "--command"],
        },
      },
    },
  },
}

​

解释器/运行时命令

• 始终绑定精确的 argv/cwd/env 上下文。
• 直接脚本文件和直接运行时文件形式会尽力绑定到一个具体的本地 文件快照。
• 仍会解析为单个直接本地文件的常见包管理器包装器形式（例如 pnpm exec、pnpm node、npm exec、npx）会在绑定前展开。
• 如果 OpenClaw 无法为某个解释器/运行时命令精确识别一个具体的本地文件 （例如包脚本、eval 形式、运行时特定加载器链，或歧义的多文件 形式），则会拒绝带审批的执行，而不是声称它并不具备的语义覆盖。
• 对于这些工作流，请优先使用沙箱、单独的主机边界，或显式受信任的 allowlist/完整工作流，由操作员接受更宽泛的运行时语义。

​

后续投递行为

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

​

第三方客户端的最小作用域

​

审批转发到聊天频道

{
  approvals: {
    exec: {
      enabled: true,
      mode: "session", // "session" | "targets" | "both"
      agentFilter: ["main"],
      sessionFilter: ["discord"], // 子串或正则
      targets: [
        { channel: "slack", to: "U12345678" },
        { channel: "telegram", to: "123456789" },
      ],
    },
  },
}

/approve <id> allow-once
/approve <id> allow-always
/approve <id> deny

​

插件审批转发

{
  approvals: {
    plugin: {
      enabled: true,
      mode: "targets",
      agentFilter: ["main"],
      targets: [
        { channel: "slack", to: "U12345678" },
        { channel: "telegram", to: "123456789" },
      ],
    },
  },
}

​

任意频道上的同聊审批

​

原生审批投递

• host exec policy 仍然决定是否需要 exec 审批
• approvals.exec 控制将审批提示转发到其他聊天目的地
• channels.<channel>.execApprovals 控制 Discord、Slack、Telegram、QQ bot 以及类似的 频道特定原生客户端是否启用
• Slack 插件审批在请求来自 Slack 且 Slack 插件审批者可解析时，可以使用 Slack 的原生审批客户端；即使 Slack exec 审批被禁用，approvals.plugin 也可以将插件审批路由到 Slack 会话或目标
• 当请求来自 Google Chat 空间或线程，并且能从 dm.allowFrom 或 defaultTo 解析出稳定的 users/<id> 审批者时，Google Chat 原生审批卡可处理 exec 和插件审批；它们不使用 reaction 事件来做决策
• WhatsApp 和 Signal 的 reaction 审批投递受 approvals.exec 和 approvals.plugin 约束；它们没有 channels.<channel>.execApprovals 区块

• 该频道支持原生审批投递
• 可以从显式的 execApprovals.approvers 或所有者身份中解析出审批者， 例如 commands.ownerAllowFrom
• channels.<channel>.execApprovals.enabled 未设置或为 "auto"

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*
• QQ bot: channels.qqbot.execApprovals.*
• Google Chat: 使用 channels.googlechat.dm.allowFrom 或 channels.googlechat.defaultTo 配置稳定的审批者；不需要 execApprovals 区块
• WhatsApp: 使用 approvals.exec 和 approvals.plugin 将审批提示路由到 WhatsApp
• Signal: 使用 approvals.exec 和 approvals.plugin 将审批提示路由到 Signal

• Telegram 默认将审批发送给审批者私信（target: "dm"）。切换为 channel 或 both，也会在发起审批的 Telegram 聊天/话题中显示审批提示。对于 Telegram 论坛话题，OpenClaw 会保留话题上下文用于审批提示和审批后的跟进。
• Discord 和 Telegram 的审批者可以是显式指定的（execApprovals.approvers）或从 commands.ownerAllowFrom 推断；只有已解析的审批者才能批准或拒绝。
• Slack 审批者可以是显式指定的（execApprovals.approvers）或从 commands.ownerAllowFrom 推断。Slack 插件审批私信使用来自 allowFrom 和账户默认路由的 Slack 插件审批者，而不是 Slack exec 审批者。Slack 原生按钮会保留审批 ID 类型，因此 plugin: ID 可以在不需要第二层 Slack 本地回退的情况下解析插件审批。
• Google Chat 原生卡片会在消息文本中保留手动 /approve 回退，但卡片按钮回调只携带不透明的动作令牌；审批 ID 和决策会从服务器端待处理状态中恢复。
• 当匹配的顶层转发族路由到 WhatsApp 时，WhatsApp 表情审批可同时处理 exec 和插件提示。原生来源提示直接绑定；共享目标模式投递会将相同的有类型审批元数据绑定到被接受的 WhatsApp 消息回执上。
• 仅当匹配的顶层转发族已启用并路由到 Signal 时，Signal 反应审批才会同时处理 exec 和插件提示。直接的同聊 Signal exec 审批可以在没有显式审批者的情况下抑制本地 /approve 回退；但 Signal 反应解析仍需要来自 channels.signal.allowFrom 或 defaultTo 的显式 Signal 审批者。
• Matrix 原生私信/频道路由和反应快捷方式可同时处理 exec 和插件审批；插件授权仍来自 channels.matrix.dm.allowFrom。Matrix 原生提示会在第一个提示事件中包含 com.openclaw.approval 自定义事件内容，这样支持 OpenClaw 的 Matrix 客户端就能读取结构化审批状态，而原生客户端则保留纯文本 /approve 回退。
• 原生 Discord 和 Telegram 审批按钮会在传输私有的回调数据中携带明确的 exec 或 plugin 所有者类型，并且只解析该所有者。旧版缺少类型的 /approve 控件仍然是一条有限的兼容路径：它们只会尝试执行操作者可能批准的所有者类型，仅在收到“未找到审批”结果后继续，并且绝不会从审批 ID 推断所有权。
• 请求者不需要是审批者。
• 如果没有任何操作员 UI 或已配置的审批客户端能够接受该请求，提示会回退到 askFallback。

• Discord
• Telegram
• QQ bot

​

官方移动端操作员应用

​

macOS IPC 流程

Gateway -> Node 服务 (WS)
                 |  IPC (UDS + token + HMAC + TTL)
                 v
             Mac 应用（界面 + 审批 + system.run）

• Unix socket mode 0600, token stored in the exec_approvals_config row of state/openclaw.sqlite.
• Same-UID peer check.
• Challenge/response (nonce + HMAC token + request hash) + short TTL.

​

常见问题

​

在审批目标上，什么时候会使用 accountId 和 threadId？

{
  approvals: {
    exec: {
      enabled: true,
      mode: "targets",
      targets: [
        {
          channel: "telegram",
          to: "-1001234567890",
          accountId: "ops-bot",
          threadId: "77",
        },
      ],
    },
  },
  channels: {
    telegram: {
      accounts: {
        default: {
          name: "Primary bot",
          botToken: "env:TELEGRAM_PRIMARY_BOT_TOKEN",
        },
        "ops-bot": {
          name: "Operations bot",
          botToken: "env:TELEGRAM_OPS_BOT_TOKEN",
        },
      },
    },
  },
}

​

当审批发送到某个会话时，该会话中的任何人都可以批准吗？

​

相关内容

• 执行审批 — 核心策略和审批流程
• 执行工具
• 提升模式
• 技能 — 基于技能的自动允许行为