実行承認 — 高度

高度な exec 承認トピック: safeBins 高速パス、インタープリター/ランタイムのバインド、およびチャットチャネルへの承認転送（ネイティブ配信を含む）。中核ポリシーと承認フローについては、Exec 承認を参照してください。

# Safe bins（stdin のみ）

tools.exec.safeBins は、明示的な許可リスト項目なしで許可リストモードで実行できる、少数の stdin のみのバイナリ（例: cut）を定義します。Safe bins は位置指定のファイル引数とパス風のトークンを拒否するため、入力ストリームに対してのみ動作できます。これは汎用的な信頼リストではなく、ストリームフィルター向けの限定的な高速パスとして扱ってください。

既定の safe bins:

cut, uniq, head, tail, tr, wc

grep と sort は既定のリストに含まれていません。オプトインする場合は、stdin 以外のワークフローについて明示的な許可リスト項目を維持してください。safe-bin モードの grep では、-e/--regexp でパターンを指定してください。位置指定のパターン形式は拒否されるため、ファイルオペランドを曖昧な位置引数として紛れ込ませることはできません。

# Argv 検証と拒否されるフラグ

検証は argv の形状のみから決定的に行われます（ホストファイルシステムの存在チェックは行いません）。これにより、許可/拒否の差異がファイル存在のオラクルとして機能することを防ぎます。既定の safe bins では、ファイル指向のオプションは拒否されます。ロングオプションはフェイルクローズで検証されます（未知のフラグや曖昧な省略形は拒否されます）。

safe-bin プロファイル別の拒否フラグ:

• 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 は、stdin のみのセグメントについて、実行時に argv トークンをリテラルテキストとして扱うことも強制します（グロブ展開も $VARS 展開もありません）。そのため、* や $HOME/... のようなパターンを使ってファイル読み取りを紛れ込ませることはできません。

# 信頼されたバイナリディレクトリ

Safe bins は信頼されたバイナリディレクトリ（システム既定値に加えて任意の tools.exec.safeBinTrustedDirs）から解決される必要があります。PATH 項目が自動的に信頼されることはありません。既定の信頼済みディレクトリは意図的に最小限です: /bin、/usr/bin。safe-bin 実行ファイルがパッケージマネージャー/ユーザーパス（例: /opt/homebrew/bin、/usr/local/bin、/opt/local/bin、/snap/bin）にある場合は、tools.exec.safeBinTrustedDirs に明示的に追加してください。

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

シェル連結（&&、||、;）は、すべてのトップレベルセグメントが許可リスト（safe bins または Skills 自動許可を含む）を満たす場合に許可されます。リダイレクトは許可リストモードでは引き続きサポートされません。コマンド置換（$() / バッククォート）は、二重引用符内を含め、許可リスト解析中に拒否されます。リテラルの $() テキストが必要な場合は単一引用符を使用してください。

