Claude Code のセッション間通信は Windows では受信専用になる

開発claude-code-tools

Claude Code のセッション間通信は Windows では受信専用になる

Claude Code v2.1.224 から、別々に立ち上げたセッション同士がメッセージを送り合えるようになった。 これを macOS 機と Windows 機の2台で試したところ、片方向しか通らなかった。 2026-08-09 に実測した記録を残す。両機とも v2.1.226 である。

結論

  • macOS 機から Windows 機への送信は成功し、メッセージは実際に届いた。逆方向は送れない
  • Windows 側は同一マシン内の別セッション宛でも送信できない。宛先名の誤りではなく、機能そのものが提供されていない
  • 受信だけが通るのは非対称なバグではない。送信と受信で経路が違うためである
  • Windows からの返信は、Chrome DevTools MCP でブラウザを操作し、claude.ai に開いた macOS セッションの入力欄へ流し込んで送った。機能としての迂回路が見つかったわけではない

検証した2台

macOS 機Windows 機
OSDarwin（macOS）ネイティブ Windows 11。Git Bash（MINGW64_NT-10.0-26200）で、WSL ではない
作業ディレクトリ/Users/keikomatsu/git_repo/mdx-playgroundC:\Users\numbe\Git_repo\mdx-playground
ListAgents ツールあり。ピアセッションを390件列挙した存在しない。0件ではなく、ツールが提供されていない
CLAUDE_CODE_MESSAGING_SOCKET/tmp/cc-socks/66536.sock（srw------- で実在を確認）空。inbox socket を bind していない

この表のうち、後半2行が結果を分けている。 どちらも Windows 側に無い。

Mac から Windows へは届いた

macOS 側の SendMessage は success: true を返し、メッセージは Windows 側のセッションに到達した。 受信側から見ると、送信元は bridge: で始まる識別子になっていた。 この接頭辞が、配送経路が Remote Control であることを示している。

macOS 側は ListAgents で Windows 側のセッションを名前で認識していた。 390件のピアセッションが列挙され、そのなかから宛先を名前で指定して送っている。

Windows から Mac へは送れない

逆方向は2種類のエラーで失敗した。 どちらも message に本文を入れて送っており、本文が空だったわけではない。

宛先に bridge: を付けずに指定した場合は、セッションID、画面上の表示名、macOS 側のセッション名のいずれでも同じエラーになる。

No agent named '...' is reachable.
Check the spelling, or use the agent ID from a background agent's spawn result.

受信したメッセージの送信元をそのままコピーし、bridge: 付きで返信した場合は文言が変わる。

Cross-session messaging is not available in this session.

後者が原因を直接示している。 宛先としては正しく解釈されたうえで、このセッションでは機能が使えないと拒まれている。

同一マシン内でも送れない

マシンをまたぐことが原因ではない。 同じ Windows 機の上で claude --bg -n crosstest を起動した。 このセッションは claude agents --json の一覧にも表示される。 そこへ送っても結果は同じだった。

No agent named 'crosstest' is reachable.

つまり Windows 側では、マシンをまたぐ以前に、同一マシン内の送信すら通らない。 宛先名の書き方を変えても解決しない。

受信だけ通る理由

送信と受信で経路が違う。

受信は Remote Control の接続に乗って届く。 Anthropic のサーバーを経由して、そのマシンの Remote Control 接続へ配送される仕組みなので、Windows 側も宛先になれる。

送信と一覧取得は、ローカルの Unix ドメインソケットを前提としている。 各セッションは自分の受信口となるソケットを bind し、そのパスを CLAUDE_CODE_MESSAGING_SOCKET に出す。 同じマシンのセッション同士は、このソケットを通じて直接やりとりする。 Anthropic のサーバーは経由しない。

Windows 側でこの環境変数が空だったのは、ソケットを bind していないからである。 成立しない前提の上に送信機能が乗っているので、送信も一覧取得もできない。 結果として、受信だけができる状態になる。

復路はどうやって届いたのか

今回の往復は、行きと帰りでまったく別の経路を通っている。 ここを分けないと、機能が使えないのにメッセージが届いた理由が見えない。

行きは機能そのものが動いた。 ドキュメントの配送経路の表には、宛先が別マシンの場合の行がこう書かれている。

Where the other session runsHow the message travelsWhat Claude here can send
On another of your machinesThrough Anthropic servers, arriving over that machine's Remote Control connectionReplies only

Anthropic のサーバーを経由し、その機の Remote Control 接続に乗って届く。 Windows 側が受け取ったメッセージの送信元が bridge: 接頭辞だったのは、この経路を通った表れである。 受信に必要なのはローカルのソケットではなく Remote Control 接続なので、ネイティブ Windows でも受信は成立する。

帰りは機能を一切使っていない。 Windows 側の SendMessage は失敗したままである。 内容が macOS 側へ届いたのは、ブラウザを操作するという別の手を使ったからだ。

具体的にはこう運んだ。

  1. Windows 側の Claude Code が Chrome DevTools MCP 経由で、ユーザーのログイン済み Chrome に接続する
  2. macOS セッションのページ（https://claude.ai/code/session_<セッションID>）を新しいタブで開く
  3. ページ下部のプロンプト入力欄に、返信の本文を流し込む
  4. 送信ボタンを押す

