私は日常、AI コーディングセッションをいくつも同時に開いています。Claude Code が機能を書き、Codex が review をし、Pi が雑用をこなす。それぞれはかなり有能なのですが、問題は互いが見えていないことです。Codex に Claude がさっき書いた diff を見てもらいたいだけなのに、私がコピーし、画面を切り替え、ペーストし、さらに返答を戻すしかない——人間が 2 つの AI のあいだのクリップボードになっていました。
Claude Code と Codex には、実はどちらも標準のクロスセッション機能があります。ただし、それぞれの製品の内部でしか有効ではなく、製品の境界で止まってしまいます。そこで私は ocs（Open Cross-session） を書きました。単一ファイルのバイナリで、Claude Code、Codex、Pi、そしてターミナル内の agent が互いにメッセージを送り、互いに起こし合えるようにします。サーバーもアカウントも不要で、データはすべて手元の ~/.ocs にあります。
使うとどんな感じか
インストールしたあと、どれか 1 つのセッションに「この部分を見てくれる agent を探して」と言うだけで、自分で仲間を探しに行きます。手動でもとても簡単です。
ocs who # このマシンで生きているセッション一覧
ocs dm codex-01a06a98 "この diff をレビューして" # Codex に送り、起こす
ocs rename reviewer # 現在のセッションに覚えやすい名前を付ける
ocs send dev "進捗どう？@reviewer" # 複数人チャンネル。@ した相手を起こす
相手が受け取るのは「ファイルに 1 行増えた」というものではなく、セッション内に直接メッセージが現れます。末尾には、そのまま使える返信コマンドも付きます。
[ocs wake] claude-7043ea85 が #dm-… であなたにメンションしました（seq 7）
この diff をレビューして
返信：ocs dm claude-7043ea85 "<your reply>"
スレッド：ocs read dm-…
相手がそのとおりに返信すると、こちらのセッションも起こされます。2 つの agent はこうして往復で会話し、あなたは横で ocs watch していれば十分です。
0.6：PC をまたぐ
最新の 0.6 では、これを LAN に広げました。私の家には Mac と Windows が 1 台ずつあります。いまでは Mac 上の Claude が、「Windows でビルドを走らせて」という作業を Windows 上の Claude や Codex に直接渡せます。
# マシン A # マシン B
ocs lan up ocs lan up
ocs lan pair # ペアリングコードを表示 → ocs lan pair 7K2M-9QXD-…
ocs dm claude-1a2b3c4d@mini "Windows でビルドを走らせて"
知らないマシンがあなたの AI セッションにメッセージを差し込めるようにするなら、安全性は最初に考える必要があります。なので、この部分は「LAN 内に悪意ある人がいる」ことを前提に設計しています。
- 身元は公開鍵だけを信じる：各マシンに Ed25519 鍵を 1 つ。IP、マシン名、相手が自分で名乗る名前は、すべてヒントとしてしか扱いません。
- ペアリングは一度だけ。「初回接続を信頼」はしない：ペアリングコードには、発行側の公開鍵フィンガープリントの接頭辞が入っています。接続後、まず相手の公開鍵を照合し、通った場合だけ自分の身元とリクエストを送ります。
- 双方向認証、全区間暗号化：署名付き X25519 ハンドシェイク + AES-256-GCM で、前方秘匿性があります。
- 未ペアリングのマシンは何もできない：有効なペアリングコードを引き換える以外、すべてのリクエストを拒否します。フレームサイズも 1 KiB に制限し、ペアリングコードは 5 回間違えると無効になります。
- デフォルトではオフ：
ocs lan upして初めて有効になります。リモートから届いたメッセージは、ローカルでは必ず名前@あなたが付けたラベルとして表示され、相手はこれを変更できません。
踏んだ落とし穴：「成功」は届いたことを意味しない
メッセージシステムを作るうえで一番危険なのは、エラーではありません。成功に見えるのに、実は失われていることです。ocs のいくつもの鉄則は、そこから生まれました。
1. Claude が ok を返しても、メッセージが会話に入ったとは限らない。 Claude Code セッションにメッセージを注入すると、socket の向こう側は ok:true を返します。しかし Claude の crossSessionInbound はデフォルトで hold です。メッセージは審査待ちキューに入り、5 分間だれも処理しないと静かに破棄されます。そのため ocs は、この ok を「配信済み」として扱いません。ocs doctor がこの項目をチェックし、accept に変更するよう案内します。
2. codex queue は保存であって、配信ではない。 ターミナル内の Codex には、公式の codex queue を使ってメッセージを入れるしかありません。ただしこれは、メッセージを thread ストレージに書き込むだけです。対象セッションがすでに終了していても、同じように成功を返します。ocs のやり方は、送る前にセッションがまだ生きていることを証明することです。lsof で、その rollout ファイルを保持しているプロセスを探します。後になって、インデックス系のサードパーティープロセスもこれらのファイルを保持することがあるとわかりました。そこでさらに身元確認を追加しました。保持者自身、またはその祖先プロセスが本当に codex でなければ、オンラインとは見なさず、メッセージは相手がオンラインになるまで inbox に残します。
3. 結果が不明なら、絶対に再送しない。 ChatGPT Desktop との通信は、その private IPC を通ります。フレームはすでに書き出されたが、応答を待つ前に止まった場合、メッセージは届いたかもしれないし、届いていないかもしれません。このとき再送すると、最悪の場合、相手は同じ指示を 2 回受け取り、作業も 2 回行います。ocs は「結果不明」を一級の状態として個別に報告し（終了コード 3）、決して自動リトライしません。人間または上位レイヤーが判断できるようにします。
4. シーケンス番号の真の情報源は 1 つだけ。 各メッセージには単調増加する seq があります。初期バージョンでは「現在の seq」を別ファイルにも保存していました。その結果、「ログの書き込みは終わったが、seq ファイルはまだ更新されていない」タイミングでクラッシュすると、再起動後に重複 seq が発行されました。読み取り側は seq で重複排除するため、後から来たメッセージが永久に隠されてしまいました。現在の seq はログそのものからだけ推定します（ロックを取ってログ末尾を読む）。この問題は回帰テストで固定されています。
これらの落とし穴は、1 つずつ見れば難しくありません。難しいのは、通常のテストではどれも全部グリーンになることです。
インストール
# 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 の skill もあわせて入れます。インストール後は ocs doctor --fix を一度実行して診断します。macOS、Linux、Windows に対応し、MIT オープンソースです。
もしあなたの利用シーンが 1 つの LAN を超える場合——異なるネットワーク、チーム共同作業、組織をまたぐ利用など——同じ使い方を Agent Party に移せます。ホスティングにも、private deployment にも対応しています。
- GitHub：leeguooooo/open-cross-session
- プロトコルと脅威モデル：docs/lan.md
問題やアイデアがあれば、GitHub で issue を立てるか、下にコメントしてください。
作者：郭立（leeguoo）。フルスタックエンジニアで、最近は AI agent が本当に仕事をこなせるようにするツール群を作っています。chrome-use、iphone-use、mail-use など。
WeChat Pay
Alipay
コメント
コメントは即時公開されますが、ポリシー違反時は非表示になる場合があります。