【Claude Code 連載第73回】他の Claude Code セッションにメッセージを送信する — セッション間の配送路

よっしー

こんにちは。よっしーです(^^)

背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. 一言でいうと何か

このページは、ある Claude Code セッションの Claude が、別のセッションの Claude にテキストを届ける——クロスセッションメッセージングの解説です。

前回（第72回）で拡張機能の一覧に初登場した機能。その専用ページが今回です。

用途の説明が具体的です。一つのセッションでの変更が別のセッションが構築しているものを破壊する場合、Claude はあなたが気付く前にそのセッションに警告することができます。一つのセッションが別のセッションがブロックされている質問を解決する場合、Claude は答えを送信することができます。

何が送られるのかは、最初に厳密に限定されています。

メッセージは、一つの Claude が別の Claude に書くテキストの一部であり、送信者の会話履歴またはファイルではありません。会話全体またはそのコンテキストを移動するには、代わりにセッションを再開してください。

**運ぶのはテキストだけ。**コンテキストの移送ではありません。ここを取り違えると期待が外れます。

使われるツールは2つ。到達できるエージェントを発見するための ListAgents と、名前でそのうちの1つにメッセージを配信するための SendMessage です。同じ SendMessage はサブエージェントとエージェントチームのチームメイトにも使われますが、このページは、独立したセッション間のメッセージについて説明しています。

そして設定は不要です。セッションが要件を満たしている場合、メッセージングは有効になっており、有効にするものはありません。——第66回のエージェントチームが環境変数必須だったのとは対照的に、条件を満たせば勝手に有効です。

2. どういう場面で役立つか

原文が挙げる典型は4つ。共通点は1つのセッションが、別のセッションの必要とするものを持っていることです。

シーン1：検出結果を引き継ぐ

1つのセッションが破壊的な変更を発見するか決定を下すと、Claude はそれを影響を受ける領域で作業しているセッションに要約します。そこで再度説明する代わりに。

あなたが両方のターミナルに同じ説明を書く手間が消える、というのが実利です。

シーン2：並列ワークツリーを調整する

**セッションが別のワークツリーで同じリポジトリで作業する場合、Claude は他のセッションに何がマージされたかを伝えることができます。**第63回の worktree 運用の穴——分離した結果、互いの状況が見えない——を埋める機能です。

シーン3：長時間実行の作業を待つ

**マイグレーションまたはテスト実行を監視しているセッションに報告させるか、そこから自分で尋ねます。**さらに専用の仕組みがあります。そのセッションがこのマシン上にある場合、Claude は次にアイドル状態になるか終了するときに1つの通知を求めることもできます。（後述）

シーン4：マシンをまたぐ

別のマシンまたはウェブ上の1つのセッションに到達します。

不要・向かないケース

原文は**「実行している内容に対して構築されたものを使ってください」**として、5つの代替を名指ししています。

会話の続きを別のターミナルでやりたい／コンテキストを共有したい。→ セッションを再開（第68回）。メッセージングは履歴を運びません。
Claude に指揮させたい。→ エージェントチーム（第66回）。
多数のセッションを1画面で見たい。→ エージェントビュー（第65回）。
スマホから自分で操舵したい。→ リモートコントロール（第24回）。
CI 結果やチャットなど外部イベントを流し込みたい。→ チャネル（第45回）。
**構造化データを送りたい。**プレーンテキストのみ。そして構造化されたエージェントチームプロトコルメッセージはチーム内に留まります。
**コンテナとホストをまたぎたい。**コンテナは独自のファイルシステムを持つため、コンテナ内のセッションとホスト上のセッションは互いに到達できません。同じ理由でWSL 2 内のセッションと同じコンピュータ上のネイティブ Windows セッションも互いに到達できません。
**ベアモードの -p セッションに送りたい。**Claude Code はソケットをバインドしないため、そのセッションはメッセージを受信できず、エージェントリストに表示されません。

3. 使い方と挙動の解説

fenced ブロックは7本（プロンプト例4・メッセージ例1・JSON 2）。すべて原文どおり引用します。

前提が多いページなので、バージョン要件を先に表にまとめます。

