メッセージはテキストのみ。会話履歴やファイルは含まれない

これは最も誤解されやすい点なので、最初に明確にしておきます。

メッセージとは、あるClaudeが別のClaudeに送るテキストのみです。会話履歴でもファイルでもなく、コンテキストも含みません。受信側が見られるのは、送信者の名前とテキストだけです。相手が何を話し合ったか、どのファイルを操作したかは、一切わかりません。

ドキュメントに記載されているサンプルメッセージは次の通りです：

データベースマイグレーションは完了しました。新しいフィールドは tenant_id です。main へのリベースは安全です。

公式ドキュメントのサンプルメッセージ

これだけです。

つまり、境界線は明確です。会話全体を移したい場合、例えば別のコンピューターで続きをやりたい、あるいは新しいセッションに現在のコンテキストを引き継がせたい場合は、メッセージではなく、セッション全体を引き継ぐ復元（resume）を使うべきです。

2つのツールはClaudeが自動で呼び出す。手動送信の必要なし

この機能の背後には2つのツールがあります。ListAgents は到達可能なセッションを発見し、SendMessage は名前を指定してメッセージを送信します。

これらのツールを直接操作する必要はありません。Claudeが送信すべきかどうか、誰に送るかを判断し、文言も自ら作成します。あなたは「別のターミナルのセッションに、マイグレーションが完了したか聞いて」とか「支払いAPIを担当しているセッションに、さっきやった作業を知らせて」といったプロンプトを出すだけで、具体的なメッセージ内容はClaudeが決定します。

到達可能なセッションを自分で確認したい場合は、/list-agents と入力します。リストには3つの種類があります：

NAMINGセッション名はどこから来るのか

メッセージは名前で配信されます。名前の由来は3つあります。/rename で変更した名前、起動時に --name で指定した名前、どちらもない場合はClaude Codeが作業ディレクトリのフォルダ名から派生させて myapp-3f のような名前を生成します。

2つのセッションが同名になる可能性があります。/list-agents の出力には各セッションの作業ディレクトリが付加されて区別されます。Claude自身のリストには各行に短い識別子も追加され、名前が衝突した場合にそれを使用して特定します。

メッセージはツール呼び出しの合間に配信され、結果は3通り

メッセージが相手に届いても、相手の進行中の作業は中断されません。受信側のClaudeは2つのツール呼び出しの合間にメッセージを読み取るため、実行中のコマンドが中断されることは絶対にありません。セッションがアイドリング中だった場合、メッセージは新しいターンを直接開始します。

配信結果は3通りあります：

メッセージが配信されると、あなた自身がプロンプトを入力したのと同様に課金されます。配信後、受信側も同様に返信できます。ただし、マシンをまたぐ一方通行の場合を除きます。

別のセッションからのメッセージはユーザー承認として扱われない

これは設計全体で最も重要な点です。

セッションAがセッションBにメッセージを送信するとき、Claude CodeはBに明確に伝えます：このメッセージは別のセッションからのものであり、あなたの人間のユーザーからのものではありません。そして、実行可能なことを4つの制限で防ぎます。それぞれが具体的な悪用シナリオを防ぎます：

送信側にも同様の制約があります。Claudeは自分側で拒否されたり、ブロックされたり、権限設定上実行できないことを、別のセッションに依頼して実行させてはならないとされています。このような場合、別のセッションを通じて実行するのではなく、あなたに作業を戻す必要があります。

これら両側の制約を合わせると、同じ意味になります：クロスセッションメッセージは「伝言」のチャネルであり、「権限昇格」のチャネルではありません。

未設定の場合、2つのセッションの権限モードに基づいて配信が決まる

何も設定していない場合、Claude Codeは2つのセッションそれぞれの権限モードを確認して判断します。セッションを2つのタイプに分類します：プロンプトを表示して確認を求めるタイプと、権限プロンプトをスキップして直接実行するタイプです。

（plan モードは、スキップ能力を持つセッションでは「スキップ」タイプとみなされます。auto、acceptEdits、dontAsk はすべて「プロンプト表示」タイプとみなされます。）

ルールは次の通りです：

一見複雑ですが、背後にあるロジックはシンプルです：確認なしで直接実行できるセッションは、外部からメッセージを送られるリスクが最も高いため、受け取ったメッセージをそのまま実行してしまいます。したがって、権限が緩いセッションほど、受信時のチェックが厳しくなります。

DIALOG保留された後はどうなるか

メッセージが保留されると、受信側は送信者とメッセージプレビューを表示する承認ダイアログを表示します。選択肢は3つ：

