​

Exec の承認

​

適用箇所

• gateway host → Gateway マシン上の openclaw プロセス
• node host → ノードランナー（macOSコンパニオンアプリまたはヘッドレスノードホスト）

• Gateway に認証された呼び出し元は、その Gateway の信頼されたオペレーターです。
• ペアリングされたノードは、その信頼されたオペレーター能力をノードホストに拡張します。
• Exec の承認は偶発的な実行リスクを減らしますが、ユーザー単位の認証境界ではありません。
• 承認されたノードホスト実行は、標準実行コンテキストを束縛します: 標準 cwd、正確な argv、存在する場合の env 束縛、適用可能な場合の固定された実行ファイルパス。
• シェルスクリプトおよびインタープリター/ランタイムによる直接ファイル実行については、OpenClaw は 1つの具体的なローカルファイルオペランドも束縛しようとします。承認後から実行前までの間にその束縛対象ファイルが変更された場合、 変更された内容は実行せず、実行は拒否されます。
• このファイル束縛は意図的にベストエフォートであり、すべての インタープリター/ランタイムのローダーパスを完全に意味的にモデル化するものではありません。承認モードで 束縛すべき具体的なローカルファイルを正確に1つ特定できない場合、完全に保護できているふりをするのではなく、 承認に裏付けられた実行の発行を拒否します。

• node host service は、ローカル IPC 経由で system.run を macOS app に転送します。
• macOS app は承認を適用し、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 設定内の要求された exec ポリシー（tools.exec.*）
• ~/.openclaw/exec-approvals.json 内のホストローカル承認ポリシー

• tools.exec.security: gateway/node では full
• tools.exec.ask: off
• ホスト askFallback: full

• tools.exec.host=auto は exec の実行場所を選びます: サンドボックスが利用可能ならサンドボックス、そうでなければ gateway。
• YOLO はホスト exec の承認方法を選びます: security=full かつ ask=off。
• 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 approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• /exec security=full ask=off は現在のセッションだけを変更します。
• /elevated full は、同じくそのセッションの exec 承認をスキップする非常用ショートカットです。

​

ポリシーのノブ

​

Security (exec.security)

• deny: すべてのホスト exec リクエストをブロックします。
• allowlist: 許可リストにあるコマンドのみ許可します。
• full: すべてを許可します（elevated と同等）。

​

Ask (exec.ask)

• off: プロンプトを一切表示しません。
• on-miss: 許可リストに一致しない場合のみプロンプトを表示します。
• always: すべてのコマンドでプロンプトを表示します。
• allow-always の永続信頼は、有効な ask モードが always の場合にはプロンプトを抑制しません

​