macOS コンパニオンアプリの承認では、シェル制御または展開構文（&&、||、;、|、`、$、<、>、(、)）を含む生のシェルテキストは、シェルバイナリ自体が許可リストに登録されていない限り、許可リスト不一致として扱われます。

シェルラッパー（bash|sh|zsh ... -c/-lc）では、リクエストスコープの env オーバーライドは小さな明示的な許可リスト（TERM、LANG、LC_*、COLORTERM、NO_COLOR、FORCE_COLOR）に削減されます。

許可リストモードでの allow-always 決定では、既知のディスパッチラッパー（env、nice、nohup、stdbuf、timeout）はラッパーパスではなく内部の実行ファイルパスを永続化します。シェルマルチプレクサー（busybox、toybox）も、シェルアプレット（sh、ash など）について同じ方法でアンラップされます。ラッパーまたはマルチプレクサーを安全にアンラップできない場合、許可リスト項目は自動的には永続化されません。

python3 や node のようなインタープリターを許可リストに登録する場合は、tools.exec.strictInlineEval=true を優先してください。これにより、インライン評価では引き続き明示的な承認が必要になります。strict モードでは、allow-always は無害なインタープリター/スクリプト呼び出しを引き続き永続化できますが、インライン評価キャリアは自動的には永続化されません。

# Safe bins と許可リストの比較

トピック	tools.exec.safeBins	許可リスト（exec-approvals.json）
目的	限定的な stdin フィルターを自動許可	特定の実行ファイルを明示的に信頼
一致タイプ	実行ファイル名 + safe-bin argv ポリシー	解決済み実行ファイルパスの glob、または PATH 経由で呼び出されたコマンド向けの裸のコマンド名 glob
引数スコープ	safe-bin プロファイルとリテラルトークン規則で制限	既定ではパス一致。任意の argPattern で解析済み argv を制限可能
典型例	head, tail, tr, wc	jq, python3, node, ffmpeg, カスタム CLI
最適な用途	パイプライン内の低リスクなテキスト変換	より広範な動作または副作用を持つ任意のツール

設定場所:

• 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 は自動足場生成されません。

カスタムプロファイルの例: OC_I18N_900000 jq を safeBins に明示的にオプトインしても、OpenClaw は safe-bin モードで env ビルトインを拒否するため、jq -n env が明示的な許可リストパスまたは承認プロンプトなしでホストプロセス環境をダンプすることはできません。

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

承認に基づくインタープリター/ランタイムの実行は、意図的に保守的です。

• 正確な argv/cwd/env コンテキストが常にバインドされます。
• 直接のシェルスクリプト形式と直接のランタイムファイル形式は、ベストエフォートで 1 つの具体的なローカルファイルスナップショットにバインドされます。
• それでも 1 つの直接的なローカルファイルに解決される一般的なパッケージマネージャーラッパー形式（例: pnpm exec、pnpm node、npm exec、npx）は、バインド前にアンラップされます。
• OpenClaw がインタープリター/ランタイムコマンドについて、具体的なローカルファイルを正確に 1 つ識別できない場合（例: パッケージスクリプト、eval 形式、ランタイム固有のローダーチェーン、曖昧な複数ファイル形式）、実際には持たない意味的カバレッジを主張する代わりに、承認に基づく実行は拒否されます。
• これらのワークフローでは、サンドボックス化、別のホスト境界、またはオペレーターがより広範なランタイムセマンティクスを受け入れる明示的に信頼された許可リスト/完全なワークフローを優先してください。

承認が必要な場合、exec ツールは承認 ID とともに即座に返ります。その ID を使って、後続のシステムイベント（Exec finished / Exec denied）を関連付けてください。タイムアウト前に決定が届かない場合、そのリクエストは承認タイムアウトとして扱われ、拒否理由として表示されます。

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

承認された非同期 exec が完了すると、OpenClaw は同じセッションにフォローアップの agent ターンを送信します。

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

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

exec 承認プロンプトは、任意のチャットチャネル（Plugin チャネルを含む）に転送し、/approve で承認できます。これは通常のアウトバウンド配信パイプラインを使用します。

設定: OC_I18N_900001 チャットで返信: OC_I18N_900002 /approve コマンドは exec 承認と Plugin 承認の両方を処理します。ID が保留中の exec 承認に一致しない場合、自動的に代わりに Plugin 承認を確認します。

# Plugin 承認の転送

Plugin 承認の転送は exec 承認と同じ配信パイプラインを使用しますが、approvals.plugin 配下に独立した専用設定があります。一方を有効または無効にしても、もう一方には影響しません。 OC_I18N_900003 設定の形状は approvals.exec と同一です: enabled、mode、agentFilter、sessionFilter、targets は同じように機能します。

共有インタラクティブ返信をサポートするチャネルは、exec と Plugin の両方の承認について同じ承認ボタンをレンダリングします。共有インタラクティブ UI のないチャネルでは、/approve 手順を含むプレーンテキストにフォールバックします。 Plugin 承認リクエストは、利用可能な決定を制限する場合があります。承認サーフェスはリクエストで宣言された決定セットを使用し、Gateway は提示されなかった決定の送信試行を拒否します。

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

exec または Plugin の承認リクエストが配信可能なチャットサーフェスから発生した場合、同じチャットで既定により /approve を使って承認できるようになりました。これは既存の Web UI とターミナル UI のフローに加えて、Slack、Matrix、Microsoft Teams などのチャネルにも適用されます。

この共有テキストコマンドパスは、その会話の通常のチャネル認証モデルを使用します。発生元のチャットがすでにコマンドを送信し返信を受信できる場合、承認リクエストを保留状態に保つためだけに別個のネイティブ配信アダプターは不要になりました。

Discord と Telegram も同一チャットの /approve をサポートしますが、これらのチャネルではネイティブ承認配信が無効な場合でも、認可には引き続き解決済みの承認者リストを使用します。

Telegram および Gateway を直接呼び出すその他のネイティブ承認クライアントでは、このフォールバックは意図的に「承認が見つからない」失敗に限定されています。実際の exec 承認の拒否/エラーが、Plugin 承認として暗黙に再試行されることはありません。

# ネイティブ承認配信

一部のチャネルは、ネイティブ承認クライアントとしても動作できます。ネイティブクライアントは、共有の同一チャット /approve フローの上に、承認者へのDM、元チャットへのファンアウト、チャネル固有のインタラクティブな承認UXを追加します。

ネイティブ承認カード/ボタンが利用可能な場合、そのネイティブUIが主な エージェント向け経路です。ツール結果でチャット承認が利用できない、または 手動承認が唯一残された経路であると示されていない限り、エージェントは重複するプレーンチャットの /approve コマンドを追加でエコーすべきではありません。

ネイティブ承認クライアントが設定されているものの、発信元チャネルでネイティブランタイムが有効でない場合、 OpenClaw はローカルの決定的な /approve プロンプトを表示したままにします。ネイティブランタイムが有効で配信を試みたものの、 どのターゲットもカードを受信しない場合、OpenClaw は同一チャットのフォールバック通知で 正確な /approve <id> <decision> コマンドを送信し、リクエストを引き続き解決できるようにします。

汎用モデル:

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

ネイティブ承認クライアントは、次のすべてがtrueの場合にDM優先配信を自動的に有効化します:

• チャネルがネイティブ承認配信をサポートしている
• 承認者を明示的な execApprovals.approvers または commands.ownerAllowFrom などの所有者IDから解決できる
• channels.<channel>.execApprovals.enabled が未設定、または "auto" である

ネイティブ承認クライアントを明示的に無効化するには enabled: false を設定します。承認者を解決できる場合に強制的に 有効化するには enabled: true を設定します。公開の元チャット配信は channels.<channel>.execApprovals.target を通じて明示的なままです。

FAQ: チャット承認にexec承認設定が2つあるのはなぜですか？

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

これらのネイティブ承認クライアントは、共有の同一チャット /approve フローと共有承認ボタンの上に、 DMルーティングと任意のチャネルファンアウトを追加します。

共有動作:

• Slack、Matrix、Microsoft Teams、および類似の配信可能なチャットは、同一チャットの /approve に通常のチャネル認証モデルを使用する
• ネイティブ承認クライアントが自動有効化されると、デフォルトのネイティブ配信ターゲットは承認者DMになる
• Discord と Telegram では、解決済みの承認者だけが承認または拒否できる
• Discord 承認者は明示的に指定する（execApprovals.approvers）か、commands.ownerAllowFrom から推論できる
• Telegram 承認者は明示的に指定する（execApprovals.approvers）か、commands.ownerAllowFrom から推論できる
• Slack 承認者は明示的に指定する（execApprovals.approvers）か、commands.ownerAllowFrom から推論できる
• Slack のネイティブボタンは承認IDの種類を保持するため、plugin: ID は2つ目のSlackローカルのフォールバック層なしでPlugin承認を解決できる
• Matrix のネイティブDM/チャネルルーティングとリアクションショートカットはexec承認とPlugin承認の両方を処理する。 Plugin認可は引き続き channels.matrix.dm.allowFrom から取得される
• Matrix のネイティブプロンプトは最初のプロンプトイベントに com.openclaw.approval カスタムイベントコンテンツを含めるため、 OpenClaw対応のMatrixクライアントは構造化された承認状態を読み取ることができ、標準クライアントは プレーンテキストの /approve フォールバックを維持する
• リクエスト元が承認者である必要はない
• 発信元チャットがすでにコマンドと返信をサポートしている場合、そのチャットは /approve で直接承認できる
• ネイティブDiscord承認ボタンは承認IDの種類でルーティングする: plugin: ID は 直接Plugin承認へ進み、それ以外はexec承認へ進む
• ネイティブTelegram承認ボタンは /approve と同じ、境界付けられたexecからPluginへのフォールバックに従う
• ネイティブの target が元チャット配信を有効にしている場合、承認プロンプトにはコマンドテキストが含まれる
• 保留中のexec承認はデフォルトで30分後に期限切れになる
• リクエストを受け付けられるオペレーターUIまたは設定済み承認クライアントがない場合、プロンプトは askFallback にフォールバックする

/diagnostics や /export-trajectory などの機密性の高い所有者専用グループコマンドは、承認プロンプトと最終結果にプライベートな 所有者ルーティングを使用します。OpenClaw はまず、所有者がコマンドを実行した同じサーフェス上のプライベート経路を試行します。 そのサーフェスにプライベート所有者経路がない場合、commands.ownerAllowFrom から利用可能な最初の所有者経路に フォールバックするため、Telegram が設定済みのプライマリプライベートインターフェイスである場合でも、Discord グループコマンドは 承認と結果を所有者のTelegram DMへ送信できます。グループチャットには短い確認応答だけが送られます。

Telegram はデフォルトで承認者DM（target: "dm"）を使用します。承認プロンプトを発信元のTelegramチャット/トピックにも表示したい場合は、 channel または both に切り替えられます。Telegramフォーラムトピックでは、OpenClaw は承認プロンプトと承認後のフォローアップのためにトピックを保持します。

参照:

• Discord
• Telegram

# macOS IPCフロー

OC_I18N_900004 セキュリティメモ:

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

# 関連

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