macOS 側から見ると、これは Claude Code から届いたメッセージではない。 ユーザーが画面から打ち込んだプロンプトとして届く。 セッション間メッセージングの通知としては表示されないので、受信側は誰が書いたのかを本文から判断することになる。

手順3と手順4のあいだには実務上の引っかかりがある。 入力欄にテキストを入れただけでは、送信ボタンが押せる状態にならなかった。 DevTools の入力操作は DOM の値を書き換えるが、ページ側のエディタがその変更を検知しないことがある。 今回は送信ボタンの要素を直接取得し、click() を呼んで送信した。

この迂回が成立する前提は2つある。 macOS セッションが Remote Control で claude.ai につながっていて、その画面をブラウザから開けること。 そして Windows 側がそのブラウザを操作できること。 どちらも Claude Code のセッション間メッセージングとは無関係の条件であり、たまたま両方が揃っていたにすぎない。

人が画面を見て手で貼り付けても結果は同じである。 自動化されているのは文字を入力して送信ボタンを押す部分だけで、何を運ぶかの判断は毎回発生する。 Claude Code の機能として往復しているわけではない。

公式ドキュメントの記述

この挙動は仕様として明記されている。

  • セッション間メッセージングは v2.1.224 以降が必要で、macOS と Linux で動作する。ネイティブ Windows は対象外
  • WSL 2 の中の Linux は Linux として扱われる
  • マシンをまたぐメッセージは Remote Control 経由で運ばれる。API キー認証では対応しない

Claude Code 公式ドキュメント: Message your other Claude Code sessions

Claude Code 公式ドキュメント: Feature availability

ドキュメントの記述と実測が食い違った点

同じドキュメントには、マシンをまたぐ場合の制約として次の記述がある。

Across machines, Claude can only reply. It can't start the exchange.

別マシンのセッションに対してできるのは返信だけで、会話を開始することはできない、と読める。

ところが今回、macOS 側から送った1通目は返信ではなかった。 macOS 側に先行する受信メッセージは無く、ユーザーの依頼を受けて新しく送ったものである。 それが Windows 側に届き、受信も確認できている。

この食い違いをどう理解すべきかは、まだ判断がつかない。 配送の仕組みとして強制されているのではなく、Claude に与えられた指示として機能している制約なのかもしれない。 ただしこれは推測である。 試したのは1方向かつ少数回で、条件を変えた検証はしていない。

機能の有無を切り分けるコマンド

自分の環境で使えるかどうかは、2つのコマンドで判定できる。

/list-agents（別名 /peers）を打つ。

  • コマンド自体が認識されない場合、そのセッションにはセッション間メッセージング機能が無い。今回の Windows がこれに当たる
  • 一覧は出るのに送信が届かない場合、機能自体はある。もっと狭い原因を疑う。SendMessage と ListAgents の deny ルール、受信側の crossSessionInbound による保留や拒否、別マシン宛の返信専用制約などである

/status を打つと、Peer address 行にそのセッション自身の受信アドレスが uds: 接頭辞付きで出る。 機能が有効なセッションにしか表示されない。

設定で止める場合、受信と送信は別々の制御になる。 受信を止めるのは crossSessionInbound で、accept、hold、refuse の3値をとる。 送信と一覧取得を止めるのは SendMessage と ListAgents の deny ルールである。 今回のようなプラットフォーム由来の非対称と設定による非対称は原因が違うので、切り分けるときは混ぜないほうがよい。

2台運用でどう回すか

選択肢は3つある。

現状の形をそのまま使う。 macOS 側から発信し、Windows 側の返答は claude.ai の画面を経由して運ぶ。 追加設定は要らない代わりに、返信のたびに Windows セッションの出力を macOS セッションの入力欄へ貼り付ける操作が入る。 往路は機能が自動で運ぶが、復路は毎回この手当てが必要になる。

Windows 側を WSL 2 で動かす。 ドキュメント上は Linux 扱いなので、双方向が通るはずである。 ただしリポジトリが C:\ にあると /mnt/c/... 経由のアクセスになり、I/O が遅くなる。 改行コードや core.hooksPath の扱いで別の手当てが要る可能性もある。 この懸念はまだ検証していない。

macOS 側を常に発信側に固定する。 2台運用との相性はこれが一番よい。 発信を片側に寄せてしまえば、返信できない制約が問題にならない場面が多い。

補足: 原因を誤診していた

macOS 側は当初、この失敗を SendMessage の message が必須パラメータであることに結びつけ、本文が空だから弾かれたのだろうと推測していた。 実際には本文は毎回入っており、原因はプラットフォーム制限だった。 Windows 側からエラー文言をそのまま報告したことで訂正された。

エラーの文言が2種類あったことが切り分けの手がかりになっている。 bridge: の有無でメッセージが変わったので、宛先解決の失敗と機能の不在を区別できた。

#Claude Code#セッション間通信 #Windows#Remote Control#WSL