​

Exec 承認

​

適用箇所

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

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

• node host service は、system.run をローカル IPC 経由で 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。
• YOLO モードでは、OpenClaw は設定済みホスト exec ポリシーに加えて、別個のヒューリスティックなコマンド難読化承認ゲートやスクリプト事前拒否レイヤーを追加しません。
• 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 exec-policy preset yolo

• ローカルの tools.exec.host/security/ask
• ローカルの ~/.openclaw/exec-approvals.json デフォルト

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• openclaw exec-policy は node 承認を同期しません
• openclaw exec-policy set --host node は拒否されます
• node exec 承認は実行時に node から取得されるため、node 向け更新では openclaw approvals --node ... を使用する必要があります

• /exec security=full ask=off は現在のセッションだけを変更します。
• /elevated full は、そのセッションの exec 承認もスキップする break-glass ショートカットです。

​

ポリシーのノブ

​

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

​

Skills CLI の自動許可

• これは手動のパス許可リストエントリーとは別の、暗黙の利便性許可リストです。
• Gateway と node が同じ信頼境界にある、信頼されたオペレーター環境向けです。
• 厳密で明示的な信頼が必要な場合は、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 は、インタープリター/ランタイムのバイナリが明示的プロファイルなしで safeBins にある場合、tools.exec.safe_bins_interpreter_unprofiled で警告します。
• openclaw doctor --fix は、不足しているカスタム safeBinProfiles.<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つの具体的ローカルファイルを特定できない場合 （たとえばパッケージスクリプト、eval 形式、ランタイム固有のローダーチェーン、または曖昧な複数ファイル形式）、 意味上の保護範囲を持っているかのように主張する代わりに、承認付き実行は拒否されます。
• そのようなワークフローでは、サンドボックス化、別のホスト境界、またはオペレーターがより広いランタイム意味論を受け入れる 明示的な trusted allowlist/full ワークフローを優先してください。

​

フォローアップ配信動作

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

• command + args
• cwd
• agent id
• 解決済み実行ファイルパス
• host + ポリシーメタデータ

• 1回許可 → 今すぐ実行
• 常に許可 → 許可リストに追加して実行
• 拒否 → ブロック

​

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

​

Plugin 承認の転送

​

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

​

ネイティブ承認配信

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

• そのチャネルがネイティブ承認配信をサポートしている
• approver が、明示的な execApprovals.approvers またはその チャネルで文書化されたフォールバックソースから解決できる
• 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 ローカルフォールバックレイヤーなしで Plugin 承認を解決できます
• Matrix のネイティブ DM/チャネルルーティングとリアクションショートカットは、exec 承認と Plugin 承認の両方を処理します。 Plugin 認可は引き続き channels.matrix.dm.allowFrom から提供されます
• 要求元が approver である必要はありません
• 発生元チャットがすでにコマンドと返信をサポートしている場合、そのチャットから直接 /approve で承認できます
• ネイティブ Discord 承認ボタンは承認 ID 種別でルーティングします: plugin: ID は 直接 Plugin 承認へ進み、それ以外はすべて exec 承認へ進みます
• ネイティブ Telegram 承認ボタンは、/approve と同じ制限付き exec-to-plugin フォールバックに従います
• ネイティブ target が発生元チャット配信を有効にすると、承認プロンプトにはコマンドテキストが含まれます
• 保留中の exec 承認はデフォルトで 30 分後に期限切れになります
• オペレーター UI または設定済み承認クライアントが要求を受け付けられない場合、プロンプトは askFallback にフォールバックします

• Discord
• Telegram

​

macOS IPC フロー

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

​

システムイベント

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

​

拒否された承認の動作

​

含意

• full は強力です。可能なら許可リストを優先してください。
• ask を使うと、迅速な承認を可能にしつつ、引き続き状況を把握できます。
• エージェントごとの許可リストにより、あるエージェントの承認が他に漏れません。
• 承認は、認可済み送信元からのホスト exec 要求にのみ適用されます。未認可送信元は /exec を発行できません。
• /exec security=full は、認可済みオペレーター向けのセッションレベルの利便機能であり、設計上承認をスキップします。 ホスト exec を強制的にブロックするには、承認 security を deny に設定するか、ツールポリシーで exec ツールを拒否してください。

• Exec tool
• Elevated mode
• Skills

​

関連

• Exec — シェルコマンド実行ツール
• Sandboxing — サンドボックスモードとワークスペースアクセス
• Security — セキュリティモデルとハードニング
• Sandbox vs Tool Policy vs Elevated — それぞれを使い分ける場面