Claude Codeのクロスセッションメッセージング

v2.1.224以降、MacまたはLinuxマシン上の対話型Claude Codeセッションはすべて起動時にUnixソケットをバインドし、自分が動かしている他のどのセッションからでもそこへテキストメッセージを投げ込めるようになりました。私の環境では/tmp/cc-socks/38590.sockにあり、パーミッションは所有者のみです。¹ ネイティブWindowsでは、リリースノートによればv2.1.239から代わりに名前付きパイプが使われ、遅延バインドという例外が1つ「落とし穴」の節にあります。この機能を動かすツールは2つです。ListAgentsが自分のセッションのうちどれに到達できるかを見つけ、SendMessageがそのうちの1つへ名前指定で届けます。² 有効化するものも、設定するものもありません。同じマシン上で両方のセッションがv2.1.224以降（Windowsではv2.1.239以降）で動いていれば、もう会話できます。

Claude Codeのセッション同士は、ローカルのUnixソケット（v2.1.239以降のネイティブWindowsでは名前付きパイプ）でメッセージを交わします。ListAgentsが到達できるセッションを見つけ、SendMessageが名前を指定してプレーンテキストを届けます。メッセージは入力であって、権限では決してありません。プロンプトを承認することも、設定を変えることも、コマンドを実行することもできず、会話履歴もファイルも運びません。

TL;DR

Claude Codeのセッション同士がメッセージをやり取りできるようになりました。同じマシン上ではAnthropicのサーバーを一切経由しないローカルソケットで、マシンをまたぐ場合はRemote Control経由です（公開当初は返信のみで、v2.1.225で名前を指定して会話を始められるようになりました）。¹⁵ メッセージはプレーンテキストだけで、会話履歴もファイルも権限も運びません。受け取る側のセッションはそれを権限ではなく入力として扱います。プロンプトを承認することも、設定を変えることも、コマンドを実行することもできないのです。¹ この機能によって、独立したターミナルの群れがチームに近いものへ変わります。いちばん活きる使い方は、これまで手作業で運んでいた調整のメッセージです。「マイグレーションが終わった」「あのカラムをリネームした」「mainはリベースしても安全」といった類のものです。もっとも鋭い落とし穴は、静かに消えることです。互いに無関係な4つのプライバシー関連の環境変数が、その値次第でそれぞれ黙ってこの機能を無効にしてしまいます。³ 公開後、v2.1.239でWindowsがネイティブに加わり、v2.1.236ではnotify_when_idleが追加されました。これは同じマシン上の相手セッションに、次にアイドルになるか終了したときに1回だけ通知するよう頼める仕組みです。⁹¹⁰

公開された内容

v2.1.224リリースでは、macOSとLinux向けにクロスセッションのSendMessageとListAgentsによる探索が追加されました。v2.1.225ではこれが拡張され、以前は返信しかできなかった他マシン上のRemote Controlセッションに対して、セッション側から会話を始めることもできるようになっています。⁴⁵

この仕組みを目にできる場所は3つあります。

• /list-agents（エイリアスは/peers）は、1行目にセッション自身の名前（他のセッションがこのセッションに到達するために使う名前で、v2.1.239から表示）を出力し、続いてClaudeが到達できるすべてのセッションを表示します。現在のセッション内のサブエージェント、そのセッションの稼働中のエージェントチームのチームメイト（v2.1.239から表示。それ以前は到達可能なチームメイトが不在に見えていました）、バックグラウンドのものを含む自分の他のローカルセッション、そしてRemote Controlが接続されている間は、他のマシン上のセッションとClaude Code on the web上のセッションです。¹⁹
• /statusにはPeer address行があり、セッション自身の受信ソケットがuds:という接頭辞付きで表示されます。¹
• CLAUDE_CODE_MESSAGING_SOCKETは、受信ボックスがバインドされるとClaude CodeがフックとBashコマンドにエクスポートする変数で（遅延バインドについては「落とし穴」の節を参照）、セッション自身のソケットパスを保持します。¹⁶ これがなぜ重要かは後述します。

