---
read_when:
    - 安全な実行ファイルまたはカスタム安全実行ファイルプロファイルの設定
    - 承認を Slack/Discord/Telegram または他のチャットチャネルに転送する
    - チャネル向けネイティブ承認クライアントの実装
summary: '高度な exec 承認: 安全な bin、インタープリターのバインディング、承認の転送、ネイティブ配信'
title: 実行承認 — 高度な設定
x-i18n:
    generated_at: "2026-04-30T05:37:24Z"
    model: gpt-5.5
    provider: openai
    source_hash: de8a72ca1d23e55dc198ae3c5ad55a57660c2111feebfb89f08d8fa9584e4337
    source_path: tools/exec-approvals-advanced.md
    workflow: 16
---

exec 承認の高度なトピック: `safeBins` 高速パス、インタープリター/ランタイムの
バインディング、チャットチャンネルへの承認転送（ネイティブ配信を含む）。
中核ポリシーと承認フローについては、[exec 承認](/ja-JP/tools/exec-approvals)を参照してください。

## 安全な bin（stdin のみ）

`tools.exec.safeBins` は、明示的な許可リスト
エントリ**なしで**許可リストモードで実行できる、**stdin のみ**のバイナリ（たとえば
`cut`）の小さなリストを定義します。安全な bin は位置指定のファイル引数とパス風のトークンを拒否するため、
入力ストリームに対してのみ動作できます。これはストリームフィルター向けの狭い高速パスとして扱い、
一般的な信頼リストとして扱わないでください。

<Warning>
インタープリターやランタイムのバイナリ（たとえば `python3`、`node`、
`ruby`、`bash`、`sh`、`zsh`）を `safeBins` に追加**しないでください**。コマンドがコードを評価したり、
サブコマンドを実行したり、設計上ファイルを読み取ったりできる場合は、明示的な許可リストエントリを優先し、
承認プロンプトを有効のままにしてください。カスタムの安全な bin は、`tools.exec.safeBinProfiles.<bin>` に明示的な
プロファイルを定義する必要があります。
</Warning>

デフォルトの安全な bin:

[//]: # "SAFE_BIN_DEFAULTS:START"

`cut`, `uniq`, `head`, `tail`, `tr`, `wc`

[//]: # "SAFE_BIN_DEFAULTS:END"

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

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

検証は argv の形状だけから決定的に行われます（ホストファイルシステムでの存在確認は行いません）。
これにより、許可/拒否の差分からファイル存在のオラクル挙動が生じるのを防ぎます。デフォルトの安全な bin では、
ファイル指向のオプションは拒否されます。ロングオプションは fail-closed で検証されます（未知のフラグと曖昧な省略形は
拒否されます）。

安全な bin プロファイルごとに拒否されるフラグ:

[//]: # "SAFE_BIN_DENIED_FLAGS:START"

- `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_BIN_DENIED_FLAGS:END"

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

### 信頼済みバイナリディレクトリ

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

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

シェルチェーン（`&&`、`||`、`;`）は、すべてのトップレベルセグメントが
許可リスト（安全な bin または 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` を推奨します。これにより、インライン eval には引き続き明示的な
承認が必要になります。strict モードでは、`allow-always` は無害な
インタープリター/スクリプト呼び出しを永続化できますが、インライン eval のキャリアは自動的には永続化されません。

### 安全な bin と許可リスト

| トピック         | `tools.exec.safeBins`                                  | 許可リスト（`exec-approvals.json`）                                                |
| ---------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| 目的             | 狭い stdin フィルターを自動許可                        | 特定の実行ファイルを明示的に信頼                                                  |
| マッチ種別       | 実行ファイル名 + 安全な bin の argv ポリシー           | 解決済み実行ファイルパスの glob、または PATH 経由で起動されたコマンドの素のコマンド名 glob |
| 引数スコープ     | 安全な bin プロファイルとリテラルトークン規則で制限   | パス一致のみ。引数についてはそれ以外は自分の責任                                  |
| 典型例           | `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>` エントリを `{}` として scaffold できます（その後、確認して締めてください）。インタープリター/ランタイムの bin は自動 scaffold されません。

カスタムプロファイルの例:
__OC_I18N_900000__
`jq` を `safeBins` に明示的にオプトインしても、OpenClaw は安全な 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`）を関連付けます。タイムアウト前に判断が到着しない場合、
リクエストは承認タイムアウトとして扱われ、拒否理由として表示されます。

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

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

- 有効な外部配信ターゲットが存在する場合（配信可能なチャンネルに加えてターゲット `to`）、フォローアップ配信はそのチャンネルを使用します。
- webchat のみ、または外部ターゲットのない内部セッションフローでは、フォローアップ配信はセッション内のみ（`deliver: false`）に留まります。
- 呼び出し元が解決可能な外部チャンネルなしで strict 外部配信を明示的に要求した場合、リクエストは `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`
手順付きのプレーンテキストにフォールバックします。

### 任意のチャンネルでの同じチャット内承認

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` は、そのチャネルがネイティブ承認クライアントとして動作するかどうかを制御します

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

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

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

FAQ: [チャット承認にはなぜ 2 つの exec 承認設定があるのですか?](/help/faq-first-run#why-are-there-two-exec-approval-configs-for-chat-approvals)

- 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` から最初に利用可能な所有者ルートへフォールバックするため、Discord グループコマンドでも、
Telegram が設定済みの主要プライベートインターフェイスである場合は、承認と結果を所有者の Telegram DM に送信できます。
グループチャットには短い確認応答のみが届きます。

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

参照:

- [Discord](/channels/discord)
- [Telegram](/channels/telegram)

### macOS IPC フロー
__OC_I18N_900004__
セキュリティメモ:

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

## 関連

- [Exec 承認](/ja-JP/tools/exec-approvals) — コアポリシーと承認フロー
- [Exec ツール](/ja-JP/tools/exec)
- [昇格モード](/ja-JP/tools/elevated)
- [Skills](/ja-JP/tools/skills) — skill による自動許可動作
