# Claude Code と Codex はどう連携できるのか？互いを起こし、メッセージを送り、別々のコンピューター間でも作業できるツールを作った

私はふだん、いくつもの AI コーディングセッションを同時どうじに開ひらいたままにしています。機能きのうを書かく Claude Code セッション、レビューをする Codex セッション、そしてさまざまなタスクを実行じっこうする Pi セッションです。それぞれは単体たんたいでもかなり有能ゆうのうです。問題もんだいは、これらが**互たがいを見みられない**ことです。Claude が書かいたばかりの diff を Codex に見みてもらいたいとき、私は自分じぶんでそれをコピーし、ウィンドウを切きり替かえ、ペーストし、さらに返答へんとうを持もち帰かえらなければなりません。つまり、人間にんげんが 2 つの AI の間あいだのクリップボードになってしまうのです。

Claude Code と Codex には、どちらにも実じつはネイティブのクロスセッション機能きのうがあります。しかし、それらはそれぞれの製品せいひんの内部ないぶでしか動うごかず、製品せいひんの境界きょうかいで止とまってしまいます。そこで私は ocs (Open Cross-session) を作つくりました。これは、Claude Code、Codex、Pi、そしてターミナルエージェントが互たがいにメッセージを送おくり、互たがいを起おこせるようにする単一たんいつファイルのバイナリです。サーバーも、アカウントも不要ふようで、すべてのデータはローカルの ~/.ocs に残のこります。

実際じっさいに使つかうとどう見みえるか

インストール後ごは、どのセッションにも「これを見みるのを手伝てつだってくれるエージェントを探さがして」と言いえば、自分じぶんで相棒あいぼうを探さがしに行いきます。手動しゅどうで使つかうのも簡単かんたんです。

ocs who                                   # このマシンで<ruby>動作中<rt>どうさちゅう</rt></ruby>のセッションはどれか
ocs dm codex-01a06a98 "Help me review this diff"   # Codex に<ruby>送<rt>おく</rt></ruby>って<ruby>起<rt>お</rt></ruby>こす
ocs rename reviewer                       # <ruby>現在<rt>げんざい</rt></ruby>のセッションに<ruby>覚<rt>おぼ</rt></ruby>えやすい<ruby>名前<rt>なまえ</rt></ruby>を<ruby>付<rt>つ</rt></ruby>ける
ocs send dev "How’s progress? @reviewer"          # <ruby>複数参加<rt>ふくすうさんか</rt></ruby>のチャンネル。@ された<ruby>相手<rt>あいて</rt></ruby>が<ruby>起<rt>お</rt></ruby>こされる

相手側あいてがわが受うけ取とるのは「ファイルにもう1行ぎょう追加ついかされた」ものではなく、セッションの中なかに直接ちょくせつ現あらわれるメッセージで、最後さいごにはそのまま使つかえる返信へんしんコマンドが付ついています。

[ocs wakeup] claude-7043ea85 mentioned you in #dm-… (seq 7)

Help me review this diff

Reply: ocs dm claude-7043ea85 "<your reply>"
Thread: ocs read dm-…

その返信へんしんコマンドに従したがうと、こちら側がわが起おこされます。2つのエージェントはこのように行いったり来きたりチャットでき、あなたは ocs watch で横よこから見守みまもれます。

0.6: コンピューター間かんで

最新さいしんの 0.6 では、これがローカルネットワークまで拡張かくちょうされました。私わたしの家いえには Mac と Windows マシンが 1 台だいずつあり、いまでは Mac 上じょうの Claude が、Windows マシン上じょうの Claude や Codex に「Windows でビルドを実行じっこうして」を直接ちょくせつ引ひき渡わたせます。

# Machine A                       # Machine B
ocs lan up                       ocs lan up
ocs lan pair   # pairing code を表示  →   ocs lan pair 7K2M-9QXD-…
                                 ocs dm claude-1a2b3c4d@mini "Help me run the build on Windows"

見知みしらぬマシンがあなたの AI セッションにメッセージを注入ちゅうにゅうできるようにするということは、セキュリティを最初さいしょから考慮こうりょする必要ひつようがあるということです。そのため、この部分ぶぶんは「ローカルネットワーク上じょうに悪意あくいある存在そんざいがいるかもしれない」という前提ぜんていで設計せっけいされています。

• 同一性どういつせいは公開鍵こうかいかぎだけに基もとづく: それぞれのマシンは Ed25519 鍵かぎを 1 つ持もちます。IP アドレス、マシン名めい、相手あいてが自称じしょうする名前なまえは、ヒントとしてしか扱あつかわれません。
• 「初回しょかい使用時しようじに信頼しんらい」はせず、1 度どだけペアリングする: ペアリングコードには、発行者はっこうしゃの公開鍵こうかいかぎフィンガープリントのプレフィックスが含ふくまれます。接続後せつぞくご、まずピアの公開鍵こうかいかぎがチェックされ、それに通とおってからはじめて、そのマシンは自身じしんの同一性どういつせいとリクエストを送おくります。
• 相互そうご認証にんしょうと暗号化あんごうかを全体ぜんたいで行おこなう: 署名付しょめいつき X25519 ハンドシェイク + AES-256-GCM、さらに前方ぜんぽう秘匿性ひとくせいつきです。
• ペアリングされていないマシンは何なにもできない: 有効ゆうこうなペアリングコードを引ひき換かえることを除のぞき、ほかのリクエストはすべて拒否きょひされ、フレームサイズでさえ 1 KiB に制限せいげんされます。ペアリングコードは 5 回かい間違まちがえると無効化むこうかされます。
• デフォルトではオフ: ocs lan up を実行じっこうしたときだけ起動きどうします。リモートマシンからのメッセージは、常つねにローカルでは name@the-label-you-gave-it として表示ひょうじされ、このラベルは相手側あいてがわからは変更へんこうできません。