Ask fallback (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

​

Skill CLI の自動許可

• これは手動のパス許可リスト項目とは別の、暗黙の利便性許可リストです。
• これは Gateway とノードが同じ信頼境界にある信頼済みオペレーター環境を想定しています。
• 厳格な明示的信頼が必要な場合は、autoAllowSkills: false のままにし、手動のパス許可リスト項目だけを使用してください。

​

Safe bins（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

​

Safe bins と許可リストの比較

• 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 ... 経由）。
• openclaw security audit は、インタープリター/ランタイム bin が safeBins に明示的プロファイルなしで含まれている場合、tools.exec.safe_bins_interpreter_unprofiled を警告します。
• openclaw doctor --fix は、不足しているカスタム safeBinProfiles.<bin> 項目を {} として雛形作成できます（その後に見直して厳しくしてください）。インタープリター/ランタイム bin は自動雛形作成されません。

​

Control UI での編集

​

承認フロー

• node exec 経路は先に1つの標準 plan を準備します
• 承認レコードにはその plan と束縛メタデータが保存されます
• 承認後、最終的に転送される system.run 呼び出しでは、後からの呼び出し元の編集を信頼せず、 保存済みの plan を再利用します
• 承認リクエスト作成後に呼び出し元が command、rawCommand、cwd、agentId、または sessionKey を変更した場合、gateway は その転送実行を承認不一致として拒否します

​

インタープリター/ランタイムコマンド

• 正確な argv/cwd/env コンテキストは常に束縛されます。
• 直接シェルスクリプトおよび直接ランタイムファイル形式は、1つの具体的なローカル ファイルスナップショットにベストエフォートで束縛されます。
• 依然として1つの直接ローカルファイルに解決できる一般的なパッケージマネージャーラッパー形式（たとえば pnpm exec、pnpm node、npm exec、npx）は、束縛前に展開されます。
• OpenClaw がインタープリター/ランタイムコマンドに対して、具体的なローカルファイルを正確に1つ特定できない場合 （たとえば package scripts、eval 形式、ランタイム固有ローダーチェーン、または曖昧な複数ファイル形式）、 意味的な保護を提供できていると主張する代わりに、承認に裏付けられた実行は拒否されます。
• そのようなワークフローでは、サンドボックス化、別のホスト境界、または、より広いランタイム意味論を オペレーターが受け入れる明示的な trusted allowlist/full ワークフローを推奨します。

​

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

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

• command + args
• cwd
• agent id
• 解決された実行ファイルパス
• host + policy メタデータ

• Allow once → 今回だけ実行
• Always allow → 許可リストに追加して実行
• Deny → ブロック

​

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

​

プラグイン承認の転送

​

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

​

ネイティブ承認配信

• ホスト exec ポリシーが、依然として exec 承認が必要かどうかを決定します
• approvals.exec が、承認プロンプトを他のチャット宛先へ転送するかどうかを制御します
• channels.<channel>.execApprovals が、そのチャネルをネイティブ承認クライアントとして動作させるかどうかを制御します

• そのチャネルがネイティブ承認配信をサポートしている
• approver を明示的な execApprovals.approvers または、その チャネルで文書化された fallback ソースから解決できる
• channels.<channel>.execApprovals.enabled が未設定または "auto" である

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

• Slack、Matrix、Microsoft Teams、および同様の配信可能チャットは、同一チャット /approve に通常のチャネル認証モデルを使用します
• ネイティブ承認クライアントが自動有効化された場合、デフォルトのネイティブ配信先は approver DM です
• Discord と Telegram では、解決済み approver のみが承認または拒否できます
• Discord approver は明示的なもの（execApprovals.approvers）か、commands.ownerAllowFrom から推測されたものです
• Telegram approver は明示的なもの（execApprovals.approvers）か、既存の owner 設定（allowFrom、およびサポートされる場合はダイレクトメッセージの defaultTo）から推測されたものです
• Slack approver は明示的なもの（execApprovals.approvers）か、commands.ownerAllowFrom から推測されたものです
• Slack のネイティブボタンは承認 id の種類を保持するため、plugin: id は2つ目の Slack ローカル fallback レイヤーなしでプラグイン承認を解決できます
• Matrix のネイティブ DM/チャネルルーティングは exec 専用です。Matrix のプラグイン承認は共有の 同一チャット /approve と任意の approvals.plugin 転送経路に留まります
• リクエスターが approver である必要はありません
• 発生元チャットがすでにコマンドと返信をサポートしていれば、そのチャットから /approve で直接承認できます
• ネイティブ Discord 承認ボタンは承認 id の種類でルーティングします: plugin: id は 直接プラグイン承認へ、それ以外はすべて exec 承認へ送られます
• ネイティブ Telegram 承認ボタンは /approve と同じく、境界付きの exec-to-plugin fallback に従います
• ネイティブ target が発生元チャット配信を有効にしている場合、承認プロンプトにはコマンドテキストが含まれます
• 保留中の exec 承認はデフォルトで 30 分後に期限切れになります
• オペレーター UI または設定済み承認クライアントがどちらもリクエストを受け付けられない場合、プロンプトは askFallback にフォールバックします

• Discord
• Telegram

​

macOS IPC フロー

• Unix socket モード 0600、token は exec-approvals.json に保存されます。
• 同一 UID ピアチェック。
• Challenge/response（nonce + HMAC token + request hash）+ 短い TTL。

​

システムイベント

• Exec running（コマンドが running notice threshold を超えた場合のみ）
• Exec finished
• Exec denied

​

承認拒否時の動作

​

影響

• full は強力です。可能なら許可リストを優先してください。
• ask を使えば、すばやい承認を維持しつつ確認ループに留まれます。
• エージェントごとの許可リストにより、あるエージェントの承認が他のエージェントへ漏れるのを防げます。
• 承認は、認可された送信者からのホスト exec リクエストにのみ適用されます。未認可の送信者は /exec を発行できません。
• /exec security=full は認可済みオペレーター向けのセッションレベルの利便機能であり、設計上承認をスキップします。 ホスト exec を確実にブロックしたい場合は、承認 security を deny に設定するか、ツールポリシーで exec ツールを拒否してください。

• Exec ツール
• 昇格モード
• Skills

​

関連

• Exec — シェルコマンド実行ツール
• サンドボックス化 — サンドボックスモードとワークスペースアクセス
• セキュリティ — セキュリティモデルとハードニング
• サンドボックスとツールポリシーと Elevated の違い — それぞれをいつ使うか