OpenClawのexec承認・上級編

exec承認の基本ページでは、ポリシーとプロンプトを説明しています。注意すべき細かな点が集まっているのは上級編のページです。stdinしか読めないという理由で許可リストを省略できるバイナリはどれか、gatewayがインタープリターのコマンドを実際に実行するファイルにどうバインドするのか、ダッシュボードが何かを承認するにはどのスコープが必要か、そしてプロンプトがどのようにチャットチャネルに届き、判断として戻ってくるのか。ここではそのページを凝縮して紹介します。

safe bins

• safe binsの設定には、allowlistモードで明示的なエントリーなしに実行できるstdin専用のバイナリを指定します。デフォルトはcut、uniq、head、tail、tr、wcです。これらは位置引数としてのファイルやパスのようなトークンを拒否し、引数をグロブや変数展開なしのリテラルテキストとして扱います。検証は引数の形だけから決定論的に行われ、未知のロングフラグやあいまいな省略形はフェイルクローズで拒否され、認識されないショートフラグは承認ポリシーに委ねられます。
• grepとsortはデフォルトのsafe binsではなく、stdin以外を使うワークフロー用には明示的な許可リストのエントリーを維持します。safe binモードのgrepは、パターンを明示的なパターンフラグ経由でしか受け取りません。awk、sed、jqは、その動作がstdin専用であると検証できないため、safe binsとしては常に拒否されます。インタープリターやランタイムは決して追加してはならず、カスタムのsafe binsには明示的なプロファイルが必要です。監査はプロファイルのないインタープリターのバイナリについて警告し、doctorの修正機能は、あとから絞り込むための空のカスタムプロファイルの雛形を作成できます。
• safe binsは信頼済みディレクトリ、つまりデフォルトの2つのシステムパスから解決される必要があり、検索パスのエントリーが自動的に信頼されることはありません。そのため、パッケージマネージャーのパスは信頼済みディレクトリのリストに明示的に追加します。プロファイルごとの拒否フラグのリストは、ファイルを読み取るオプションをブロックします。たとえば、grepの再帰フラグとファイルフラグ、sortの出力オプションとファイルリストオプション、tailのフォロー、wcのファイルリストオプションです。
• シェルの連結は、トップレベルのすべてのセグメントが許可リストを満たす場合に許可されます。リダイレクトは引き続きサポートされず、コマンド置換はダブルクォートの内側でも拒否されます。シェルラッパーはリクエストによる環境変数の上書きを少数のリストに絞り込み、allow-alwaysの判断は透過的なラッパーの奥にある内側の実行ファイルを保存し、シェルのマルチプレクサーのアプレットをアンラップします。また厳格なインライン評価の設定により、インタープリターが許可リストに入っている場合でも、インラインのevalはレビューを経るようになります。

セッションへの配信が制御するのは、プロンプトが表示される場所だけです。それだけで、そのチャットの参加者全員に承認の権限が与えられるわけではありません。

インタープリターのバインドとapprovalsスコープ

承認に基づくインタープリターの実行は、意図的に慎重に設計されています。正確な引数、作業ディレクトリ、環境がバインドされます。gateway上では、外部ディスパッチチェーン全体（各ラッパーの実行ファイルと最後の実行ファイル）がレビュー前にバインドされ、起動前に再チェックされます。保護された実行ファイルは実パスで、書き込み可能な実行ファイルはさらにコンテンツハッシュでもバインドされるため、検索パスのより前方に新しい実行ファイルが現れると、実行は拒否されます。直接実行するスクリプトやランタイムのファイルは1つのファイルスナップショットにバインドされ、一般的なパッケージマネージャーのラッパーは最初にアンラップされます。パッケージスクリプト、evalの形式、ローダーチェーンのように、gatewayがローカルファイルを1つに特定できない場合、承認に基づく実行は、カバーしているふりをするのではなく拒否されます。自動モードでは、レビュアーが扱うのは完全にバインドされたチェーンだけです。シェルコマンドのラッパー、環境変数の代入、アプレット、組み込みのディスパッチは自動レビューを飛ばして、一度限りの人間による承認の経路をたどります。ログインシェルや対話型シェルのラッパーは、起動ファイルがバインドの範囲外にあるため人間の判断が必要で、コードを読み込む対話型のオプションは引き続き拒否されます。承認が必要な場合、ツールはただちに承認IDを返します。判断が届かないままの場合はタイムアウトとなり、ホストコマンドの拒否として表面化したうえで元のセッションが再開されるため、エージェントはコマンドが実行されなかったことを把握できます。保留中の承認は30分で期限切れになります。承認を解決するには専用のapprovalsスコープが必要で、writeスコープはこれを含みません。ドキュメントはこれを、リモート実行に相当する権限であり、小さな承認用インターフェースに対してであっても慎重に付与すべきものだとしています。