• 承認：このメッセージをClaudeに渡す
• 拒否：またはダイアログを閉じると、このメッセージは破棄される
• 放置：dialogExpiry の期限（デフォルト5分）を過ぎるとダイアログは自動的に閉じ、メッセージは破棄される

保留されたメッセージは最大100件まで保存され、超過分は最も古いものから破棄されます。保留中にこのセッションの権限モードが変更された場合、ルールが再評価され、許可すべきものは許可されます。拒否に変更された場合は、保留中の全メッセージが破棄され、到達可能な各送信者に拒否通知が返信されます。

送信側にも動きが見えます：メッセージが保留されると通知が届き、その後、配信されたか、拒否されたか、期限切れになったかを示すフォローアップメッセージも届きます。最初から拒否された場合のみ、送信側には何の通知もありません。

同一マシンはローカルsocket経由、マシン間は返信のみ

メッセージがどの経路を通るか、こちらから何を送信できるかは、相手のセッションがどこにあるかによって決まります：

「返信のみ」の意味は、相手が先に連絡してきた場合にのみ、こちらから返信できるということです。別のマシン上のセッションに能動的に連絡したい場合、この経路は使えません。

VISIBILITY同一マシン内連携の前提は「同じファイル群が見えること」

各セッションはディスク上のファイルに自身を登録し、そこに受信ボックスソケットをバインドします。Claudeがローカルセッションを一覧表示または連絡するとき、これらのファイルを読み取ります。したがって、2つのセッションが互いに到達可能であるためには、同じファイル群が見える必要があります。

この推論は実際的です：コンテナには独自のファイルシステムがあるため、コンテナ内のセッションとホストマシン上のセッションは互いに到達できません。ただし、同じコンテナ内の2つのセッションは通信できます。セルフホストランナーでも同様です。

もう1つ、つまずきやすい詳細があります：マシンをまたぐ返信で、送信時にRemote Controlに接続していない場合、メッセージは（Anthropicサーバーへの直接リクエストで）配信されますが、返信先アドレスが含まれず、相手は返信できません。Claudeは送信時にこのことを通知されます。

このマシンから出るすべてのメッセージに承認を求める場合は、isolatePeerMachines を true に設定します。設定すると、すべての権限プロンプトをスキップするモードでも、返信がマシン外に出る前に確認を求められます。どの設定レベルでも true が書かれていれば有効なので、リポジトリにコミットされたプロジェクト設定でこの要件を有効にできますが、無効にすることはできません。同一マシン内のメッセージには影響しません。

claude -p セッションもメッセージを受信可能。socket はスクリプト用

無人実行の claude -p セッションも受信ボックスソケットにバインドされ、メッセージを受信でき、リストにも表示されます。したがって、長時間実行される -p ワーカーは指示を受け取れます。

ただし、ここに落とし穴があります：-p セッションは承認ダイアログを表示できません。そのため、メッセージが保留されると、後で設定が変更されて許可されない限り、保留されたままになります。無人ワーカーがメッセージを自律的に受信できるようにするには、起動時の --settings で crossSessionInbound を accept に設定する必要があります。（ユーザーレベルの設定でも可能ですが、その場合、実行するすべてのセッションに影響します。）

また、bare mode と呼ばれる起動方法もあり、これはソケットをバインドせず、メッセージを受信できず、リストにも表示されません。

SOCKETsocket の場所と使い方

パスは2箇所で確認できます：

• /status の Peer address の行。パスには uds: プレフィックスが付きます
• 環境変数 CLAUDE_CODE_MESSAGING_SOCKET。hook と Bash コマンドの両方から取得でき、任意の hook が実行される前にエクスポートされています（SessionStart を含む）。各セッションは自身のものをエクスポートし、親セッションのものを継承しません

つまり、スクリプトや hook が自身のセッションにメッセージを投函できます。当サイトの検証では値は /tmp/cc-socks/27983.sock でした。数字の部分はセッションに対応するプロセスIDです。

この経路には、覚えておく価値のあるプラットフォーム間の違いがあります。セッション自身の子プロセス（hook や Bash コマンドなど）がメッセージを投函する場合、送信元を検証できれば直接配信されます：Linux（WSL 2 内も含む）は終了した子プロセスでも検証できます。macOS はプロセスが生きている間のみ検証可能です。コンテナ内でClaude CodeがPID 1の場合、検証はまったくできません。検証できない場合は通常のメッセージとして扱われるため、権限プロンプトをスキップするセッションはそれを保留し、あなたの承認を待ちます。

