実行承認

Exec 承認は、サンドボックス化されたエージェントが実ホスト（gateway または node）でコマンドを実行できるようにするための コンパニオンアプリ / ノードホストのガードレール です。安全インターロックとして、コマンドはポリシー + allowlist + （任意の）ユーザー承認がすべて一致した場合にのみ許可されます。Exec 承認は、ツールポリシーと昇格ゲートの 上に重ねて 適用されます（ただし昇格が full に設定されている場合は承認をスキップします）。

有効なポリシーの確認

ローカルスコープが host=node を要求すると、exec-policy show はローカル承認ファイルが正本であるかのように見せるのではなく、そのスコープを実行時にノード管理として報告します。

コンパニオンアプリの UI が 利用できない 場合、通常ならプロンプトを出すリクエストは ask フォールバック（デフォルト: deny）で解決されます。

適用される場所

Exec 承認は、実行ホスト上でローカルに強制されます。

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

信頼モデル

• Gateway 認証済みの呼び出し元は、その Gateway の信頼されたオペレーターです。
• ペアリング済みノードは、その信頼されたオペレーター能力をノードホストへ拡張します。
• Exec 承認は誤実行のリスクを低減しますが、ユーザーごとの認証境界やファイルシステムの読み取り専用ポリシーではありません。
• 承認されると、コマンドは選択されたホストまたはサンドボックスのファイルシステム権限に従ってファイルを変更できます。
• 承認済みのノードホスト実行は、正準の実行コンテキストをバインドします。正準 cwd、正確な argv、存在する場合の env バインド、該当する場合の固定された実行可能ファイルパスです。
• シェルスクリプトと、インタープリターまたはランタイムファイルの直接呼び出しについて、OpenClaw は 1 つの具体的なローカルファイルオペランドのバインドも試みます。そのバインドされたファイルが承認後から実行前までに変更された場合、ずれた内容を実行するのではなく、その実行は拒否されます。
• ファイルバインドは意図的にベストエフォートであり、すべてのインタープリターまたはランタイムローダーパスの完全な意味モデルでは ありません。承認モードがバインド対象として 1 つの具体的なローカルファイルを正確に識別できない場合、完全にカバーできるふりをするのではなく、承認に基づく実行の発行を拒否します。

macOS の分離

• ノードホストサービス は system.run をローカル IPC 経由で macOS アプリ に転送します。
• macOS アプリ は承認を強制し、UI コンテキストでコマンドを実行します。

設定と保存場所

承認は、実行ホスト上のローカル JSON ファイルに保存されます。

~/.openclaw/exec-approvals.json

スキーマ例:

{  "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",          "source": "allow-always",          "commandText": "rg -n TODO",          "lastUsedAt": 1737150000000,          "lastUsedCommand": "rg -n TODO",          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"        }      ]    }  }}

ポリシーの調整項目

exec.security

exec.ask

askFallback

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 によって新しい allowlist エントリーが自動的に永続化されることはありません。

tools.exec.commandHighlighting

この設定は security、ask、allowlist マッチング、厳格なインライン評価の挙動、承認の転送、コマンド実行を変更 しません。tools.exec.commandHighlighting の下でグローバルに設定するか、agents.list[].tools.exec.commandHighlighting の下でエージェントごとに設定できます。

YOLO モード（承認なし）

承認プロンプトなしでホスト exec を実行したい場合は、両方の ポリシーレイヤーを開く必要があります。OpenClaw 設定の要求 exec ポリシー（tools.exec.*）と、~/.openclaw/exec-approvals.json 内のホストローカル承認ポリシーです。

明示的に厳しくしない限り、YOLO がデフォルトのホスト動作です。

独自の非対話型権限モードを公開する CLI ベースのプロバイダーは、このポリシーに従えます。Claude CLI は、OpenClaw の要求 exec ポリシーが YOLO の場合に --permission-mode bypassPermissions を追加します。そのバックエンド動作を上書きするには、agents.defaults.cliBackends.claude-cli.args / resumeArgs の下に明示的な Claude 引数を設定します。たとえば --permission-mode default、acceptEdits、bypassPermissions です。

より保守的な設定にしたい場合は、どちらかのレイヤーを allowlist / on-miss または deny に戻して厳しくしてください。

永続的な Gateway ホストの「プロンプトなし」設定

openclaw config set tools.exec.host gatewayopenclaw config set tools.exec.security fullopenclaw config set tools.exec.ask offopenclaw 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 デフォルト。

これは意図的にローカル専用です。Gateway ホストまたはノードホストの承認をリモートで変更するには、openclaw approvals set --gateway または openclaw approvals set --node <id|name|ip> を使用します。

ノードホスト

ノードホストの場合は、代わりに同じ承認ファイルをそのノードに適用します。

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 承認もスキップする緊急用ショートカットです。

ホスト承認ファイルが設定より厳しいままの場合は、より厳しいホストポリシーが引き続き優先されます。

Allowlist（エージェントごと）

Allowlist は エージェントごと です。複数のエージェントが存在する場合は、macOS アプリで編集対象のエージェントを切り替えてください。パターンは glob マッチです。

パターンには、解決済みバイナリパスの glob または素のコマンド名 glob を指定できます。素の名前は PATH 経由で呼び出されたコマンドにのみ一致するため、コマンドが rg の場合、rg は /opt/homebrew/bin/rg に一致できますが、./rg や /tmp/rg には 一致しません。特定の 1 つのバイナリ位置を信頼したい場合は、パス glob を使用してください。

レガシーの agents.default エントリーは、読み込み時に agents.main へ移行されます。echo ok && pwd のようなシェルチェーンでは、引き続き各トップレベルセグメントが allowlist ルールを満たす必要があります。

例:

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

argPattern による引数の制限

Allowlist エントリーがバイナリと特定の引数形状に一致する必要がある場合は、argPattern を追加します。OpenClaw は、実行可能ファイルトークン（argv[0]）を除いた解析済みコマンド引数に対して正規表現を評価します。手書きのエントリーでは、引数は単一スペースで結合されるため、完全一致が必要な場合はパターンをアンカーしてください。

{  "version": 1,  "agents": {    "main": {      "allowlist": [        {          "pattern": "python3",          "argPattern": "^safe\\.py$"        }      ]    }  }}

このエントリーは python3 safe.py を許可します。python3 other.py は allowlist ミスです。同じバイナリに対するパスのみのエントリーも存在する場合、一致しなかった引数は引き続きそのパスのみのエントリーへフォールバックできます。目的がバイナリを宣言済みの引数に制限することなら、パスのみのエントリーは省略してください。

Entries saved by approval flows は、正確な argv 一致のために内部セパレーター形式を使用できます。エンコードされた値を手動編集するのではなく、UI または承認フローでそれらのエントリを再生成することを推奨します。OpenClaw がコマンドセグメントの argv を解析できない場合、argPattern を持つエントリは一致しません。

各 allowlist エントリは次をサポートします。

Skills CLI の自動許可

Skills CLI の自動許可が有効な場合、既知の Skills から参照される実行可能ファイルは、Node（macOS Node または headless Node ホスト）上で allowlist 登録済みとして扱われます。これは Gateway RPC 経由で skills.bins を使用し、Skills の bin リストを取得します。厳密な手動 allowlist を使いたい場合は、これを無効にしてください。

安全な bin と承認の転送

安全な bin（stdin のみの高速パス）、インタープリターのバインディング詳細、承認プロンプトを Slack/Discord/Telegram に転送する方法（またはネイティブ承認クライアントとして実行する方法）については、Exec 承認 - 高度な設定を参照してください。

Control UI での編集

デフォルト、エージェントごとの上書き、allowlist を編集するには、Control UI → Nodes → Exec approvals カードを使用します。スコープ（デフォルトまたはエージェント）を選び、ポリシーを調整し、allowlist パターンを追加または削除してから、保存します。UI はパターンごとの最終使用メタデータを表示するため、リストを整理しておけます。

ターゲットセレクターでは、Gateway（ローカル承認）または Node を選択します。Node は system.execApprovals.get/set（macOS アプリまたは headless Node ホスト）を公開している必要があります。Node がまだ exec 承認を公開していない場合は、そのローカルの ~/.openclaw/exec-approvals.json を直接編集してください。

CLI: openclaw approvals は Gateway または Node の編集に対応しています。Approvals CLIを参照してください。

承認フロー

プロンプトが必要な場合、gateway は exec.approval.requested をオペレータークライアントへブロードキャストします。Control UI と macOS アプリは exec.approval.resolve 経由でそれを解決し、その後 gateway が承認済みリクエストを Node ホストへ転送します。

host=node の場合、承認リクエストには正規の systemRunPlan ペイロードが含まれます。gateway は、承認済みの system.run リクエストを転送するときに、そのプランをコマンド/cwd/セッションコンテキストの権威ある情報として使用します。

これは非同期承認のレイテンシーに関係します。

• Node exec パスは、最初に 1 つの正規プランを準備します。
• 承認レコードは、そのプランとバインディングメタデータを保存します。
• 承認されると、最終的に転送される system.run 呼び出しは、後続の呼び出し元による編集を信頼するのではなく、保存済みプランを再利用します。
• 承認リクエストの作成後に呼び出し元が command、rawCommand、cwd、agentId、または sessionKey を変更した場合、gateway は転送される実行を承認不一致として拒否します。

システムイベント

Exec のライフサイクルはシステムメッセージとして表示されます。

• Exec running（コマンドが実行中通知のしきい値を超えた場合のみ）。
• Exec finished。
• Exec denied。

これらは、Node がイベントを報告した後にエージェントのセッションへ投稿されます。Gateway ホストの exec 承認も、コマンド完了時（および任意でしきい値より長く実行中の場合）に同じライフサイクルイベントを送信します。承認で制御された exec は、照合しやすいように、これらのメッセージ内の runId として承認 id を再利用します。

拒否された承認の動作

非同期 exec 承認が拒否された場合、OpenClaw は、そのセッション内で同じコマンドの以前の実行から得られた出力をエージェントが再利用できないようにします。拒否理由は、コマンド出力が利用できないことを明示するガイダンスとともに渡されるため、エージェントが新しい出力があると主張したり、以前に成功した実行の古い結果を使って拒否されたコマンドを繰り返したりすることを防ぎます。

影響

• full は強力です。可能な場合は allowlist を推奨します。
• ask は、素早い承認を可能にしつつ、ユーザーが関与し続けられるようにします。
• エージェントごとの allowlist は、あるエージェントの承認が他のエージェントへ漏れることを防ぎます。
• 承認は、承認済み送信者からのホスト exec リクエストにのみ適用されます。未承認の送信者は /exec を発行できません。
• /exec security=full は、承認済みオペレーター向けのセッションレベルの利便機能であり、設計上、承認をスキップします。ホスト exec を強制的にブロックするには、承認セキュリティを deny に設定するか、ツールポリシーで exec ツールを拒否してください。

関連