対象	必要バージョン
機能全体（macOS・Linux・WSL 2）	v2.1.224 以降
機能全体（ネイティブ Windows）	v2.1.234 以降
マシンを超えた会話を自分から開始する	v2.1.225 以降
`@` メンションでターゲット指定／`/config` の行	v2.1.232 以降
アイドル通知（`notify_when_idle`、両セッションとも）	v2.1.236 以降
`/list-agents` にチームメイトと自セッション名が出る	v2.1.239 以降
一部プロバイダーでフラグ取得オフ時の同一マシン配信	v2.1.248 以降
`claude -p` 送信者への保留通知	v2.1.271 以降

プロバイダー条件も分かれます。このマシン上のセッションはAmazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry を含むすべてのプロバイダーで利用可能。一方このマシンを超えたセッションはこのセッションのアクティブな認証として claude.ai サインインが必要で、Claude は API キーまたは Amazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry ではこれらのセッションを検出できません。

送り方 — 自分は ListAgents も SendMessage も呼ばない

Claude は ListAgents でターゲットを検出し、SendMessage で送信するため、ユーザーがこれらのツールを呼び出す必要はありません。Claude は要求されなくてもメッセージを送信することを決定できますし、ユーザーがメッセージを促すこともできます。

促す場合のプロンプト例（以下の例は Claude が送信するメッセージではなく、ユーザーが入力するプロンプトです）。

他のターミナルで実行中のセッションに、マイグレーションが完了したかどうかを確認してください

文面を Claude に任せることもできます。

支払い API で作業中のセッションに、今実行したことを説明してください

Claude は実際のメッセージ自体を作成するため、ユーザーのプロンプトはコンテンツを Claude に任せることができます。

宛先を自分で決めるなら @ メンション。@ に続けてセッション名の最初の文字を入力し、タイプアヘッドからセッションを選択します。これはサブエージェントを明示的に呼び出す場合と同じ方法です。

@api-worker にスキーママイグレーションが完了したことを知らせてください

メンションの効果が説明されています。Claude Code はメンションを挿入し、Claude にそのセッションを指定するため、Claude はセッションを最初にリストアップせずにそのセッションにメッセージを送信できます。

タイプアヘッドには例外が2つ。クラウドまたはリモートコントロールセッションは、Claude がこのマシンを超えたセッションをリストアップまたはメッセージした後にのみタイプアヘッドに表示されるため、Claude に最初にそれらをリストアップするよう依頼してください。そしてスペースまたは文字、数字、ハイフン、アンダースコア以外の文字を含む名前は**@"release notes" のようにダブルクォートで入力**します（ピッカーから選べば自動で付きます）。

届き方

受信側の挙動が明確です。受信側の Claude はアクティブなターンの間にツール呼び出しの間でメッセージを読むため、実行中のツールが中断されることはありません。受信セッションがアイドル状態の場合、Claude Code はメッセージで新しいターンを開始します。

**作業中のセッションを壊さない。**ここは安心材料です。

@ の扱いに注意点があります。別のセッションからのメッセージはプレーンテキストとして到着します。@ でファイルまたは MCP リソースに言及する場合、Claude は記述されたメンションを見て、Claude Code は何も添付しません。ただしClaude は依然として受信マシン上の指定されたパスを独自のツールで開くことができます。そのセッションの権限に従います。（v2.1.251 より前は添付されていました）

送信が拒否される条件は4つ。サイズ上限超過（送信側で拒否）、急速なバーストでインボックスが受け入れる量に到達、返信ターゲットが安全性チェックに失敗（シンボリックリンクされたターゲットや予期されたプロセスではないエンドポイントなど）、自分自身の名前に送ろうとした場合。

受信側では3つの結果のいずれかになります。配信済み／保留中／拒否。

そしてコスト。配信されると、メッセージは使用状況に対してユーザーが入力したプロンプトのようにカウントされ、受信側の Claude は同じ方法で送信者に返信できます。（一方向クロスマシンの場合を除く）

権限の壁は越えない

このページで最も重要な設計がここです。

Claude は、自身のセッションで拒否またはブロックされたアクション、または独自の権限設定がブロックするアクションを別のセッションに要求しないよう指示されており、その作業をユーザーに戻すよう指示されています。

受信側にも壁があります。セッション A がセッション B にメッセージを送信する場合、Claude Code は B の Claude に対して、そのメッセージがあなたからではなく別のセッションから来たことを伝え、メッセージが実行できることを制限します。