サンドボックス内の Bash コマンドがソケットに到達できるかどうかは、サンドボックスの Unix ソケット設定（sandbox.network.allowAllUnixSockets と sandbox.network.allowUnixSockets）によって決まります。

受信と送信は個別に無効化可能。それぞれに副作用あり

受信と送信は2つの独立したスイッチで、片方だけを無効化できます：

2つの副作用を知っておく必要があります：

第一に、SendMessage を拒否すると、サブエージェントやチームメンバーへのメッセージ送信機能も一緒に無効になります。同じツールがこれらの機能を提供しているためです。セッション間の相互連絡を防ぎたいだけだったのに、セッション内のコラボレーションも無効になってしまいます。

第二に、無効化した後、外部からはまったく見えません。Claude Codeは通常通りソケットにバインドし続け、届いたメッセージを単に破棄します。拒否設定のセッションは、自身の /status や他のセッションのリストに何のマークも表示されません。確認するには、その設定を調べるしかありません。

復元、Agent teams などとの役割分担

Claude Code には「並行して開く」ためのメカニズムがいくつかあり、最も間違いやすい点です。ドキュメントには比較表が記載されているので、書き写しておく価値があります：

一言で区別すると：クロスセッションメッセージは「自分で開いた、それぞれ独立したセッション」間の連絡手段です。Claude が生成して統括するチームは、チーム独自の名簿を通じて連絡します。コンテキスト全体を移すのは復元の役割です。

システム、プロバイダーの制限、メッセージループのスロットリング

TROUBLESHOOT送信できない場合の調査方法

/list-agents と入力して、2つのケースを分けて考えます：

コマンドが認識されない：このセッションにはクロスセッションメッセージ機能がありません。上記の表を1つずつ確認し、まず claude --version から始めます。

コマンドは認識されるが、メッセージが届かない：機能は有効です。問題はより詳細な部分にあります。権限拒否ルールがこれらのツールを除外している可能性、受信側の受信制御がメッセージを保留または破棄している可能性、または相手が別のマシン上にある（返信のみ可能）可能性があります。

LIMITS2つのハード制限

プレーンテキストのみ送信可能です。Agent teams 内部の構造化されたプロトコルメッセージは、チームの外には出せません。

メッセージループは自動的に遮断されます。同じ送信者にはレート制限があり、短時間に届く完全に同一の重複メッセージは破棄されます。Claude が読むのを待つメッセージは、セッションごとに最大50件までスタックできます。したがって、2つのセッションが互いにメッセージを送り合う無限ループは、自然に停止します。あなたが介入する必要はありません。

送信されるのはテキストのみ

受信側が見られるのは、送信者の名前とテキストだけです。例：「データベースマイグレーションは完了しました。新しいフィールドは tenant_id です。リベースは安全です。」相手が何を話し合ったか、どのファイルを操作したかは、一切わかりません。

送信判断はClaudeが実施。ツールを直接操作する必要はありません

背後では2つのツールが機能しています。1つは到達可能なセッションを発見し、もう1つはメッセージを送信します。どちらも手動操作は不要です。Claudeが送信要否、送信先、文言を判断します。あなたは「別のターミナルのセッションに、データベースマイグレーションが完了したか聞いて」と指示するだけで、具体的なメッセージ内容はClaudeが作成します。

別のセッションの言葉は、あなたの同意ではない

メッセージが届くと、Claude Codeは送信元を明確にします：これは別のセッションの発言であり、あなたの発言ではありません。そして、実行可能なことを厳しく制限します。

セッションが自律的に判断するほど、外部からのメッセージは厳しくチェックされる

未設定の場合、Claude Codeは両セッションの権限の厳しさに基づいて配信を決定します：

この背後にある理論：確認なしで直接実行するセッションは、外部からメッセージを受け取るリスクが高いため、権限が緩いセッションほど受信時のチェックが厳しくなります。

このチャネルが不要な場合、受信と送信は個別に無効化できます：crossSessionInbound を refuse に設定すると受信を無効化。権限拒否ルールで SendMessage と ListAgents を指定すると送信を無効化できますが、セッション内でサブエージェントを呼び出す機能も一緒に無効になります。Bedrock、AWS、Google Cloud、Microsoft Foundry 上のバージョンでは現在利用できません。このチャネルは、あなた自身が開いた独立したセッション間の連絡手段です。復元や Agent teams などの他の「並行実行」メカニズムは、別の仕組みです。