Tools
実行の承認
Exec 承認は、サンドボックス化されたエージェントが実ホスト（gateway または node）でコマンドを実行できるようにするための、コンパニオンアプリ / Node ホストのガードレールです。コマンドは、ポリシー + 許可リスト +（任意の）ユーザー承認のすべてが一致した場合にのみ実行されます。承認は、ツールポリシーと昇格ゲートの上に重ねて適用されます（昇格 full ではスキップされます）。
deny、allowlist、ask、auto、full、Codex Guardian のマッピング、ACPX ハーネスの権限について、モードを中心とした概要は権限モードを参照してください。
適用範囲
Exec 承認は実行ホスト上でローカルに適用されます。
- Gateway ホスト -> Gateway マシン上の
openclawプロセス。 - Node ホスト -> Node ランナー（macOS コンパニオンアプリまたはヘッドレス Node ホスト）。
信頼モデル
- Gateway で認証された呼び出し元は、その Gateway の信頼されたオペレーターです。
- ペアリングされた Node は、その信頼されたオペレーターの権限を Node ホストまで拡張します。
- 承認は誤操作による実行リスクを軽減しますが、ユーザー単位の認証境界やファイルシステムの読み取り専用ポリシーではありません。
- 承認されると、コマンドは選択したホストまたはサンドボックスのファイルシステム権限に従ってファイルを変更できます。
- 承認済みの Node ホスト実行には、正規の実行コンテキスト（cwd、正確な argv、存在する場合は環境変数のバインド、該当する場合は固定された実行可能ファイルのパス）が結び付けられます。
- シェルスクリプトや、インタープリター / ランタイムによるファイルの直接呼び出しでは、OpenClaw は具体的なローカルファイルのオペランドを1つ結び付けることも試みます。そのファイルが承認後、実行前に変更された場合、内容が変化したファイルを実行するのではなく、実行を拒否します。
- ファイルのバインドはベストエフォートであり、すべてのインタープリター / ランタイムのローダーパスを網羅する完全なモデルではありません。具体的なローカルファイルを正確に1つ特定できない場合、OpenClaw は完全に網羅しているかのように扱わず、承認に基づく実行の発行を拒否します。
macOS での分担
- Node ホストサービスは、ローカル IPC を介して
system.runをmacOS アプリに転送します。 - macOS アプリは承認を適用し、UI コンテキストでコマンドを実行します。
有効なポリシーの確認
| コマンド | 表示内容 |
|---|---|
openclaw approvals get / --gateway / --node <id|name|ip> |
要求されたポリシー、ホストポリシーのソース、有効な結果。 |
openclaw exec-policy show |
ローカルマシンで統合されたビュー。 |
openclaw exec-policy set / preset |
ローカルで要求されたポリシーとローカルホストの承認ファイルを1ステップで同期します。 |
完全な CLI リファレンス（フラグ、JSON 出力、許可リストの追加 / 削除）については、承認 CLIを参照してください。
ローカルスコープが host=node を要求している場合、exec-policy show はローカル承認ファイルを信頼できる情報源として扱うのではなく、そのスコープが実行時に Node によって管理されることを報告します。
コンパニオンアプリの UI が利用できない場合、通常なら確認を表示するすべての要求は、確認フォールバック（デフォルト: deny）によって解決されます。
設定と保存場所
承認は、実行ホスト上のローカル JSON ファイルに保存されます。OPENCLAW_STATE_DIR が設定されている場合、ファイルはその状態ディレクトリに配置されます。設定されていない場合は、OpenClaw のデフォルト状態ディレクトリが使用されます。
$OPENCLAW_STATE_DIR/exec-approvals.json# それ以外の場合~/.openclaw/exec-approvals.jsonデフォルトの承認ソケットも同じルートに従います。$OPENCLAW_STATE_DIR/exec-approvals.sock、または変数が未設定の場合は ~/.openclaw/exec-approvals.sock です。
2026.6.6 より前のリリースでは、ファイルは常に ~/.openclaw に保存されていました。OPENCLAW_STATE_DIR が別の場所を指していて、承認ファイルがデフォルトディレクトリに残っている場合は、openclaw doctor --fix を直接1回実行して状態ディレクトリへインポートしてください（元のファイルは .migrated サフィックス付きでアーカイブされます）。対話型の doctor でもインポートをプレビューして確認できます。自動更新および Gateway 監視の修復実行では、状態ディレクトリをまたぐインポートは一切行われません。一時またはステージング用の状態ディレクトリが、デフォルトインストールの承認を取り込んではなりません。同じ境界が、従来の plugin-binding-approvals.json から共有 SQLite 状態へのインポートにも適用されます。
スキーマ例:
{ "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", "lastUsedAt": 1737150000000, "lastUsedCommand": "rg -n TODO", "lastResolvedPath": "/Users/user/Projects/.../bin/rg" } ] } }}ポリシー設定
tools.exec.mode
tools.exec.mode は、ホストでの Exec に推奨される正規化済みポリシー設定です。
| 値 | 動作 |
|---|---|
deny |
ホストでの Exec をブロックします。 |
allowlist |
確認せず、許可リストに登録されたコマンドのみを実行します。 |
ask |
許可リストポリシーを使用し、一致しない場合に確認します。 |
auto |
許可リストポリシーを使用し、決定的に一致するものは直接実行します。承認されていないものは OpenClaw のネイティブ自動レビュアーに送り、その後、人による承認経路へフォールバックします。 |
full |
承認確認なしでホスト上の Exec を実行します。 |
従来の tools.exec.security / tools.exec.ask も引き続きサポートされており、そのスコープで mode が未設定の場合に適用されます。
exec.security
security"deny" | "allowlist" | "full"deny- ホストでの Exec 要求をすべてブロックします。allowlist- 許可リストに登録されたコマンドのみを許可します。full- すべてを許可します（昇格と同等）。
Gateway / Node ホストのデフォルトは full です。sandbox ホストのデフォルトは代わりに deny です。
exec.ask
ask"off" | "on-miss" | "always"ホストでの Exec に設定された確認ポリシーです。tools.exec.ask とホスト承認のデフォルトによる、承認確認の基準動作を制御します。デフォルトは off です。呼び出し単位の ask ツールパラメーター（Exec ツールを参照）は、この基準を強化することしかできません。また、チャネル由来のモデル呼び出しでは、ホストの有効な確認設定が off の場合、このパラメーターは無視されます。
off- 確認を表示しません。on-miss- 許可リストに一致しない場合のみ確認します。always- すべてのコマンドで確認します。有効な確認モードがalwaysの場合、allow-alwaysによる永続的な信頼でも確認は抑制されません。
askFallback
askFallback"deny" | "allowlist" | "full"確認が必要であるにもかかわらず UI に到達できない場合（または確認がタイムアウトした場合）の解決方法です。省略時のデフォルトは deny です。
deny- ブロックします。allowlist- 許可リストに一致する場合のみ許可します。full- 許可します。
tools.exec.strictInlineEval
strictInlineEvalbooleantrue の場合、インタープリターのバイナリ自体が許可リストに登録されていても、インラインコード評価形式を承認必須として扱います。1つの安定したファイルオペランドに明確に対応付けられないインタープリターローダーに対する多層防御です。
厳格モードで検出される例: python -c、node -e/--eval/-p、ruby -e、perl -e/-E、php -r、lua -e、osascript -e（さらに awk、sed、make、find -exec、xargs のインライン形式）。
厳格モードでは、これらのコマンドにレビュアーまたは明示的な承認が必要です。tools.exec.mode: "auto" の場合、コマンドに適用可能な計画があれば、レビュアーは低リスクな実行を1回許可できます。それ以外の場合、OpenClaw は人に確認します。レビュアーへのフォールバックに到達した Codex app-server コマンドの承認では、承認要求に適用可能な解決済み実行可能ファイルが公開されないため、人に確認します。インライン評価コマンドでは、allow-always によって新しい許可リストエントリが永続化されることはありません。
tools.exec.commandHighlighting
commandHighlightingbooleandefault: false表示専用です。有効にすると、OpenClaw はパーサーから導出したコマンド範囲を付加し、Web の承認確認でコマンドトークンを強調表示できるようにします。security、ask、許可リストの照合、厳格なインライン評価の動作、承認の転送、コマンド実行は変更しません。
グローバルでは tools.exec.commandHighlighting、エージェント単位では agents.list[].tools.exec.commandHighlighting に設定します。
YOLO モード（承認なし）
承認確認なしでホスト上の Exec を実行するには、両方のポリシーレイヤーを開放します。つまり、OpenClaw 設定（tools.exec.*）で要求される Exec ポリシーと、実行ホストの承認ファイルにあるホストローカル承認ポリシーの両方です。
省略された askFallback のデフォルトは deny です。UI のない承認確認で許可へフォールバックする必要がある場合は、ホストの askFallback を明示的に full に設定してください。
| レイヤー | YOLO 設定 |
|---|---|
tools.exec.security |
gateway/node で full |
tools.exec.ask |
off |
ホストの askFallback |
full |
独自の非対話型権限モードを公開する CLI ベースのプロバイダーも、このポリシーに従えます。OpenClaw の有効な exec ポリシーが YOLO の場合、Claude CLI は --permission-mode bypassPermissions を追加します。OpenClaw が管理する Claude ライブセッションでは、Claude ネイティブの権限モードより OpenClaw の有効な exec ポリシーが優先されます。YOLO はライブ起動を --permission-mode bypassPermissions に正規化し、制限的な有効 exec ポリシーは、Claude バックエンドの生の引数で別のモードが指定されていても、ライブ起動を --permission-mode default に正規化します。
より保守的な設定にする場合は、OpenClaw の exec ポリシーを 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 と、ローカルの承認ファイルのデフォルト（askFallback: "full" を含む）の両方を更新します。意図的にローカル専用となっています。Gateway ホストまたは Node ホストの承認をリモートで変更するには、openclaw approvals set --gateway または openclaw approvals set --node <id|name|ip> を使用してください。
その他の組み込みプリセットには、cautious（host=gateway、security=allowlist、ask=on-miss、askFallback=deny）と deny-all（host=gateway、security=deny、ask=off、askFallback=deny）があります。同じ方法で適用します：openclaw exec-policy preset cautious。
完全なプリセットではなく個別のフィールドを設定するには、これらのフラグを任意に組み合わせて openclaw exec-policy set --host <auto|sandbox|gateway|node> --security <deny|allowlist|full> --ask <off|on-miss|always> --ask-fallback <deny|allowlist|full> を使用します。
Node ホスト
代わりに、同じ承認ファイルを Node に適用します。
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は、要求されたポリシーとホストの承認ファイルの両方がsecurity: "full"およびask: "off"に解決される場合に限り、exec 承認を省略する緊急時用ショートカットです。ask: "always"など、より厳格なホストファイルでは引き続き確認が表示されます。
ホストの承認ファイルが設定よりも厳格なままの場合は、より厳格なホストポリシーが引き続き優先されます。
許可リスト（エージェントごと）
許可リストはエージェントごとです。複数のエージェントが存在する場合は、macOS アプリで編集対象のエージェントを切り替えてください。パターンには glob マッチを使用します。
パターンには、解決済みバイナリパスの glob またはコマンド名だけの glob を指定できます。名前だけのパターンは PATH 経由で呼び出されたコマンドにのみ一致するため、コマンドが rg の場合、rg は /opt/homebrew/bin/rg に一致できますが、./rg や /tmp/rg には一致しません。特定の 1 か所にあるバイナリだけを信頼するには、パスの glob を使用してください。
従来の agents.default エントリは読み込み時に agents.main に移行されます。echo ok && pwd のようなシェルチェーンでも、最上位の各セグメントが許可リストのルールを満たす必要があります。
例：
rg~/Projects/**/bin/peekaboo~/.local/bin/*/opt/homebrew/bin/rg
argPattern による引数の制限
許可リストのエントリを、バイナリと特定の引数形式の両方に一致させる必要がある場合は、argPattern を追加します。OpenClaw はすべてのホストで ECMAScript（JavaScript）の正規表現セマンティクスを使用し、実行可能ファイルのトークン（argv[0]）を除いた、解析済みのコマンド引数に対して式を評価します。手動作成したエントリでは引数が単一の空白で結合されるため、完全一致が必要な場合はパターンをアンカーしてください。
{ "version": 1, "agents": { "main": { "allowlist": [ { "pattern": "python3", "argPattern": "^safe\\.py$" } ] } }}このエントリは python3 safe.py を許可しますが、python3 other.py は許可リストに一致しません。同じバイナリに対するパスのみのエントリも存在する場合、一致しなかった引数でも、そのパスのみのエントリにフォールバックできます。バイナリを宣言済みの引数に限定することが目的の場合は、パスのみのエントリを省略してください。
承認フローによって保存されるエントリでは、argv の完全一致に内部の区切り形式が使用されます。エンコードされた値を手動で編集するのではなく、UI または承認フローを使用してエントリを再生成することを推奨します。OpenClaw がコマンドセグメントの argv を解析できない場合、argPattern を含むエントリは一致しません。
各許可リストエントリは次のフィールドをサポートします。
| フィールド | 意味 |
|---|---|
pattern |
解決済みバイナリパスの glob またはコマンド名だけの glob |
argPattern |
任意の ECMAScript argv 正規表現。省略時はパスのみ |
id |
安定した不透明 ID。未指定の場合は UUID として生成 |
source |
allow-always などのエントリのソース |
commandText |
従来のプレーンテキスト入力。読み込み時に破棄 |
lastUsedAt |
最後に使用された時刻 |
lastUsedCommand |
最後に一致したコマンド |
lastResolvedPath |
最後に解決されたバイナリパス |
Skills の CLI の自動許可
Auto-allow skill CLIs（autoAllowSkills）が有効な場合、既知の Skills から参照される実行可能ファイルは、Node（macOS Node またはヘッドレス Node ホスト）上で許可リスト登録済みとして扱われます。これは Gateway RPC 経由の skills.bins を使用して Skills のバイナリ一覧を取得します。厳格な手動許可リストを使用する場合は、これを無効にしてください。
安全なバイナリと承認の転送
安全なバイナリ（標準入力専用の高速パス）、インタープリターのバインドに関する詳細、および承認確認を Slack/Discord/Telegram に転送する方法（またはネイティブ承認クライアントとして実行する方法）については、Exec 承認 - 高度な設定を参照してください。
Control UI での編集
デフォルト、エージェントごとのオーバーライド、および許可リストを編集するには、Control UI -> Nodes -> Exec approvals カードを使用します。スコープ（Defaults またはエージェント）を選択し、ポリシーを調整して許可リストのパターンを追加または削除した後、Save を選択します。UI にはパターンごとの最終使用メタデータが表示されるため、リストを整理された状態に保てます。
対象セレクターでは、Gateway（ローカル承認）または Node を選択します。Node は system.execApprovals.get/set を通知する必要があります（macOS アプリまたはヘッドレス Node ホスト）。Node がまだ exec 承認を通知していない場合は、そのローカル承認ファイルを直接編集してください。
Windows コンパニオンを含む一部の Node ホストでは、異なる承認ポリシー形式を所有しています。Control UI では、これらのホストネイティブなポリシーは読み取り専用で表示されます。編集するには、コンパニオンアプリまたはネイティブのポリシー形式を指定した openclaw approvals set --node <id|name|ip> を使用してください。承認 CLIも参照してください。
CLI：openclaw approvals は Gateway または Node の編集をサポートします。承認 CLIを参照してください。
承認フロー
確認が必要な場合、Gateway はオペレータークライアントに exec.approval.requested をブロードキャストします。Control UI と macOS アプリは exec.approval.resolve を介してこれを解決し、その後 Gateway が承認済みのリクエストを Node ホストに転送します。
host=node の場合、承認リクエストには正規化された systemRunPlan ペイロードが含まれます。承認済みの system.run リクエストを転送する際、Gateway はそのプランをコマンド、cwd、セッションのコンテキストに関する信頼できる情報源として使用します。
- Node の exec パスは、最初に 1 つの正規プランを準備します。
- 承認レコードは、そのプランとバインド用メタデータを保存します。
- 承認後、最終的に転送される
system.run呼び出しは、呼び出し元による後続の編集を信頼せず、保存済みのプランを再利用します。 - 承認リクエストの作成後に呼び出し元が
command、rawCommand、cwd、agentId、またはsessionKeyを変更すると、Gateway は承認の不一致として転送対象の実行を拒否します。
システムイベントと拒否
Node が完了を報告すると、exec のライフサイクルはエージェントのセッションに Exec finished システムメッセージを投稿します。また OpenClaw は、承認が許可されてから tools.exec.approvalRunningNoticeMs が経過した時点で、実行中の通知を送信できます（デフォルトは 10000、0 で無効化）。拒否された exec 承認は、そのホストコマンドに対する終端結果となり、コマンドは実行されません。
- 発生元のセッションがあるメインエージェントの非同期承認では、OpenClaw は拒否を内部フォローアップとしてそのセッションに投稿します。これにより、エージェントは非同期コマンドの待機を終了でき、結果欠落の修復を回避できます。
- セッションが存在しない場合やセッションを再開できない場合でも、OpenClaw は簡潔な拒否をオペレーターまたは直接チャットの経路に報告できます。
- サブエージェントおよび Cron セッションに対する拒否は、そのセッションには投稿されません。
Gateway ホストの exec 承認も、同じ完了ライフサイクルイベントを送出します。承認が必要な exec は承認 ID を再利用し、保留中のリクエストをその完了または拒否メッセージ（Exec finished (gateway id=...) / Exec denied (gateway id=...)）に関連付けます。
影響
fullは強力です。可能な場合は許可リストを推奨します。askは迅速な承認を可能にしつつ、ユーザーによる確認を維持します。- エージェントごとの許可リストにより、あるエージェントの承認が別のエージェントに漏れることを防ぎます。
- 承認は、認可済みの送信者からのホスト exec リクエストにのみ適用されます。認可されていない送信者は
/execを実行できません。 /exec security=fullは認可済みオペレーター向けのセッションレベルの利便機能であり、設計上、承認を省略します。ホスト exec を完全にブロックするには、承認のセキュリティをdenyに設定するか、ツールポリシーでexecツールを拒否してください。