2026年8月25日にClaude Code 2.1.246で自分のマシンで確認したところ、エージェント一覧は「This session is blakecrosley-com-76 [04e18a] — the name other sessions use to message it (it is not listed below; a message to it would be a message to yourself).」（このセッションはblakecrosley-com-76 [04e18a]。他のセッションがメッセージを送るときに使う名前で、下の一覧には含まれず、ここへのメッセージは自分宛てになる）という行で始まり、続いて「resumegeni-25 [10d770] · interactive · idle · started 21h ago」のような行で11個のピアセッションが並びました。名前はディレクトリ名に2文字の接尾辞を付けた形で、角括弧付きの短い識別子が添えられ、状態はidle、busy、shellのいずれか、行ごとに起動からの経過時間があり、セッション自身の子については別のSubagentsブロックにまとまっています。/tmp/cc-socks/配下のソケットファイルのパーミッションはsrw-------で、ディレクトリ自体はdrwx------です。読み書きできるのは自分のユーザーだけで、これが共有マシンでの境界になります。¹

セッションは名前で呼ばれます。/renameか--nameフラグで名前を付けられ、付けなければClaude Codeが作業ディレクトリからmy-app-3fのような名前を導き出します。¹¹¹ v2.1.232以降、対話型セッションを起動、再開、リネームした結果、そのマシン上の別の稼働中セッションがすでに使っている名前になった場合、Claude Codeは名前を先に持っていたセッションに残し、こちらをname-word-word形式の派生名（auth-refactor-graceful-unicornのようなもの）にリネームして、その旨を知らせます。¹¹⁰ 衝突が残るのは、一方のセッションが古いバージョンで動いている場合、重複した名前がClaude Codeの生成したものである場合、そしてClaude Codeが起動時に確認しない--nameを付けてバックグラウンドまたは-pセッションを起動した場合です。¹¹ 一覧には各ローカルセッションの作業ディレクトリが常に表示されるため、同名のセッションでも別のディレクトリで動いていれば見分けがつきます。名前が重複している場合、Claudeはさらに各行に短い識別子を加え、宛先にもそれを使います。クラウドやRemote Controlのセッション一覧が読み取り対象のページ数上限を超えたアカウントのように、セッションが動いているすべての場所をClaude Codeが確認できなかったときも、Claudeは同じ短い識別子による宛先指定にフォールバックします。¹

公開後に変わったこと（2026年8月）

公開後2週間で出た5つのリリースが、この記事が指摘したWindowsの空白を埋め、命名と宛先指定を引き締め、記事が指摘していなかった4つの静かな失敗モードを塞ぎました。⁹¹⁰

実用上の効果はこうです。後述の「報告する長時間実行セッション」パターンには、もう確認のプロンプトが要りません。見守る側のセッションがnotify_when_idleで長時間実行側に1回のアイドル通知を頼んでおけば、長時間実行側が次にアイドルになるか終了したときに返事が届きます。4つの失敗モードのうち2つ（大きすぎるメッセージと、受信ボックスに対して速すぎる連投）は送信側で事前に失敗するようになり、残りの2つ（拒否されたメッセージと捨てられたメッセージ）は、同じマシン上の対話型の送信者へ明示的な報告として返ってきます。

面白いのは信頼モデルです

Anthropicの設計は、多くのマルチエージェントシステムが取りこぼす問いに答えています。別のエージェントからのメッセージには、どれだけの重みがあるのか、という問いです。ここでの答えは明確です。メッセージは情報であって、権限では決してありません。¹

セッションAがセッションBにメッセージを送るとき、届いたものには4つのルールが課されます。¹

