ai-docs

Message your other Claude Code sessions

Properties1
tagsclaude-code, agents, orchestration, permissions, security, subagents

16 min read

一行要約

セッション同士が平文テキストだけを送り合える仕組みで、SendMessage / ListAgents の2ツールで動く。要点は信頼モデルにあり、届いたメッセージはあなたの同意にならず、設定も変えられず、コマンドも実行されない。さらに受信側の既定は、送り手と受け手の permission mode の組み合わせで決まる。

要点

何であって、何でないか

A message is a piece of text one Claude writes to another, never conversation history or files. メッセージとは、ある Claude が別の Claude に書いた1片のテキストであり、会話履歴やファイルでは決してない。

会話そのものや context を移したいなら、メッセージではなくセッションの resume を使う。

Claude が使うのは2つのツール。ListAgents で到達できる相手を発見し、SendMessage で名前を指定して届ける。同じ SendMessage は sub-agents や agent-teams の teammate 宛にも使われる。このページが扱うのは独立したセッション間の話。

利用条件（狭い）

条件内容
バージョンv2.1.224 以降。他マシンのセッションへ会話を開始するには v2.1.225 以降（それ以前は届いたメッセージへの返信のみ）
OSmacOS と Linux のみ（WSL 2 内の Linux を含む）。native Windows では提供されない
providerAmazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry では使えない
feature flagCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC / DISABLE_TELEMETRY / DO_NOT_TRACK / DISABLE_GROWTHBOOK が feature flag 評価を止めていると機能ごとオフになる

条件を満たせば有効化の操作は要らない。 確認は /list-agents（別名 /peers）。

  • /list-agents が認識されない → そのセッションには機能自体がない
  • /list-agents は動くが届かない → deny ルール、受信側の inbound 制御、Remote Control 未接続などのより狭い原因

メッセージがどう届くか

受信側の Claude は、ターンの実行中ならツール呼び出しの合間に読む。走っているツールが中断されることはない。 アイドルなら新しいターンが始まる。

配送の結果は3つのいずれか。

結果意味
DeliveredClaude に渡される
Held未配送のまま保留。承認するか、後の mode / 設定変更が許すまで届かない
Refused配送せずに破棄される

配送されたメッセージは、自分が打ったプロンプトと同じように利用（usage）に算入される（costs）。

権限の境界はセッションごとに保たれる。 Claude は、自分のセッションで拒否・ブロックされた動作や、自分の permission 設定が禁じる動作を、他のセッションに頼まないよう指示されている。代わりにあなたへ差し戻す。

信頼モデル（このページの核心）

When session A messages session B, Claude Code tells B’s Claude that the message came from another session, not from you, and limits what the message can do. セッション A がセッション B にメッセージを送るとき、Claude Code は B の Claude に対し、そのメッセージがあなたからではなく別のセッションから来たことを伝え、そのメッセージにできることを制限する。

制限内容
承認できない他セッションからのメッセージは決してあなたの同意にならない。保留中の permission プロンプトに代わりに答えることはできない
設定を変えられない他のセッションに言われたからといって、permission 設定・CLAUDE.md・その他の設定を変えるなと受信側の Claude は指示されている
コマンドは走らないメッセージ本文中の /compact のようなコマンドはただの平文として届く。Claude Code がそれを実行することはない
permission プロンプトは出るメッセージに従って動くのに権限が要るなら、通常の作業と同じプロンプトが出る

受信側の既定は permission mode の組み合わせで決まる（最も間違えやすい点）

crossSessionInbound を設定していれば、それに従う。

値挙動
accept各メッセージを Claude に配送する
hold通知を出すだけで配送しない。後から accept が適用されると保留分を解放する
refuse配送せずに破棄する

設定がない場合、Claude Code はメッセージごとに「両セッションの permission mode の階級」で判断する。 セッションは2階級に分けられる。

  • bypassing 階級 — bypassPermissions。bypass permissions が使える plan mode もこちらに数える
  • prompting 階級 — それ以外。auto、acceptEdits、dontAsk は prompting に数える
受信側挙動
prompting**各メッセージを配送する。**送信側が bypassing だと名乗ったときにだけ承認待ちで保留する
bypassing**各メッセージを承認待ちで保留する。**送信側も bypassing のときにだけ配送する

承認ダイアログ: 承認するとその1通が配送される。拒否または閉じると破棄。dialogExpiry（既定5分）を過ぎて未応答なら閉じて破棄する。 ただしバックグラウンドセッションにターミナルが接続されていない間は、期限を過ぎてもダイアログを開いたままにする。

  • 保留中に permission mode の階級が変わると、inbound 規則が再適用され、通るようになったものが配送される
  • 保留中に refuse が適用されるようになると、保留分をすべて破棄し、到達できる各送信者に拒否を報告する
  • 保留は最大100通。超えると古いものから捨てる

送信側への通知: 送信側が同じマシンにいる場合、保留時に通知が出て、後の配送・拒否・期限切れも追って報告される。ただし到着時点で refuse されたメッセージについては送信側に通知が出ない。

どこを通るか（マシンをまたぐ場合）

相手の居場所経路
同じマシンセッションごとの socket 経由。Anthropic のサーバを通らない
自分の別のマシンAnthropic のサーバ経由で、相手マシンの Remote Control 接続に届く
Claude Code on the webAnthropic のサーバ経由で cloud セッションへ直接