落とし穴: 「成功」は配達はいたつされたことを意味いみしない

メッセージングシステムを作つくるとき、もっとも危険きけんなのはエラーではありません。実際じっさいにはメッセージを失うしなっているのに、成功したように見みえることです。ocs のいくつかの厳格げんかくなルールは、まさにここから生うまれました。

1. Claude が ok を返かえしても、メッセージが会話かいわに入はいったとは限かぎりません。 Claude Code セッションにメッセージを注入ちゅうにゅうすると、ソケットは ok:true を返かえします。しかし Claude の crossSessionInbound はデフォルトで hold です。つまりメッセージはレビューキューに入はいり、誰だれも処理しょりしなければ 5 分後ふんごに無言むごんで破棄はきされます。そのため ocs は、この ok を「配達済はいたつずみ」とは扱あつかいません。ocs doctor はこの設定せっていをチェックし、accept に変更へんこうするよう案内あんないします。

2. codex queue はストレージに書かき込こむだけで、配達はいたつではありません。 Terminal Codex は公式こうしきの codex queue 経由けいゆでしかメッセージを受うけ取とれませんが、それはメッセージをスレッドストレージに書かき込こむだけです。対象たいしょうセッションがずっと前まえに終了しゅうりょうしていても、成功を返かえします。ocs は送信前そうしんまえに、まずセッションが生いきていることを証明しょうめいします。そのロールアウトファイルを保持ほじしているプロセスを lsof で見みつけます。後あとになって、インデックス関連かんれんの一部いちぶのサードパーティプロセスもこれらのファイルを保持ほじできることが分わかったため、もう一ひとつの身元確認みもとかくにんを追加ついかしました。保持者自身じしん、またはその祖先そせんプロセスのどれかが実際じっさいに codex でなければ、オフラインとして扱あつかわれ、メッセージはオンラインになるまで inbox に残のこります。

3. 結果けっかが不明ふめいなら、絶対ぜったいに再送さいそうしません。 ChatGPT Desktop との通信つうしんは、そのプライベート IPC を通とおります。フレームがすでに書かき込こまれたのに応答おうとうが届とどかない場合ばあい、メッセージは届とどいたかもしれませんし、届いていないかもしれません。その時点じてんで再送さいそうすると、最悪さいあくのケースでは、相手側あいてがわが同一どういつの指示しじを 2 回かい受うけ取とり、作業さぎょうを 2 回かい実行じっこうします。ocs は「結果不明けっかふめい」を一級いっきゅうの状態じょうたいとして扱あつかい、別べつに報告ほうこくします（終了コード 3）。自動じどうで再試行さいしこうすることは決けっしてなく、判断はんだんは人間にんげん、または上位じょういレイヤーに委ゆだねます。

4. シーケンス番号ばんごうの信頼しんらいできる唯一ゆいいつの情報源じょうほうげんは、必ず 1 つだけでなければなりません。 各メッセージには、単調増加たんちょうぞうかする seq があります。初期しょきバージョンでは「現在げんざいの seq」を別べつファイルに保存ほぞんしていました。その後あと、「ログ書がき込こみ完了かんりょう」と「seq ファイルはまだ更新こうしんされていない」の間あいだにクラッシュが 1 回かい発生はっせいし、再起動後さいきどうごに重複ちょうふくした seq が送おくられました。リーダーは seq で重複排除ちょうふくはいじょしたため、後続こうぞくのメッセージが永久えいきゅうに隠かくされてしまいました。現在げんざいでは、seq はロック下かでログ末尾を読よみ取とることにより、ログそのものだけから導出どうしゅつされます。そしてこの問題もんだいはリグレッションテストで固定こていされています。

これらの落とし穴は、それぞれ単独たんどくでは難むずかしくありません。難むずかしいのは、それらがすべて通常つうじょうのテストを通とおってしまうことです。

インストール

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/leeguooooo/open-cross-session/main/install.sh | sh

# Windows (PowerShell)
irm https://raw.githubusercontent.com/leeguooooo/open-cross-session/main/install.ps1 | iex

インストーラーは、Claude Code、Codex、Pi 向むけの ocs スキルもインストールします。インストール後ご、ヘルスチェックのために ocs doctor --fix を 1 回かい実行じっこうしてください。macOS、Linux、Windows をサポートしており、MIT のもとでオープンソースとして公開こうかいされています。

あなたのユースケースが 1 つのローカルネットワークを超こえる場合ばあい——異ことなるネットワーク、チームでの共同作業きょうどうさぎょう、または組織間そしきかんの作業さぎょう——でも、同おなじ利用りようモデルを Agent Party に移うつせます。Agent Party はホスト型とプライベートデプロイの両方りょうほうをサポートしています。

• GitHub: leeguooooo/open-cross-session
• プロトコルと脅威きょういモデル: docs/lan.md

質問しつもんやアイデアがあれば、GitHub で issue を開ひらくか、下したにコメントを残のこしてください。

著者ちょしゃ: Guo Li (leeguoo)、フルスタックエンジニア。最近さいきんは、AI エージェントが実際じっさいに仕事しごとを完了かんりょうできるよう支援しえんする一連のツールを構築こうちくしています: chrome-use、iphone-use、mail-use など。