一方向にしか通らないと思った通信の正体は、7秒の起動レースだった

Claude Codeでクロスセッション通信を試した。別々に起動したセッション同士でメッセージを送る機能だ。片方は仕事記録用、もう片方はアプリ開発用。相手を見つけて送信すると、success: trueが返り、実際に届いた。ここで「双方向で動く」と結論を出した。それが間違いだった。「送れた」と「往復する」は別物だ。相手から返信を送ると、リモートコントロール扱いで返信だけが許可される、と言われた。こちらが先に送っているのに、返信条件を満たしていないと拒否される。登録ファイルを並べて比較すると、答えが見えた。受信用のUNIXドメインソケットを、こちらのセッションだけ持っていなかった。

タイムスタンプを見ると全貌が出た。7秒早く起動したこちらは、ソケットの置き場所がないまま起動を完了した。後から起動した相手が、ディレクトリを作成し、その中に自分のソケットを作った。先に起動したほうが負ける競合だ。受信ソケットがないから、送信メッセージに返信先の情報が乗らない。相手は返信先が分からないので、一覧の表示名で送ろうとする。その名前は別の宛先空間に解決され、ブロックされる。ドキュメントが実物と違うのではなく、送信元がソケットを持たないことの結果だ。

ここからの持ち帰りは3つ。success: trueは片道の証明であって、往路と復路は別の実験として試すこと。一覧に出ているのに送れない宛先がある。これは理由を問わず起きる。推測を重ねるより、両方の現物を並べて差分を取るほうが速いこと。自分の仮説が守りに入っているときほど、外からの素朴な疑問が当たっていた。複数セッションを同時に使う運用では、起動タイミングで予期しない通信エラーが出ることがある。そのときは設定を疑う前に、ソケットファイルの実在を確認することから始めるべきだ。