**何も承認できません。**別のセッションからのメッセージはあなたの同意としてカウントされないため、保留中の権限プロンプトに代わって応答することはできません。
**設定を変更できません。**権限設定、CLAUDE.md、またはその他の設定を変更しないよう指示します。
**コマンドは実行されません。**メッセージのテキスト内のコマンド（/compact など）はプレーンテキストとして到着します。Claude Code はそれを実行することはありません。
権限プロンプトは引き続き発火します。

第66回のエージェントチームで見た「同意ロンダリング封じ」と同じ思想が、セッション間にも一貫して適用されています。

アイドル通知

**Claude は、このマシン上のセッションの1つに、そのセッションが次にアイドル状態になるか終了するときに1つの通知を送り返すよう依頼できます。**定義も明確です。ここでアイドルとは、セッションがキューに入っているものがない状態でターンを完了したことを意味します。

頼み方。

マイグレーションセッションが作業を完了したときに教えてください

内部では**SendMessage ツールの notify_when_idle 入力で購読**します。単独で使う場合の挙動が効率的です。Claude Code は監視対象セッションでターンを開始したり、トークンを消費したりせずに購読し、そのセッションが既にアイドル状態の場合は通知をすぐに送信します。

制限が3つ。通知は1回限りです。そして12時間以内に通知が到着しない場合、Claude Code は購読を削除し、Claude に通知するため、待機を続けません。さらにメインの会話の Claude のみが購読でき、このマシン上のセッションのみに購読できます。

対象外に頼んだ場合の挙動も定義されています。Claude がチームメイト、サブエージェント、またはこのマシンを超えたセッションなど、他のエージェントから通知をリクエストする場合、Claude Code は添付されたメッセージを含む呼び出し全体を拒否し、Claude に拒否を報告して、リクエストなしでメッセージを再送信できるようにします。

到達できるセッションを見る

/list-agents コマンドを実行します。（/peers としても利用可能）

**最初の行（存在する場合）はこのセッション自体の名前で、他のセッションがそれにメッセージを送信するために使用する名前です。**以下の行が到達先——サブエージェント／チームメイト／他のローカルセッション（バックグラウンドセッションを含む）／クラウドセッション（cloud とラベル）／他のマシン上のリモートコントロールセッション（Remote Control とラベル、切断中は offline）。

ローカルセッションが出る条件は1つ。セッションはインボックスソケットをバインドするときにのみ表示されます。

リモートコントロール接続中は表示が一部伏せられます。プライバシー配慮です。各ローカルセッションの作業ディレクトリを除外します。****人に属性付けできないセッション名を除外するため、名前が残っていない行は (unnamed session) と読みます。****このセッション自体の名前を持つ行を除外します。——ただしユーザーがこのターミナルでその名前を入力した場合を除きます（--name または /rename で自分が付けた名前なら出る）。

**リスト件数にも上限があります。**Claude Code はクラウドおよびリモートコントロールセッションリストを最新順に読み、各ページの制限数の後に停止します。アカウントにそれ以上のセッションがある場合、Claude Code は古いセッションをリストアップしません。Claude はそれらを名前でメッセージできません。

名前の付き方と衝突

宛先は名前です。セッションは /rename コマンドまたは --name フラグで設定した名前に応答します。設定しない場合、Claude Code はセッション自体に名前を付けます。

改名時に裏で起きることも書かれています。Claude Code は他のセッションがセッションの名前を検索するために使用する共有レコードも更新します。そのレコードを更新できない場合、他のセッションが古い名前を表示する可能性があることを /rename 出力で警告します。

重複したらClaude Code は既に名前を持つセッションに名前を残し、ユーザーの名前をバリアントに変更します。それでも同名が並ぶことはあり（古いバージョンが動いている場合など）、その場合はClaude はリストの各行に短い識別子を追加し、アドレスで識別子を使用します。

マシンをまたぐ経路

メッセージがどのように移動するか、および Anthropic サーバーを通過するかどうかは、ターゲットセッションが実行される場所によって異なります。