1. 何も承認できません。 Bで保留中の権限プロンプトは、Aが何を言おうと無視します。プロンプトに答えるのは自分だけです。
2. 設定を変更できません。 Claude Codeは受信側のClaudeに対し、別のセッションに頼まれたからといって権限設定、CLAUDE.md、その他いかなる設定も決して変えないよう指示しています。
3. コマンドはテキストとして届きます。 メッセージ本文の/compactは8文字の文章であって、実行されるコマンドにはなりません。
4. 権限プロンプトは変わらず出ます。 メッセージに従って動くのにBが持っていない権限が必要なら、他のどんな作業とも同じプロンプトが表示されます。

受信側の配信にも独自のゲートがあります。届いた各メッセージは3つの結果（配信、承認待ちで保留、拒否）のいずれかに落ち着き、これをcrossSessionInbound設定（accept、hold、refuse）が制御します。¹ 何も設定しなければ、Claude Codeは2つのセッションの権限モードを使ってメッセージごとに判断します。このデフォルトのロジックが見事です。権限プロンプトをバイパスするセッションが1つのクラスを、それ以外が別のクラスを形成します（プランモードはバイパスが利用可能なセッションではバイパス側に数えられ、auto、acceptEdits、dontAskはプロンプト側に数えられます）。プロンプト側のセッションはメッセージを自由に受け取りますが、バイパス側のセッションから届いたものは保留します。バイパス側のセッションは、同じくバイパス側のセッションからのメッセージ以外をすべて保留します。¹ この非対称は意図的なものです。メッセージが寛容なセッションの権限に便乗してはならない、という原則を、v2.1.222がautoモードの送信側に適用した（権限分類器が各送信をディスパッチ前に審査する）のに続いて、v2.1.224が受信側にも適用したのです。⁷

保留されたメッセージは、送信者とプレビューを示す承認ダイアログを開きます。応答のないダイアログは5分（dialogExpiryで調整可能）で期限切れになり、メッセージは破棄されます。¹ ターミナルが接続されていないバックグラウンドセッションでは、この期限を過ぎてもダイアログは開いたままです。接続した後、ダイアログが期限の一期間まるごと未応答のままだった場合にだけメッセージが破棄されます。¹ 一度に保留されるのは最大100件です。¹ さらに2つの制御で範囲を絞れます。isolatePeerMachines: trueにすると、bypassPermissionsモードであっても、メッセージがマシンの外へ出る前に明示的な承認が必要になります。どの設定スコープからのtrueでも優先されるため、チェックインされたプロジェクトファイルは締めることはできても緩めることは決してできません。¹ 組織として機能を完全に止めるには、マネージド設定でSendMessageとListAgentsへの拒否ルールにcrossSessionInbound: "refuse"を組み合わせます。¹

メッセージの通り道

相手のセッションがどこで動いているかによって、トランスポートと送れるものの両方が決まります。¹

この記事の初出時、Anthropicのドキュメントページはマシンをまたぐメッセージングをすべて返信のみと記述していましたが、v2.1.225のリリースノートはSendMessageが「can now start a conversation with your Remote Control sessions on other machines by name.」（他のマシン上のRemote Controlセッションと名前指定で会話を始められるようになった）と述べていました。ドキュメントはその後追いつき、自分の別のマシン上のセッションと会話を始めるにはv2.1.225以降と、一覧に現れる宛先が必要だと明記しています。¹⁵

同じマシンかどうかを決めるのはファイルシステムの可視性です。セッションはディスク上のファイルに登録されるため、2つのセッションが互いに到達できるのは同じファイルが見えるときだけです。コンテナ内のセッションとホスト上のセッションは会話できませんが、同じコンテナ内の2つのセッションなら会話できます。¹

配信は受信側セッションのリズムを尊重します。受信側のClaudeは、進行中のターンではツール呼び出しの合間にメッセージを読み、実行中のツールを中断することはありません。セッションがアイドルなら、Claude Codeがそのメッセージで新しいターンを始めます。¹ 配信されたメッセージは、自分で入力したプロンプトと同じように使用量に数えられます。¹

