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

​

信頼済みバイナリディレクトリ

​

シェルの連結、ラッパー、マルチプレクサー

​

セーフバイナリと許可リストの比較

• 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）から取得されます。エージェントごとのプロファイルキーはグローバルキーを上書きします。
• 許可リストエントリは、agents.<id>.allowlist 配下のホストローカルな承認ファイル（または Control UI / openclaw approvals allowlist ... 経由）に保存されます。
• openclaw security audit は、明示的なプロファイルがないインタープリター/ランタイムのバイナリが safeBins に存在すると、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 がインタープリター/ランタイムコマンドについて具体的なローカルファイルを正確に 1 つ特定できない場合 （例: パッケージスクリプト、評価形式、ランタイム固有のローダーチェーン、または曖昧な複数ファイル 形式）、実際には提供できない意味的な網羅性を主張する代わりに、承認に基づく実行が拒否されます。
• これらのワークフローでは、サンドボックス化、別のホスト境界、またはオペレーターがより広範な ランタイムセマンティクスを受け入れる明示的に信頼された許可リスト/完全なワークフローを推奨します。

​

フォローアップ配信の動作

• 有効な外部配信先（配信可能なチャネルとターゲット to）が存在する場合、フォローアップ配信にはそのチャネルが使用されます。
• 外部ターゲットがない Web チャットのみのフローまたは内部セッションフローでは、フォローアップ配信はセッション内のみに留まります（deliver: false）。
• 解決可能な外部チャネルがない状態で呼び出し元が厳格な外部配信を明示的に要求した場合、リクエストは INVALID_REQUEST で失敗します。
• bestEffortDeliver が有効で、外部チャネルを解決できない場合、配信は失敗する代わりにセッション内のみにダウングレードされます。

​

サードパーティークライアントの最小スコープ

​

チャットチャネルへの承認転送

{
  approvals: {
    exec: {
      enabled: true,
      mode: "session", // "session" | "targets" | "both"
      agentFilter: ["main"],
      sessionFilter: ["discord"], // substring or regex
      targets: [
        { channel: "slack", to: "U12345678" },
        { channel: "telegram", to: "123456789" },
      ],
    },
  },
}

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

​

Plugin 承認の転送

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

​

任意のチャネルでの同一チャット内承認

​

ネイティブ承認配信

• exec 承認が必要かどうかは、引き続きホストの exec ポリシーによって決まります
• approvals.exec は、承認プロンプトを他のチャット宛先に転送するかどうかを制御します
• channels.<channel>.execApprovals は、Discord、Slack、Telegram、QQ bot、および同様のチャネル固有のネイティブクライアントを有効にするかどうかを制御します
• リクエストが Slack から送られ、Slack Plugin 承認者を解決できる場合、Slack Plugin 承認では Slack のネイティブ承認クライアントを使用できます。approvals.plugin は、Slack の exec 承認が無効な場合でも、Plugin 承認を Slack のセッションまたはターゲットにルーティングできます
• Google Chat のネイティブ承認カードは、dm.allowFrom または defaultTo から安定した users/<id> 承認者を解決できる場合に、Google Chat のスペースまたはスレッドから発生した exec 承認と Plugin 承認を処理します。決定にはリアクションイベントを使用しません
• WhatsApp と Signal のリアクション承認配信は、approvals.exec と approvals.plugin によって制限されます。これらには channels.<channel>.execApprovals ブロックはありません

• チャネルがネイティブ承認配信をサポートしている
• 明示的な execApprovals.approvers、または commands.ownerAllowFrom などの所有者 ID から承認者を解決できる
• 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 はデフォルトで承認者への DM（target: "dm"）を使用します。発生元の Telegram チャットまたはトピックにも承認プロンプトを表示するには、channel または both に切り替えます。Telegram のフォーラムトピックでは、OpenClaw は承認プロンプトと承認後のフォローアップでトピックを維持します。
• Discord と Telegram の承認者は、明示的に指定する（execApprovals.approvers）か、commands.ownerAllowFrom から推論できます。解決済みの承認者だけが承認または拒否できます。
• Slack の承認者は、明示的に指定する（execApprovals.approvers）か、commands.ownerAllowFrom から推論できます。Slack Plugin 承認の DM では、Slack の exec 承認者ではなく、allowFrom の Slack Plugin 承認者とアカウントのデフォルトルーティングを使用します。Slack のネイティブボタンは承認 ID の種類を保持するため、plugin: ID は Slack 内の第 2 フォールバックレイヤーを使用せずに Plugin 承認を解決できます。
• Google Chat のネイティブカードは、メッセージテキスト内に手動の /approve フォールバックを保持しますが、カードボタンのコールバックには不透明なアクショントークンのみが含まれます。承認 ID と決定は、サーバー側の保留状態から復元されます。
• WhatsApp の絵文字承認は、対応するトップレベルの転送ファミリーが WhatsApp にルーティングされている場合、exec と Plugin の両方のプロンプトを処理します。ネイティブ由来のプロンプトは直接バインドされます。共有ターゲットモードの配信では、同じ型付き承認メタデータが受理済みの WhatsApp メッセージ受信記録にバインドされます。
• Signal のリアクション承認は、対応するトップレベルの転送ファミリーが有効で Signal にルーティングされている場合にのみ、exec と Plugin の両方のプロンプトを処理します。同一チャット内の直接的な Signal exec 承認では、明示的な承認者なしでもローカルの /approve フォールバックを抑制できます。Signal のリアクション解決には、引き続き channels.signal.allowFrom または defaultTo の明示的な Signal 承認者が必要です。
• Matrix のネイティブ DM/チャネルルーティングとリアクションショートカットは、exec と Plugin の両方の承認を処理します。Plugin の認可には引き続き 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 + トークン + HMAC + TTL)
                 v
             Mac アプリ (UI + 承認 + system.run)

• Unix ソケットモード 0600、トークンは exec-approvals.json に保存されます。
• 同一 UID のピアチェック。
• チャレンジ/レスポンス（nonce + HMAC トークン + リクエストハッシュ）+ 短い TTL。

​

FAQ

​

承認ターゲットで 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",
        },
      },
    },
  },
}

​

承認がセッションに送信された場合、そのセッション内の誰でも承認できますか？

​

関連項目

• Exec 承認 — コアポリシーと承認フロー
• Exec ツール
• 昇格モード
• Skills — スキルに基づく自動許可の動作