2026年 OpenClaw Exec Approvals を独占リモート Mac（SSH ヘッドレス）で運用する：tools.exec・承認状態・無 UI フォールバックの意思決定マトリクス＋FAQ
Exec Approvals（実行前の人間確認）と tools.exec を、独占リモート Mac の SSH ヘッドレス前提で矛盾なく回すための方針、承認キューの状態ファイル、GUI が無いときの保守的フォールバックを runbook 粒度でまとめます。
前提の立て方や launchd の健康診断は、 2026年最新 OpenClaw デプロイ・安定運用マニュアル と併読すると再現性が上がります。
1. 背景：ヘッドレス SSH だからこそ「承認」を設計資産にする
独占リモート Mac では、エージェントが tools.exec でシェルコマンドやスクリプトを起動できます。画面が無いと「ポップアップで承認」が使えない一方、監査要件では「誰がいつ何を許可したか」を残す必要があります。Exec Approvals は、そのギャップを 状態機械＋永続キュー で埋めるためのレイヤです。
本稿のスコープは次の三点です。(1) tools.exec の許可モデルと承認ポリシーの対応、(2) 承認待ち・却下・期限切れを表す状態ファイルの置き場所と単一ライター規律、(3) UI が無いときの「拒否優先」フォールバックと運用者が SSH だけで完結する手順。
2. Exec Approvals と tools.exec の関係
概念的には、モデルがツール呼び出しを要求するとき、tools.exec は「実行系ツール」の入口です。Exec Approvals がオンなら、危険度の高いコマンドやポリシー外の引数は 保留（pending） に入り、承認者が明示的に 許可（approved） するまでプロセス起動やファイル破壊的オペレーションを起こしません。
2.1 推奨ポリシー（実務向け）
- 本番・共有テナント：デフォルト deny、ホワイトリストされた読み取り専用コマンドのみ auto。それ以外は必ず pending。
- 検証・個人専用：開発者本人のみ SSH できるなら auto を広げてもよいが、同一ホストに複数ボット／複数セッションがある場合は pending を維持。
- 秘密情報：承認 UI が無い環境では、承認操作そのものを別チャネル（社内チャットの slash コマンド、署名付き webhook）に逃がし、Mac 上は状態ファイルの更新だけに限定する。
資格情報と監査ログの扱いは OpenClaw 安全運用（SecretRef／Lobster） のパターンと整合させると、承認ログと秘密の境界が崩れにくくなります。
3. 承認状態ファイル：単一ライターとアトミック更新
ヘッドレス運用では、承認キューは JSONL または SQLite 等の単一ストア に集約し、OpenClaw プロセス（または専用 sidecar）だけが書き込むようにします。複数プロセスが同時に書くと、pending が二重実行されたり、承認が失われたりします。
3.1 最低限のフィールド例
各リクエストに request_id、tool、argv ハッシュ、cwd、submitter（セッション ID や inbound チャネル）、status（pending／approved／rejected／expired）、ttl、監査用タイムスタンプを載せます。macOS では rename(2) による同ディレクトリ内の置換でアトミックにコミットするか、SQLite のトランザクションを使います。
3.2 SSH 運用者向けチェック
- キューファイルのパスを
OPENCLAW_STATE_DIR（仮）など環境変数で固定し、launchd のEnvironmentVariablesと揃える。 - 手編集が必要なら、エージェントを止めてから行うか、専用 CLI（
openclaw approvals approve <id>等）だけを許可する。 - バックアップは「コピーではなくスナップショット＋整合性検証」：承認済み ID と実際の exec ログを突合する。
4. 意思決定マトリクス（再現用）
次の表は、チームレビューに貼れる「条件 → 推奨設定」の一覧です。セルは運用ポリシー名としてそのまま議事録に転記できます。
| 条件 | tools.exec 既定 | Exec Approvals | 無 UI 時のフォールバック |
|---|---|---|---|
| 本番・複数人が SSH 可能 | strict（読み取りのみ auto） | 必須・TTL 短め | 外部承認 webhook → 状態ファイル更新 |
| 個人専用・単一 SSH 鍵 | moderate | 破壊的操作のみ pending | CLI 承認＋監査ログ tail |
| CI 連携ボット（Inbound のみ） | allowlist コマンドのみ | ジョブ単位で batch approve | 失敗時は reject＋アラート、再実行は新 request_id |
| オフライン／ゲートウェイ不安定 | deny へ自動降格 | キューを凍結 | 既存 pending は expired へ（手動再発行） |
5. 無 UI（ヘッドレス）の保守的フォールバック
GUI が無いときの鉄則は 「迷ったら実行しない」 です。具体的には、(1) 承認チャネルが応答しない間は pending のままタイムアウトし、モデルには「ブロックされた」旨を返す。(2) 設定不整合（状態ファイルが壊れている／バージョン不一致）は起動時にフェイルクローズ。(3) 緊急時だけ限定的に「break-glass」用のロールを別ファイルで定義し、使用後は必ずローテーションと事後監査。
SSH からの運用では、launchctl print でゲートウェイが生きているか、log show --predicate で exec 監査イベントが流れているかを週次で確認すると、承認レイヤの沈黙障害に早く気づけます。
6. FAQ
Q1. pending が溜まり続けてセッションが詰まる
TTL を設定し、期限切れは expired としてクローズ。モデル側には短いエラーテンプレを返し、ユーザーに「範囲を狭くして再依頼」を促します。同時実行数も tools.exec 側で上限を掛けます。
Q2. 承認と実際のコマンドが食い違う（TOCTOU）
承認対象は argv の正規化済みハッシュ とワーキングディレクトリまで含めます。承認後に引数が変わったら新しい request_id が必要、という規律をコード側で強制します。
Q3. 複数 OpenClaw インスタンスを同一 Mac で動かしたい
状態ファイルのパスをインスタンスごとに分離し、同じキューを参照しないようにします。共有が必要なら、キュー専用の単一プロセス（Redis ではなく「単一ライター」サービス）を挟むのが安全です。
7. なぜこの運用は Mac mini／macOS で噛み合いやすいか
承認キューと exec ログを同一ノードに置く構成では、ディスクの整合性・ファイルロック・タイムスタンプの挙動が安定していることが重要です。macOS は Unix ツールチェーンと launchd が素直に揃い、Apple Silicon の Mac mini は待機電力が非常に低く、ヘッドレスの OpenClaw を昼夜問わず回しても電気コストと騒音の負担が小さいです。Gatekeeper や SIP とも相性がよく、「承認されたコマンドだけが実ファイルに触れる」 という境界を運用で守りやすいのも利点です。
開発者にとっては、SSH と Homebrew、コンテナ類が前提通りに動き、承認用の小さな CLI や webhook 受け口をローカルに載せ替えるだけでスタックを完成させられます。リモート専用機として長期運用するなら、静音・低消費電力・クラッシュ率の低さを合わせ持つ Mac mini M4 は、コストパフォーマンスの観点でも現実的な第一選択になります。
本文のような「無 UI で安全に回す」設計を本気で運用に載せるなら、まず一台の信頼できる Mac mini に状態を集約し、監査と承認の単一ライター規律を守るのが最短ルートです。今すぐ手元に置ける構成を検討するなら、 SSHMac の Mac mini ライン からプランを確認するのがおすすめです。