他のセッションが実行される場所	メッセージの移動方法
このマシン上	macOS および Linux 上のセッションごとのソケット、またはネイティブ Windows 上のセッションごとの名前付きパイプ。Anthropic サーバーを通じて決してない
他のマシンの1つ	Anthropic サーバーを通じて、そのマシンのリモートコントロール接続を通じて到着
クラウド	Anthropic サーバーを通じて、クラウドセッションに直接

**同一マシンなら外に出ない。**ここは情報統制の観点で押さえるべき事実です。

オフライン相手にも送れます。送信は通過しますが、メッセージはそのセッションのマシンが再接続した後にのみ到着します。

返信アドレスの扱いが独特です。このセッションがリモートコントロールに接続されている間、別のマシン上のセッションにメッセージを送信する場合、Claude Code はそのセッションの会話でこのセッションのリモートコントロール名の下にメッセージを表示します。例としてlaptop-graceful-unicorn が挙がっています。逆にリモートコントロールに接続されていない場合、メッセージは依然として通過しますが、返信アドレスなしで、受信側の Claude は応答できません。——一方向になるということです。

見え方

メッセージが到着すると、Claude Code は会話内に薄い1行のプレビューとして表示し、プレビュー行は後で会話に残ります。形式は› Message from @api-worker: Schema migration finished (ctrl+o to expand) のようになります（v2.1.247 より前は全文表示でした）。

全文を見るには**Ctrl+O を押してトランスクリプトビューアを開くか、--verbose で開始されたセッション**なら最初から全文が出ます。プレビューは表示内容のみを短縮します。展開するかどうかに関わらず、Claude はメッセージ全体を読みます。

実際のメッセージ例（ある Claude が別の Claude に書いたメッセージ）。

Schema migration finished
The new column is tenant_id, and rebasing on main is safe now.

サブエージェントが送った場合は経路が変わります。送信側セッションの名前で到着し、メッセージテキスト内でサブエージェントが識別されます。それへの返信は、そのセッションのメイン会話に到達し、サブエージェントには到達しません。

受信側のコントロール

crossSessionInbound で決めます。

値	動作
`accept`	Claude Code は各メッセージを Claude に配信します
`hold`	Claude Code は各メッセージの通知を表示し、配信しません。後で `accept` が適用される場合、優先順位ルールに従って、Claude Code は保留中のメッセージをリリースします
`refuse`	Claude Code は各メッセージを配信せずにドロップします

設定ファイル以外に**/config 行の Messages from your other sessions** から選べます（v2.1.232 以降、管理設定や --settings がキーを設定していると非表示）。なおClaude Code はこのキーに対して /config crossSessionInbound=value ショートハンドを拒否します。

未設定時の既定が巧妙です。値が適用されない場合、Claude Code は2つのセッションの権限モードに基づいてメッセージごとに決定します。分類は権限プロンプトをバイパスするセッションを1つのクラスにグループ化し、他のすべてのセッションを別のクラスにグループ化します。Plan mode は、バイパス権限が利用可能なセッションではバイパスとしてカウントされ、auto、acceptEdits、dontAsk はプロンプトとしてカウントされます。

そのうえで——

受信側セッションが権限をプロンプト：各メッセージを配信します。送信側セッションが権限プロンプトをバイパスしていることを識別する場合のみ、承認のために1つを保留します。
受信側セッションが権限をバイパス：各メッセージを承認のために保留します。送信側セッションも同様にバイパスしていることを識別する場合のみ、1つを配信します。

**無警戒なセッション（bypassPermissions）宛ては、原則いったん止める。**危険側に倒さない設計です。

保留時のダイアログには送信者とプレビューが表示され、Approve で配信、Deny または閉じると破棄。dialogExpiry 期限（既定5分）を過ぎて未回答なら閉じてドロップします。バックグラウンドセッションは例外で、ターミナルが接続されていない場合、Claude Code はダイアログを期限を過ぎて開いたままにします。

途中で状況が変われば再評価されます。このセッションの権限モードクラスがメッセージが保留されている間に変更される場合、Claude Code はインバウンドルールを再適用し、現在受け入れるメッセージを配信し、通知を表示します。逆に設定変更により refuse が適用される場合、すべての保留中のメッセージをドロップし、到達できる各送信者に拒否を報告します。