作る価値のある5つのパターン

1. ワークツリー間の調整。 いちばん分かりやすいもので、ドキュメントが自前の例文で示しているケースでもあります。同じリポジトリを別々のワークツリーで作業しているセッション同士が、何が入ったかを伝え合うのです。¹ 「Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.」（スキーマのマイグレーション完了。新しいカラムはtenant_idで、mainへのリベースはもう安全）は、そうでなければ自分が気づいてターミナルを切り替え、打ち直さなければならない類の更新です。複数のセッションがワークツリーではなく1つのチェックアウトを共有している場合、この調整メッセージの価値はさらに上がります。「これからcontent/guides/をコミットするので、ステージしないで」という一言が、あるセッションが別のセッションの作りかけの作業をコミットしてしまう、共有ツリーでの典型的な衝突を防ぎます。

2. 監視役と作業役。 デプロイ、テストスイート、ログを見張る監視セッションを走らせておき、何かが壊れた瞬間に修正担当のセッションへメッセージを送らせます。受け取る側のセッションは、その発見をコマンドではなくコンテキストとして受け取り、何をするかは自身の権限のもとで自分で決めます。監視役をバックグラウンドセッションと通知フックに組み合わせれば、本当に必要なときにだけ人間に行き着くエスカレーションの連鎖ができあがります。

3. 報告する長時間実行セッション。 あるセッションでマイグレーションや長いテスト実行を始め、実際に見ているセッションへ報告させます。¹ 状況が、忘れ去られたターミナルの中に閉じ込められなくなります。逆向きも成り立ちます。見ている側から尋ねるのです。「もう1つのターミナルで動いているセッションに、マイグレーションが終わったか聞いて」というプロンプトを出せば、探索も宛先指定も言い回しもClaudeが自分で処理します。¹ v2.1.236以降は、質問そのものを省けます。見ている側のセッションに長時間実行側へnotify_when_idleを設定させておけば、次にアイドルになるか終了したときに1回だけ報告が返り、どちら側もポーリングしません。¹¹⁰ 両方のセッションがv2.1.236以降である必要があり、制限は受信側の制御に従います。すべての購読には12時間の上限があり、それまでに通知が届かなければClaude Codeは購読を破棄し、Claudeに待つのをやめるよう伝えます。監視される側がrefuseだと、そのセッションは要求を記録も応答もせずに破棄するため、購読は上限まで応答のないまま期限切れになります。尋ねる側がrefuseだと、Claude Codeはそもそも購読しません。どちらか一方がholdだと通知は劣化した形で届きます。監視される側は1行のステータスを省き、尋ねる側は通知をClaudeに配信せずトランスクリプトに表示するだけになります。¹

4. 無人のワーカー群。 ヘッドレスのclaude -pセッションも受信ソケットをバインドするので、長時間動く-pワーカーはメッセージを受け取れ、一覧にも現れます。⁸ 注意点は、-pセッションは承認ダイアログを表示できないことです。デフォルトで保留されたメッセージはdialogExpiryの期限（デフォルトで5分。dialogExpiryには60s、5m、10m、neverを指定できます）まで待った後に破棄され、到達できる送信者には期限切れと報告されます。その時間内にモードか設定が変わった場合にだけ配信されます。¹ メッセージが保留されたままセッションが終了すると、Claude Codeは到達できる各送信者に期限切れとして報告します。¹ v2.1.225より前は期限がまったく存在せず、保留されたメッセージは通知も期限切れもなく放置され、保留メッセージを抱えたまま終了したワーカーは送信者に何も伝えませんでした。¹ 無人でメッセージを受け取るワーカーを動かすには、その--settingsの値にcrossSessionInbound: "accept"を入れて起動します。ワーカー単位の許可であって、自分が動かすすべてのセッションに効いてしまうユーザー設定でのacceptではありません。⁸ ベアモードのセッションはソケットを一切バインドせず、到達不能のままです。⁸