チャットへの転送

• exec承認の転送ブロックは、通常の送信パイプラインを通じて任意のチャットチャネルにプロンプトを送ります。モードはsession、targets、bothのいずれかで、エージェントとセッションのフィルター、チャネルと受信者を組み合わせたターゲットを指定できます。エージェントがapproveコマンドを中継するのは、実際に保留中の承認から、その正確なIDを使う場合だけです。単独で書かれたIDや捏造されたIDでは何も承認されません。allow-onceの許可は1つのコマンドにのみ有効です。また、IDが保留中のexec承認のものでない場合は、同じコマンドでプラグインの承認も解決でき、プラグインの系統は独立して設定します。
• Slack、Matrix、Teamsなど配信可能な同様のサーフェスでは、デフォルトで元のチャットから承認できますが、Discord、Telegram、QQボットでは、同じチャット内であっても解決済みの承認者リストが使われます。ネイティブ承認クライアントは、承認者へのダイレクトメッセージ、元のチャットへのファンアウト、インタラクティブなカードを追加します。これらは解決可能な承認者がいるチャネルごとに有効化され、Telegramではデフォルトで自動かつ承認者へのメッセージになります。どのターゲットにも届かなかったカードは、正確なコマンドを添えた同じチャット内の通知にフォールバックします。
• ターゲットには、特定のボットアカウントから送信するためのアカウントIDと、フォーラムのトピック内にとどまるためのスレッドIDを持たせられます。公式モバイルアプリは、管理者接続の場合、または承認用デバイスとしてターゲットに指定された場合に保留中の承認を確認し、確認応答が失われたときはレコードを読み直します。macOSの経路は、トークン、チャレンジ、短い有効期間を伴う同一ユーザーのソケット上で動作します。

このページが拡張する基本のポリシーについてはOpenClawのexec承認の記事を、バインドでカバーできないワークフローについてドキュメントが推奨する境界についてはOpenClawのサンドボックスの解説をご覧ください。

高速パスが狭い理由

safe binの設計全体は、ひとつの性質の上に成り立っています。stdinしか読めないバイナリは、ポリシーが公開するつもりのなかったファイルを持ち出せない、という性質です。すべてのルールはここから導かれます。位置引数としてのパスの拒否、リテラルとしての引数、拒否されるファイルフラグ、インタープリターとjqの禁止、そして検索パスのより前方にある偽物のバイナリを止める信頼済みディレクトリです。ツールがファイルを開いたりコードを評価したりできるようになった時点で、ドキュメントはそれを、プロンプト付きの許可リストのほうへ回します。転送されたプロンプトが届く先となるDialiのチャネルの例として、DialiでのTelegramとDialiでのSlackがあります。

Dialiでは

Dialiでは、ランタイム設定はダッシュボードから生成されてリリースのたびに置き換えられ、お客様ごとのランタイムがそれぞれ独立した境界になります。ホスティングされたアシスタントについてはDialiのマネージドOpenClawホスティングのページを、アシスタントが実行するすべてのコマンドを取り巻く管理策についてはDialiのセキュリティのページをご覧ください。

• safe binsが読むのはstdinだけ。インタープリターは決して対象になりません。
• インタープリターの実行は、チェーン全体をバインドするか、拒否されるかのどちらかです。
• 承認に必要なのはwriteではなく、approvalsスコープです。