送信側に結果が返るのも良い設計です。同じマシン上のセッションの場合、Claude Code は受信者がメッセージを保留するときに通知を送信し、受信者が後でメッセージを配信、拒否、または期限切れにするときにフォローアップを送信します。通知は送信側の Claude に到達するため、他のセッションが読んでいないメッセージで待機し続けないようになります。

保留の上限は最大100個のメッセージを保留し、配信キューとは別に、それを超えると最も古いものをドロップします。

非インタラクティブセッション

claude -p セッションのインボックスソケットをインタラクティブなものと同様にバインドするため、長時間実行される -p ワーカーはメッセージを受信でき、リストに表示されます。ただしベアモードは対象外です。

-p は承認ダイアログを表示できません。保留された場合は同じ dialogExpiry 期限（デフォルトは5分）でそれを保持し、期限前にモードや設定が変われば配信、期限後はドロップして送信者に報告します。

無人運用の作法も示されています。-p ワーカーが無人でメッセージを受け取れるようにするには、その --settings 値で crossSessionInbound を accept に設定して開始します。ユーザー設定の accept も機能しますが、実行するすべてのセッションに適用されます。

インボックスソケット

Claude Code は、クロスセッションメッセージングが有効になっている各セッションのインボックスソケットをバインドします。実体はmacOS と Linux（WSL 2 内の Linux を含む）では Unix ドメインソケットで、ネイティブ Windows ではネームドパイプです。

パスの確認方法は2つ。/status は Peer address 行に表示します。パスは uds: で始まります。そしてフックと Bash コマンドに CLAUDE_CODE_MESSAGING_SOCKET 環境変数としてエクスポートされます。メッセージングがオンで開始するセッションでは、SessionStart を含むすべてのフックが実行される前に変数をエクスポートします。

保護もされています。macOS と Linux では、Claude Code はソケットをオペレーティングシステムユーザーに制限します。ネイティブ Windows では、代わりに各接続がまずオペレーティングシステムユーザーのみが読み取ることができるキーで認証することを要求します。

スクリプトから自分のセッションに投稿できるのがこの節の実用点です。セッションごとのトークンを CLAUDE_CODE_MESSAGING_TOKEN としてエクスポートしており、接続の最初の行として {"type":"auth","token":"<token>"} を送信できます。認証行はmacOS と Linux ではオプション、ネイティブ Windows では必須です。

接続のタイミングにも注意があります。投稿するメッセージの準備ができたときにのみ接続を開きます。Claude Code は30秒以内に完全な行を送信していない接続を閉じるため、遅いコマンドの出力をまずキャプチャしてから接続を開いて送信します。

自分の子プロセスからのメッセージには特例があります。**crossSessionInbound 値が適用されない場合、Claude Code はセッションの独自の子プロセス（フックや Bash コマンドなど）から来たことを検証したメッセージを配信します。**検証方法はプラットフォーム差があり、Linux ではプロセス証拠で既に終了した子も検証可能、macOS は投稿プロセスが実行中のときのみ、ネイティブ Windows ではトークンが唯一の方法です。検証できない場合は、権限クラスを主張しない他のメッセージのように扱うため、bypass 側は保留になります。

サンドボックス下では別の設定が効きます。Bash コマンドがサンドボックス内からソケットに到達できるかどうかを、サンドボックスの Unix ソケット設定 sandbox.network.allowAllUnixSockets と sandbox.network.allowUnixSockets で制御します。

絞る・止める

マシンを超えた送信に承認を要求するなら isolatePeerMachines。

{
  "isolatePeerMachines": true
}

**これが設定されている場合、Claude Code は、bypassPermissions モード（通常の権限プロンプトをスキップする）でも、Claude のメッセージがこのマシンを超えたセッションに出発する前に承認を求めます。**そして一方向性があります。任意の設定スコープからの true が適用されるため、チェックインされたプロジェクトファイルは要件をオンにできますが、オフにはできません。

完全に止める場合は方向ごとに分かれます。受信を停止は crossSessionInbound を refuse、送信とリストを停止は**SendMessage と ListAgents に名前を付ける権限拒否ルール**（両方は指定子なしでベアツール名を取ります）。組織全体なら管理設定で両方を。

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

副作用が明記されています。SendMessage を拒否すると、同じツールが両方に機能するため、サブエージェントとエージェントチームチームメイトへのメッセージングも削除されます。