5. スクリプトからの投函。 地味ながら強力です。Claude CodeがCLAUDE_CODE_MESSAGING_SOCKETをフックとBashコマンドにエクスポートするため、スクリプトからセッション自身の受信ボックスへ投稿できます。⁶ Claude Codeは自分の子からのメッセージを検証します。フックやコマンドが自分のセッションへ投稿し返す場合、明示的なcrossSessionInboundが適用されていなければ、手続きなしで配信されます。¹ セッション自身のコミットが起動したgitフック、セッションが立ち上げたテストラッパー、セッションが実行したデプロイスクリプト。セッション自身が始めたフックやBashコマンドなら何でも、1行のコンテキストをそのセッションに投稿し返せます。Claude Codeは投稿者が自分の子であることを検証しなければならず、プロセスの証拠でもトークンでも検証できない場合は、権限クラスを主張しないメッセージとして扱います。そのため、バイパス側のセッションはそれを配信せず、承認待ちで保留します。¹ ネイティブWindowsでは、接続の1行目がCLAUDE_CODE_MESSAGING_TOKENを含む認証行でなければならず、そうでなければClaude Codeは読まずに接続を閉じます。Windowsが自分の子からのメッセージを検証する手段も、このトークンだけです。¹ Linuxではプロセスの証拠による検証が投稿プロセスの終了後も機能しますが、macOSでは動いている間しか機能しません。macOSで終了した後や、Claude CodeがPID 1のコンテナ内では、代わりにセッションがエクスポートしたCLAUDE_CODE_MESSAGING_TOKENを認証行で送った子を検証します。¹ サンドボックス化されたコマンドにはソケットの許可が必要です。macOSではsandbox.network.allowUnixSocketsにソケットパスを列挙し、seccompフィルターがパスを検査できないLinuxとWSL 2ではsandbox.network.allowAllUnixSockets: trueだけが開放します。このオプションのフィルターがインストールされていなければ、サンドボックスがソケットをブロックすることはそもそもありません。¹¹²

この機能がなろうとしないもの

制限は設計上の決定であり、それを尊重すれば間違ったものを作らずに済みます。

承認チャネルではありません。 信頼モデルのすべては、あるセッションが別のセッションの行動を認可するのを防ぐために存在します。「セッションAが承認し、セッションBが実行する」という形のワークフローは、設計上明示的に排除されています。権限は常に人間を経由させてください。¹

コンテキストの転送ではありません。 メッセージはあるClaudeが別のClaudeに宛てて書くテキストであって、会話履歴やファイルでは決してありません。Anthropicのドキュメントは率直に述べています。会話を移したければ、代わりにセッションを再開してください、と。¹ 要約して渡すのであって、丸ごと投げ込むのではありません。

エージェントチームではありません。 独立したセッション同士のメッセージングはピアツーピアのケースです。Claudeが生成して監督する協調チーム（構造化されたプロトコルメッセージ、名簿、共有タスク状態）はエージェントチーム機能であり、構造化されたチームメッセージは意図的にチーム内にとどまります。¹ クロスセッションのテキストの上にメッセージプロトコルを設計している自分に気づいたら、必要なのはエージェントチームです。

チャットループではありません。 Claude Codeは送信者ごとに繰り返しメッセージをレート制限し、短い時間内に届く同一の繰り返しを捨て、未読の受理済みメッセージをセッションあたり50件に制限します。そのため、2つのセッション間のメッセージループは設計上、自ら枯れていきます。¹ v2.1.236ではさらに、短時間の連投が受信側の受信ボックスの受け入れ上限を超える場合、受信側が捨てているのに送信済みと報告する代わりに、それ以降のメッセージを送信前の時点で拒否します。¹⁰ 作るべきは要求と応答のやり取りであって、会話ではありません。