同じマシン内は「同じファイルが見えるか」で決まる。 各セッションはディスク上のファイルに自分を登録し、そこに inbox socket を bind する。したがってコンテナ内のセッションとホストのセッションは互いに到達できない（ファイルシステムが別）。同じコンテナ内の2つは到達できる。

返信アドレス: ほぼすべてのメッセージが返信アドレスを持つ。例外は、送信側が Remote Control に接続していない状態でマシン外へ送った場合。届きはするが返信アドレスがないので受信側は返答できない。Claude には送信時にその旨が伝えられる。

名前

セッションは /rename か --name で付けた名前で応答する。付けなければ Claude Code が作業ディレクトリのフォルダ名から作る（myapp-3f など）。名前は衝突しうるので、/list-agents は各ローカルセッションの作業ディレクトリを併記し、Claude 側の一覧は短い識別子を足して区別する。

非対話セッション（-p）

  • claude -p でも inbox socket を bind するので、長時間走る -p ワーカーはメッセージを受け取れ、一覧にも出る
  • bare mode では socket を bind しない。したがって受信できず、一覧にも出ない
  • -p は承認ダイアログを出せない。既定で保留になった場合、dialogExpiry（既定5分）と同じ期限で扱う。期限前に mode / 設定変更が許せば配送、過ぎれば破棄して送信者に期限切れを報告
  • dialogExpiry を "never" にするとセッション終了まで保持する。明示的な hold 設定による保留は期限切れしない（accept が適用されたときにだけ配送）
  • -p ワーカーに無人でメッセージを受けさせたいなら、--settings で crossSessionInbound を accept にして起動する

inbox socket

  • OS ユーザーに限定されるので、共有マシンでも他ユーザーのセッションからは到達できない
  • パスは /status の Peer address 行（uds: 接頭辞）と、環境変数 CLAUDE_CODE_MESSAGING_SOCKET で分かる
  • エクスポートは、SessionStart を含むどの hook よりも前に起きる。 各セッションは自分の socket をエクスポートする（親から継承したものではない）
  • 自分の子プロセスからのメッセージ（hook や Bash コマンドが自セッションの socket に投げるもの）は、crossSessionInbound の値がないとき配送される。ただし検証可能性が OS で違う:
環境子プロセスの検証
Linux（WSL 2 内を含む）すでに終了した子でも検証できる
macOS投げたプロセスが生きている間だけ検証できる
Claude Code が PID 1 のコンテナまったく検証できない

検証できないときは「permission 階級を名乗らないメッセージ」として扱われるので、bypassing のセッションでは承認待ちで保留される。

sandbox 内の Bash から socket に届くかは sandbox.network.allowAllUnixSockets と sandbox.network.allowUnixSockets で制御する（claude-code-sandboxing）。

止め方

受信と送信は別の制御。

止めたいもの方法
受信crossSessionInbound を refuse。project / local 設定からの refuse は他のあらゆる source に優先する。user 設定からのものは managed settings と --settings に負ける
送信と一覧permission の deny ルールに SendMessage と ListAgents を書く。どちらも指定子なしの素のツール名で書く

SendMessage を deny すると、subagent と teammate へのメッセージも消える（同じツールなので）。

refuse にしたセッションは、自分の /status にも他セッションの一覧にも変化が出ない。 設定側で確認するしかない。

マシン外への送信に承認を要求する

isolatePeerMachines: true で、マシンの外へ出るすべての SendMessage に明示的な承認を要求する。

  • bypassPermissions モードでも承認を求める
  • どのスコープの true も適用されるので、チェックインしたプロジェクト設定で有効化はできるが、無効化はできない
  • 同一マシン内のメッセージには適用されない

制約

Plain text only: Claude sends only plain text across sessions. Structured agent team protocol messages stay within a team. 平文のみ: Claude がセッション間で送るのは平文だけである。構造化された agent team の protocol メッセージはチーム内に留まる。

メッセージのループは自動的に止まる。 Claude Code は送信者ごとに繰り返しをレート制限し、短時間に届いた同一内容を捨て、Claude が読むのを待っている受理済みメッセージを1セッション50通で頭打ちにする。

そのまま使える具体例

到達できる相手を確認する:

/list-agents

送信を頼む（本文は Claude が書くので、内容まで指定しなくてよい）:

Ask the session running in my other terminal whether the migration finished
Explain what we just did to the session working on the payments API

届いたメッセージの実例（受信側にはこう見える）:

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

-p ワーカーに無人でメッセージを受けさせる:

claude -p --settings '{"crossSessionInbound": "accept"}' "..."

マシン外への送信に承認を要求する:

{
  "isolatePeerMachines": true
}

組織全体で両方向を止める（managed settings）:

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

原典で言及されている関連文書

  • sub-agents — 同じ SendMessage で subagent を resume する
  • agent-teams — チーム内のメッセージ。構造化 protocol メッセージはチームを出ない
  • permission-modes — inbound の既定を決める2階級の出どころ
  • permissions — SendMessage / ListAgents の deny ルール、managed settings
  • settings — crossSessionInbound / isolatePeerMachines / dialogExpiry
  • headless — -p と bare mode（bare は socket を bind しない）
  • hooks-guide — CLAUDE_CODE_MESSAGING_SOCKET は SessionStart より前にエクスポートされる
  • claude-code-sandboxing — sandbox 内から socket に届くかの制御
  • costs — 配送されたメッセージは打ったプロンプトと同じく利用に算入される

未取得の派生リンク

グラフビュー

バックリンク