Claude Code クロスセッションメッセージングをいつ使うか

別のターミナルで走らせているClaude Codeの片方がスキーマを変えて、もう片方は古い前提のままコードを書き続けている。

並列でセッションを回していると、これがふつうに起きます。

v2.1.224で入ったクロスセッションメッセージングは、そこにセッション同士の直通回線を通す機能です。

クロスセッションメッセージングで送れるのはテキストだけ

自分でツールを叩く場面はありません。

Claudeが ListAgents で届く相手を探し、SendMessage で名前を指定して送ります。

こちらは「別のターミナルのセッションに、マイグレーション終わったか聞いて」と言うくらいで、Claudeが必要だと判断して勝手に送ることもあります。

ここが勘所なんですが、飛ぶのはテキストだけです。

会話履歴もファイルも渡りません。

受信側に届くのは、送信者の名前と本文と返信先だけ。

公式が載せている実例はこんな一行です。

「スキーマのマイグレーションが終わった。新しいカラムは tenant_id で、main へのリベースはもう安全」

痩せて見えますが、これは制約ではなく設計です。

コンテキストごと引き渡したいならメッセージングではなくセッションのresumeを使え、と公式がはっきり線を引いています。

Message your other Claude Code sessions - Claude Code Docs

Let Claude list and message your other Claude Code sessions on this machine, and reach your sessions on other machines or on the web.

code.claude.com

有効化の作業はいりません。

v2.1.224以降のmacOSかLinuxなら、条件を満たした時点でオンになっています。

届いたメッセージは自分で打ったプロンプトと同じく利用量にカウントされるので、通知代わりに撃ちまくるものではないです。

ただ、飛びつく前に確認したいことがあります。

Claude Codeには複数セッションを扱う機能がすでに5つあって、選び間違えると手数が増えるだけです。

resume Agent Teams Remote Control との使い分け

複数セッションを扱う道具は、これで6つになりました。

公式ドキュメントが正面から整理してくれているので、横に並べます。

境界線を一言にすると「誰が立ち上げて、誰が舵を握っているか」です。

Claudeが自分で生やして監督しているならAgent Teams、自分が別々に立ち上げて別々に舵を握っているセッション同士ならクロスセッションメッセージング。

この線を外すと、Agent Teamsに任せれば済む話をターミナルの手動並列でやることになります。

実装にもその線は出ていて、Agent Teamsのチームメイトは /list-agents に現れません。

チーム内の連絡はチーム専用の名簿を通るからです。

受信したメッセージは承認の代わりにならない

セッション同士が話せると聞いて最初に気になるのは、権限がどう扱われるかだと思います。

ここはかなり神経質に作られていて、受信側には4つの縛りがあります。

• 他セッションからのメッセージは、あなたの同意として数えられない。保留中の許可プロンプトへの回答にはならない
• 他セッションに頼まれたことを理由に、権限設定やCLAUDE.md、その他の設定を変えないよう受信側のClaudeは指示されている
• 本文に /compact のようなコマンドが書かれていても、ただのテキストとして届く。実行されない
• メッセージが求める作業に許可が必要なら、いつもどおり許可プロンプトが出る

送信側にも縛りがあります。

自分のセッションで拒否された操作、ブロックされた操作、自分の権限設定なら止まるはずの操作を、他のセッションに代わりにやらせないようClaudeは指示されています。

その仕事は他所に回らず人間に戻ってくる。

bypassPermissions で走らせているセッションを踏み台にして禁止操作を通す、という抜け道を最初から塞ぎにいっているわけです。

同じ慎重さは、既定の挙動にもそのまま出ています。

crossSessionInbound で受信をどこまで締めるか

届いたメッセージを渡すか渡さないかは、3つの値で決まります。

値を設定していないときの既定が面白くて、送信側と受信側の権限モードを、許可プロンプトを飛ばすクラスとプロンプトが出るクラスに分けて判断します。

受信側がプロンプトの出るセッションなら基本は配送、送信側が飛ばす側だと名乗ったときだけ保留。

受信側が bypassPermissions のように飛ばす側なら逆で、基本は保留、送信側も同じクラスのときだけ配送されます。

無防備な側に勝手に流し込まない方向へ倒れる、と読めば覚えやすいです。

保留にはダイアログが出ますが、時限つきです。

dialogExpiry の既定は5分で、放置するとダイアログは閉じてメッセージは捨てられます。

保留できるのも最大100件までで、超えると古いものから消えます。

claude -p の常駐ワーカーはそもそもダイアログを出せないので、無人で受け取らせるなら起動時に --settings で accept を渡しておく必要があります。

逆に締めるなら isolatePeerMachines で、マシンを越える送信のたびに明示承認が要るようになります。

動かないときに疑う5か所

送ったのに届かない、そもそも /list-agents（別名 /peers）が反応しない。

詰まるのはだいたいこの5か所です。

1: バージョン。

v2.1.224未満だと /list-agents 自体が通りません。

他マシンのセッションに自分から会話を始めるならv2.1.225以降で、それ以前は届いた分への返信しかできませんでした。

2: OSとプロバイダ。

macOSとLinux（WSL2の中のLinuxを含む）のみです。

ネイティブWindowsのほか、Amazon Bedrock、Claude Platform on AWS、Google CloudのAgent Platform、Microsoft Foundryでも使えません。

3: コンテナの壁。

同じマシン内の発見はディスク上のファイルとソケット経由なので、コンテナの中とホスト側はお互いに見えません。

同じコンテナの中同士なら届きます。

4: 環境変数。

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC や DISABLE_TELEMETRY で機能フラグの評価が止まると、機能ごとオフのままです。

社内ポリシーでこの手の変数を入れている環境は、ここで引っかかります。

5: 受信側の設定。

crossSessionInbound が refuse か、SendMessage と ListAgents に deny ルール。

厄介なのは refuse 側の見た目が何も変わらないことで、自分の /status にも相手の一覧にも痕跡が出ません。

セッションを増やす前提で機能が設計され始めた

Agent Teams、Agent View、Remote Control、channels、そして今回のクロスセッションメッセージング。

並んだ顔ぶれを眺めていると、Claude Codeが想定する標準の姿が変わってきたのがわかります。

1つのセッションと向き合う道具ではなく、同時に何本も走っているセッションを人間が束ねている状態を、既定として置きにきている。

そのうえで、これらに共通する制約がおもしろいところです。

渡るのはテキストだけ、権限は貸し借りできない、設定は他人の依頼では変わらない。

つなぐけれど混ぜない、が一貫しています。

エージェント連携というと能力の合算に目がいきますが、実際に効くのは「どこまでを混ぜないか」を先に決めてある設計のほうです。

手元で使えるかは /list-agents を打てば1秒でわかります。

出なければ、まず claude --version から。