落とし穴

プライバシー変数が黙って無効にします。 クロスセッションメッセージングはフィーチャーフラグの評価に依存しており、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK、DISABLE_GROWTHBOOKのいずれもがその評価を止め、メッセージングを道連れに、しかも静かに落とします。³ 診断には/list-agentsを使います。セッションがこのコマンドを認識しないなら、そのセッションには機能自体がありません。コマンドは動くのに送信が届かないなら、もっと狭い原因のどれかです。拒否ルール、受信側の受信制御、一覧にない宛先（Remote Controlが未接続か、Claude Codeが読み取るページ数上限からセッションがこぼれた）、あるいはv2.1.225より前の送信者がマシンをまたぐ会話を始めようとしている、といった場合です。¹ 受信ボックスを一度もバインドしていない宛先は、静かなケースではありません。プライバシー変数の影響下にあるセッション、ベアモードのセッション、コンテナ境界の向こう側のセッションは/list-agentsに決して現れないため、そこへの送信はClaude Codeが見つけられない名前として派手に失敗します。さらにv2.1.234以降、SendMessageは見えないセッションを不在として扱う代わりに、セッション一覧を完全には確認できなかったときにそう伝えます。¹³¹⁰ アップグレード後の最初のセッションは遅延バインドであって、欠落ではありません。Claude Codeはフィーチャーフラグの取得が完了した時点で受信ボックスをバインドしてソケット変数をエクスポートし、その最初のセッションが受信ボックスなしで起動することがあった問題はv2.1.228で修正されました。¹¹⁰ 本当に静かなケースは送信側にあります。ドキュメントが保留通知とその続報、到着時の拒否通知、破棄通知を約束しているのは同じマシン上の対話型の送信者だけなので、マシンをまたぐ送信者や-pワーカーには、それらのケースで約束された通知がありません。「each sender it can reach」（到達できる各送信者）に届く報告は2つあります。デフォルトで保留されたメッセージの期限切れと、設定変更によって保留メッセージが破棄されたときの拒否です。明示的なhold設定によって留め置かれたメッセージは決して期限切れにならないため、期限切れの報告が返ってくることもありません。¹

プラットフォームとプロバイダーの空白。 ネイティブWindowsはv2.1.239で対応しました。それ以前はWSL 2内のLinuxだけが動いていました。¹⁹ AnthropicのドキュメントページはWindowsの下限をv2.1.234としていますが、リリースノートで最初に告知されたのはv2.1.239です。安全な下限はv2.1.239と考えてください。¹⁹ 同じコンピューター上のWSL 2内のセッションとネイティブWindowsのセッションも互いに到達できません。異なるホームディレクトリに登録され、異なる種類のソケットで待ち受けるからです。¹ Amazon Bedrock、Claude Platform on AWS、Google CloudのAgent Platform、Microsoft Foundryでは利用できません。¹

一方通行の返信という端のケース。 返信する側のセッションがRemote Controlに接続していない状態で送った他マシン上のセッションへの返信は届きはしますが、返信先アドレスがないため受信側は答えられません。Claude Codeは送信時にその旨をClaudeに伝えます。v2.1.225では宛先指定も引き締められ、Claude Codeが自身のセッション一覧を確認できなかったとき、確認済みの他マシン上の宛先を同名のローカルセッションと取り違えることは決してなくなりました。⁵

ヘッドレスでの保留。 メッセージを不可解に無視する-pワーカーは、ほぼ例外なく保留メッセージの問題です。ダイアログがなければ配信もありません。受け取るべきワーカーにはcrossSessionInbound: "accept"を設定してください。⁸

重要なポイント

日常的にClaude Codeを使う人向け： - 一度/list-agentsを実行して、セッションがすでに何に到達できるかを確かめましょう。重要なセッションには/renameで名前を付けておくと、メッセージの宛先がきれいに定まります。Claude Codeガイドでは、この機能が依存するセッションコマンドと設定を扱っています。 - メッセージは普通の言葉で頼み（「決済を担当しているセッションに、何を変えたか伝えて」）、文面はClaude自身に書かせましょう。¹