診断上の注意も1つ。拒否するセッションは、独自の /status またはマシン上の他のセッションのリストに目に見える変化を示さないため、確認するには、ステータスではなく、そのセッションに適用される設定ファイルを確認してください。

届かないときの切り分け

原文が切り分けの入口を用意しています。

/list-agents が認識されない→**セッションはクロスセッションメッセージングを持っていません。**まず claude --version。

/list-agents は機能するが、送信が到着しなかった→メッセージングはオンであり、より狭い範囲の何かが適用されます。候補は拒否ルール／受信側のインバウンドコントロール／クラウドセッションはリモートコントロール接続中のみ表示／他マシンは双方がリモートコントロール／offline 相手は再接続後に到着／古いセッションはページ制限で載らない。

その他の制限

同じマシンメッセージサイズは上限があります。****シリアル化された形式が約100万文字を超えると拒否し、受信側のセッションには何も到達しません。
急速なバーストは送信者で拒否されます。（v2.1.236 より前は送信済みと報告しつつ受信側が捨てていました）
**メッセージループはスロットルされます。**送信者ごとに繰り返されたメッセージをレート制限し、短いウィンドウ内に到着する同一の繰り返しをドロップし、最大50個の受け入れられたメッセージを Claude が読むためにキューに入れます。したがって、2つのセッション間のメッセージループは独自に停止します。

**Claude 同士が延々と往復する事故が、仕組みで止まる。**自律エージェント同士を繋ぐ以上、必須の安全装置だと思います（この評価は筆者のものです）。

4. まとめ＋次回予告

クロスセッションメッセージングはある Claude から別の Claude へテキストを届ける機能。要件を満たせば自動的に有効で、有効化設定はない。
運ぶのはテキストだけ。会話履歴もファイルも渡らない。コンテキストごと移したいならセッション再開。
使うツールは ListAgents（発見）と SendMessage（配信）。ユーザーが呼ぶ必要はない。
宛先は名前。@ メンションのタイプアヘッドで指定でき（v2.1.232 以降）、空白入りの名前は @"..."。
**受信側は作業を止めずに読む。**ツール呼び出しの合間に入り、アイドル中なら新しいターンが始まる。
権限の壁はセッションをまたがない。受信メッセージは承認にならない・設定を変えられない・コマンドを実行しない。権限プロンプトは通常どおり出る。
アイドル通知は notify_when_idle。1回限り・12時間で失効・同一マシンのみ・メイン会話の Claude のみ。
**/list-agents（＝/peers）**で到達先を確認。最初の行が自分の名前。リモートコントロール接続中は作業ディレクトリと一部の名前が伏せられる。
経路は3つ。同一マシンはソケット／名前付きパイプで、Anthropic サーバーを通らない。他マシンとクラウドはAnthropic サーバー経由。
リモートコントロール未接続でマシンを越えて送ると、返信アドレスが付かず一方向になる。
到着表示は1行プレビュー（v2.1.247 以降）。全文は Ctrl+O か --verbose。Claude は常に全文を読む。
受信制御は crossSessionInbound の accept / hold / refuse。未設定時は双方の権限モードで自動判定され、bypassPermissions 側が絡むと保留に倒す。
**保留は送信側に通知が返る。**待ち続けずに済む。保留は最大100件。
claude -p も受信できる（ベアモードを除く）。ダイアログが出せないので**dialogExpiry（既定5分）で期限切れ**。無人運用は --settings で accept。
フックや Bash から自分のセッションのソケットへ投稿できる。CLAUDE_CODE_MESSAGING_SOCKET と CLAUDE_CODE_MESSAGING_TOKEN、接続後30秒以内に1行。
絞るなら isolatePeerMachines（マシン越えに承認必須、オンにはできてもオフにはできない）、止めるなら refuse ＋ SendMessage/ListAgents の拒否ルール。SendMessage 拒否はチームメイトとサブエージェントへの送信も巻き添えにする。
安全装置——約100万文字の上限／バースト拒否／同一メッセージのレート制限とキュー上限50でループが自然停止。

次回予告（暫定）：第72回で挙がった拡張機能のうち最後に残った**アーティファクト（artifacts）**を取り上げ、セッションの出力をプライベートなインタラクティブ Web ページとして公開する仕組みを扱う予定です。