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
• wc: --files0-from

​

可信二进制目录

​

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

​

安全二进制与 allowlist 的对比

• safeBins 来自配置（tools.exec.safeBins 或按 agent 的 agents.list[].tools.exec.safeBins）。
• safeBinTrustedDirs 来自配置（tools.exec.safeBinTrustedDirs 或按 agent 的 agents.list[].tools.exec.safeBinTrustedDirs）。
• safeBinProfiles 来自配置（tools.exec.safeBinProfiles 或按 agent 的 agents.list[].tools.exec.safeBinProfiles）。按 agent 的配置文件键会覆盖全局键。
• allowlist 条目位于宿主本地的 ~/.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> 条目脚手架化为 {}（之后请自行审查并收紧）。解释器/运行时二进制不会自动脚手架化。

{
  tools: {
    exec: {
      safeBins: ["jq", "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 still decides whether exec approval is required
• approvals.exec controls forwarding approval prompts to other chat destinations
• channels.<channel>.execApprovals controls whether Discord, Slack, Telegram, and similar channel-specific native clients are enabled
• Slack plugin approvals can use Slack’s native approval client when the request comes from Slack and Slack plugin approvers resolve; approvals.plugin can also route plugin approvals to Slack sessions or targets even when Slack exec approvals are disabled
• Google Chat native approval cards handle exec and plugin approvals that originate from Google Chat spaces or threads when stable users/<id> approvers resolve from dm.allowFrom or defaultTo; they do not use reaction events for decisions
• WhatsApp and Signal reaction approval delivery are gated by approvals.exec and approvals.plugin; they do not have channels.<channel>.execApprovals blocks

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

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*
• Google Chat: configure stable approvers with channels.googlechat.dm.allowFrom or channels.googlechat.defaultTo; no execApprovals block is required
• WhatsApp: use approvals.exec and approvals.plugin to route approval prompts to WhatsApp
• Signal: use approvals.exec and approvals.plugin to route approval prompts to Signal

• Slack, Matrix, Microsoft Teams, and similar deliverable chats use the normal channel auth model for same-chat /approve
• when a native approval client auto-enables, the default native delivery target is approver DMs
• for Discord and Telegram, only resolved approvers can approve or deny
• Discord approvers can be explicit (execApprovals.approvers) or inferred from commands.ownerAllowFrom
• Telegram approvers can be explicit (execApprovals.approvers) or inferred from commands.ownerAllowFrom
• Slack approvers can be explicit (execApprovals.approvers) or inferred from commands.ownerAllowFrom
• Slack plugin approval DMs use Slack plugin approvers from allowFrom and account default routing, not Slack exec approvers
• Slack native buttons preserve approval id kind, so plugin: ids can resolve plugin approvals without a second Slack-local fallback layer
• Google Chat native cards preserve the manual /approve fallback in message text but card button callbacks carry only opaque action tokens; approval id and decision are recovered from server-side pending state
• WhatsApp emoji approvals handle both exec and plugin prompts only when the matching top-level forwarding family is enabled and routes to WhatsApp; target-only WhatsApp forwarding stays on the shared forwarding path unless it matches the same native origin target
• Signal reaction approvals handle both exec and plugin prompts only when the matching top-level forwarding family is enabled and routes to Signal. Direct same-chat Signal exec approvals can suppress the local /approve fallback without explicit approvers; Signal reaction resolution still requires explicit Signal approvers from channels.signal.allowFrom or defaultTo.
• Matrix native DM/channel routing and reaction shortcuts handle both exec and plugin approvals; plugin authorization still comes from channels.matrix.dm.allowFrom
• Matrix native prompts include com.openclaw.approval custom event content on the first prompt event so OpenClaw-aware Matrix clients can read structured approval state while stock clients keep the plain-text /approve fallback
• the requester does not need to be an approver
• the originating chat can approve directly with /approve when that chat already supports commands and replies
• native Discord approval buttons route by approval id kind: plugin: ids go straight to plugin approvals, everything else goes to exec approvals
• native Telegram approval buttons follow the same bounded exec-to-plugin fallback as /approve
• when native target enables origin-chat delivery, approval prompts include the command text
• pending exec approvals expire after 30 minutes by default
• if no operator UI or configured approval client can accept the request, the prompt falls back to askFallback

• Discord
• Telegram

​

macOS IPC 流程

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

• Unix socket 模式为 0600，token 存储在 exec-approvals.json 中。
• 同 UID 对等方检查。
• 挑战/响应（nonce + HMAC token + request hash）+ 短 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",
        },
      },
    },
  },
}

​

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

​

相关内容

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