自動化を組む人向け： - フックやスクリプトからはCLAUDE_CODE_MESSAGING_SOCKET経由でセッションに投稿します。自分の子からのメッセージは、Linuxでは承認の手間なく配信されます。¹⁶ - 無人の-pワーカーには、グローバルではなくそれぞれの--settingsでcrossSessionInbound: "accept"を与えます。⁸

チームとセキュリティレビュアー向け： - この機能は正しいデフォルトで出荷されています。メッセージは権限を持たず、デフォルトでバイパス側のセッションは隔離され、isolatePeerMachinesとマネージド設定の拒否ルールがマシン単位と組織全体のオフスイッチになります。¹ - メッセージングが壊れていると結論づける前に、4つのプライバシー環境変数を点検してください。拒否しているセッションは一覧でも自身の/statusでも見た目が変わらないので、ステータスではなくそのセッションに適用される設定ファイルを確認します。v2.1.238以降は、同じマシン上のセッションからの送信でも拒否が報告として返ってきます。¹¹⁰

よくある質問

Claude CodeのクロスセッションメッセージングはWindowsで動きますか？

はい。リリースノートによればv2.1.239からネイティブに動作し、同じSendMessageとListAgentsツールを使い、Unixソケットの代わりに名前付きパイプが使われます。それ以前はWSL 2内のLinuxだけが動いていました。AnthropicのドキュメントページはWindowsの下限をv2.1.234としていますが、安全な下限はv2.1.239と考えてください。同じコンピューター上のWSL 2のセッションとネイティブWindowsのセッションは、今でも互いに到達できません。¹⁹

あるClaude Codeセッションが別のセッションの権限プロンプトを承認できますか？

いいえ。メッセージは情報であって、権限では決してありません。保留中の権限プロンプトは送信側のセッションが何を言おうと無視します。プロンプトに答えるのは自分だけだからです。Claude Codeは受信側のClaudeに対し、別のセッションに頼まれたからといって権限設定、CLAUDE.md、その他いかなる設定も変えないよう指示しており、メッセージ本文の/compactは8文字の文章であって、実行されるコマンドにはなりません。¹

他のセッションが/list-agentsに現れないのはなぜですか？

まずプライバシー関連の環境変数を点検しましょう。メッセージングはフィーチャーフラグの評価に依存しており、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK、DISABLE_GROWTHBOOKのいずれもがその評価を止め、メッセージングを道連れに、しかも静かに落とします。ベアモードのセッションや、コンテナ境界の向こう側のセッションも決して現れません。2つのセッションが互いに到達できるのは、ディスク上の同じファイルが見えている場合だけだからです。¹³

無人のclaude -pワーカーにメッセージを受け取らせるには？

そのワーカーの--settingsの値にcrossSessionInbound: "accept"を入れて起動します。実行するすべてのセッションに効いてしまうユーザー設定のacceptではなく、ワーカーごとの許可として与えるわけです。-pセッションは受信ボックスのソケットをバインドして一覧にも現れますが、承認ダイアログを表示できません。そのため、デフォルトで保留されたメッセージはdialogExpiryの期限を待ち切って破棄されます。⁸

会話履歴やファイルを別のセッションに送れますか？

いいえ。メッセージはあるClaudeが別のClaudeに宛てて書くプレーンテキストであって、会話履歴でもファイルでも権限でもありません。Anthropicのドキュメントは率直に述べています。会話を移したければ、代わりにセッションを再開してください、と。丸ごと投げ込むのではなく、要約して渡しましょう。そして、クロスセッションのテキストの上にメッセージプロトコルを設計している自分に気づいたら、本当に必要なのはエージェントチームです。¹

参考文献