Claude Code と Codex ペイン間のメッセージング

同じ renga セッションに並べた Claude Code と Codex のペインが、renga-peers を通じて直接メッセージを送り合える機能です (Issue #289 以降はタブをまたいで届きます)。片方のエージェントにちょっとした調査を頼んだり、失敗したテストの続きをもう片方に引き継いだりを、ユーザーが手でコピペしなくても進められるようになります。

Claude 側は <channel source="renga-peers">...</channel> タグで受信するので、ユーザー入力と区別できます。Codex 側も pane layer で扱いますが、renga が PTY 経由で流し込むのは check_messages を促す one-shot nudge だけで、実際の依頼本文は MCP inbox に残します。

スコープは「renga セッション」単位

claude-peers-mcp は cwd / git_root / PID の組み合わせからペアを推測しますが、renga-peers は 「ユーザーがこの renga インスタンスに置いた」という物理配置 そのもの (全タブ横断) をスコープの拠り所にします。推測に頼らないので、同じディレクトリを複数案件で開いていても取り違えませんし、同じリポジトリを別の場所で再オープンしても重複しません。renga がペインのライフサイクルを把握している以上、古くなったペアを掃除する仕組みも追加で要りません。#289 以降、list_peers は全タブを列挙し (自分のタブが先頭)、数値 pane id を宛先にすればメッセージはタブをまたいで届きます。タブが今も律しているのは名前の解決で、pane 名はタブ内でのみ一意なため、名前指定は他タブへ解決されません (「配送の仕様」参照)。

チャンネル名は server:renga-peers と server:claude-peers で分かれているので、同じ Claude Code に両方インストールしていても衝突しません。renga 内では renga セッション単位、外では cwd / repo 単位、と使い分けられます。

セットアップ (1 回だけ)


renga mcp install --client claude
renga mcp install --client codex

いま走っている renga バイナリを renga-peers という名前で、選択した client のユーザー設定に登録します。Claude では claude mcp add-json、Codex では codex mcp add を使って、まず client CLI 側の正規登録経路に載せます。

Codex については、peer messaging に必要な env var passthrough を保つため、登録後に ~/.codex/config.toml の renga-peers エントリを最小限だけ補正します。check_messages と send_message の auto-approve まで入れたい場合は、--codex-auto-approve-peer-tools を付けて明示的に opt-in してください。send_keys や pane 操作系までは自動承認しません。

同じ登録を何度実行しても安全 (既に登録があれば内容を表示して止まる) で、renga をアップグレードしてバイナリのパスが変わったときだけ --force を付けて上書きしてください。


renga mcp uninstall --client claude
renga mcp status --client claude
renga mcp uninstall --client codex
renga mcp status --client codex

renga mcp install --client ... は、選んだ client の CLI が PATH にないと失敗します。Claude Code / Codex を先にインストールしてください。

Claude Code / Codex をメッセージング対応で起動する

配送方式は client ごとに非対称です。

Claude Code は MCP の experimental channel を使うので、起動時に --dangerously-load-development-channels server:renga-peers が必要です。
Codex は renga mcp install --client codex で入れた MCP 登録を使います。そこで RENGA_PEER_CLIENT_KIND=codex が MCP サブプロセスに注入されるため、pane 側の起動は plain codex で足ります。renga は非フォーカスの worker pane が ready になったら check_messages を促す nudge を流し込み、実際の peer 本文は check_messages で読ませます。対象の Codex pane がフォーカス中なら、すぐ PTY 注入せずローカル通知 overlay を出します。

Codex 側の peer messaging は、現状どうしても Claude より不安定です。理由は 2 つで、受信が check_messages ベースの pull 型であることと、MCP 承認が pane ごとで共有されないことです。pending messages の表示が stale になることもあるので、最終的な真実は常に check_messages の返り値を見てください。

Claude の起動フラグを毎回手で打たなくて済むように、renga 側から 2 つの経路を用意しています。

`Alt+P` — どのペインからでも

フォーカス中のペインで Alt+P を押すと、


claude --dangerously-load-development-channels server:renga-peers

が入力行に挿入されます (末尾にスペース、Enter は押されない)。そのまま Enter で起動してもよいし、引数を書き足してから Enter でも構いません。シェル (bash / zsh / fish / pwsh / cmd.exe) の種類を問わず同じ動きをします。これは shell の hook ではなく ペインの PTY にバイトを直接書き込んでいるからです。

`renga split --role claude` — 新しいペインで自動起動

ペインを分割した瞬間から、その新しいペインで自動的にフラグ付きの Claude Code が立ち上がります。


renga split --direction vertical --role claude
# 新しいペインで `claude --dangerously-load-development-channels server:renga-peers` が走る

renga new-tab --role claude も同じ扱い (新しいタブを開いてそこで起動)。--command "..." を明示的に渡したときはそちらが優先されるので、別のコマンドを走らせたいときはそれで上書きできます。

Codex の登録が済んでいれば、オーケストレータ側のペインから spawn_codex_pane(direction, …) で Codex ワーカーを会話の中から直接起動できます。

提供ツール

ピアメッセージング

ツール	役割
`list_peers(scope?)`	全タブの他ペインを、自分のタブを先頭に返します (#289)。自分自身は除外。各エントリに表示用のタブ情報 (`tab` index / `tab_name` / `same_tab`) が付きますが、タブ index はタブを閉じるとずれるので、宛先指定は常に数値 pane id を使ってください。`scope` は claude-peers-mcp との互換のため受け取りますが中身は見ません。
`send_message(to_id, message, deliver?)`	数値 pane id ならどのタブの相手にも届きます (#289)。名前 (stable name) はタブ内でしか一意でないため、自分のタブ内でのみ解決されます — 別タブの相手は名前では指定できません。解決できない宛先は偽の `Delivered` を返さず `pane_not_found` エラーになります。`deliver` は配送の意味を選びます: `"channel"` (既定・従来どおり) は相手のターンを奪わずに本文を見せるだけ、`"user_turn"` は本物のユーザーターンとして投入します (#323 — 後述)。
`check_messages`	queued peer message を drain します。Codex では renga の nudge を受けたあとに、実際の peer 本文をここから読みます。返ってきた各メッセージは「ただの文字列」ではなく、必要なら tool 実行やコード編集まで含む peer 指示として扱ってください。
`set_summary(summary)`	呼び出したペインの 1〜2 文サマリーを設定 / クリア。`list_panes` / `list_peers` の各エントリに `summary` フィールドとして含まれ、ピア間で「今何をしているか」を共有できます。空文字列でクリア、最大 256 Unicode scalar values (`[summary_too_long]` で reject)。renga プロセス内のメモリ保持のみで再起動では消えます。

channel 配送と user-turn 配送

この 2 つは「同じものの符号化違い」ではなく、意味の異なる配送です。

deliver="channel" (既定) は本文を Claude ピアには <channel source="renga-peers"> タグとして push し、Codex ピアにはペインローカル nudge を出して check_messages で読ませます。相手のターンは奪いません — 報告・ack・進捗共有に向いています。
deliver="user_turn" は本文を相手エージェントの入力欄に打ち込んで submit し、本物のユーザーターンとして届けます。ユーザーターンでないと発火しない指示 — /loop や /clear をはじめとするスラッシュコマンド — はこちらを使ってください。channel タグでは相手がテキストを了解するだけで何も起動されずに idle に戻ってしまいます。

user_turn は推測せず拒否します。renga はまずカーソルが入った空の入力欄 を積極的に同定できたときだけ書き込みます。証明できない画面は 1 バイトも書かずに拒否されるので、権限プロンプト・folder-trust ダイアログ・人間が書きかけの下書き・renga が知らない UI 改訂は、そこにターンを打ち込むのではなく fail closed します。拒否コード:

コード	意味	書き込み
`user_turn_busy`	相手がターン処理中。キューには積みません — 相手側の「busy 中にキュー」機能を使うと「submit した」が「あとで submit されるかもしれない」に化けるためです。	なし — idle になってから再試行
`user_turn_not_ready`	空の入力欄を証明できない (モーダル・下書き・読めない画面)。人間がスクロールバックしたペイン (renga がライブ画面ではなく履歴を読むことになる)、および同じ入力欄に別の配送が進行中の場合も含みます。	なし — 阻害要因を解消して再試行
`user_turn_unsupported_target`	そもそも Claude / Codex が動いていないペイン、またはプロセスが終了済み。	なし
`user_turn_invalid_body`	本文が空 / 制御文字入り / 単一行にタブを含む (相手は Tab キー入力として解釈するため) / 複数行なのに相手が bracketed paste 未対応 / 4 KiB 超（ユーザーターンはプロンプトであってファイル転送ではありません。`deliver="channel"` に長さ制限はありません） / Codex 宛のみ入力欄 1 行に収まらない本文（複数行、または幅超過）。	なし
`user_turn_stalled`	本文は打ち込まれたが submit を観測できなかった。	あり — 再試行前にペインを確認すること

Codex の長さ制限はポリシーではなく既知の制限です。折り返した Claude の入力欄は継続行をたどって読めますが、Codex が折り返した入力欄をどう描くかの検証済みモデルが renga に無く、推測することは「Enter がどの行を submit するか」を推測することと同じになります。打ち込んだまま submit できず放置するより、拒否する方が安全です。

成功 (status: "submitted") は下書きが消費されたのを観測してから返します。同一ペインへの同一本文は 5 秒以内なら抑止され status: "duplicate_suppressed" を返すので、user_turn_stalled 後の再試行が /clear を 2 回撃つことはありません。このウィンドウは channel 側の重複抑止とは別管理で、互いを飲み込みません。

阻害要因の「解消」は意図的に対象外です — ダイアログに答えるのは引き続き send_keys の仕事です。send_keys のセマンティクスは変更していません。 send_keys は入力欄の存在を前提にできない生キー入力 (y / n・Shift+Tab・ Ctrl+C・trust プロンプトへの素の Enter) のためにあり、そこに検証を足せばキーを拒否するか、意図した瞬間を過ぎてから届けるかのどちらかになります。 user-turn 配送を send_keys で自作しないでください。

ペイン操作

ツール	役割
`list_panes`	呼び出し元ペインが属するタブ (ユーザーが表示中のタブではありません) の全ペインを、id / 任意の name・role / フォーカス状態 / cwd / 端末ジオメトリ込みで一覧します。
`spawn_pane(direction?, …)`	指定ペインを分割して新ペインを生やします。`command`・`name`・`role`・`cwd`、そして #290 以降は配置先タブを選ぶ `tab` セレクタ (後述) もオプション。`command="claude"` (または `claude <args>`) を渡したときは `Alt+P` と同じ peer 対応コマンドに自動書き換えするので、毎回 `--dangerously-load-development-channels` を覚えていなくてもメッセージング付きの Claude が立ち上がります。
`spawn_claude_pane(direction?, …)`	Claude 起動専用の高レベル API。`spawn_pane` と同じ `tab` セレクタを受け付けます。`permission_mode` / `model` / `args[]` を構造化フィールドで受け取り、peer チャネルを必ず有効にした状態で Claude Code を立ち上げます。`args[]` に予約済みフラグ（`--dangerously-load-development-channels` / `--permission-mode` / `--model`）が入っていると `invalid-params` で拒否します。
`spawn_codex_pane(direction?, …)`	Codex 起動専用の高レベル API。`spawn_pane` と同じ `tab` セレクタを受け付けます。`args[]` から最終的な `codex ...` コマンドを renga 側で shell-quote して組み立てます。MCP サブプロセス側の `RENGA_PEER_CLIENT_KIND=codex` 登録は `renga mcp install --client codex` に委ねます。
`close_pane(target)`	ペインを閉じます。相対指定 (`"focused"`・名前) は呼び出し元自身のタブ内で解決され、数値 id のみ他タブに届きます (#296 — 修正前の `"focused"` はユーザーが表示中のタブのフォーカスペインでした)。他にタブが残っている状態でタブ最後のペインを閉じると、そのタブごと閉じます — `last_pane` で拒否されるのは唯一のタブの最後のペインだけです。
`focus_pane(target)`	キーボードフォーカスを移します。解決先のペインがユーザーの表示中タブに無い場合は、表示中のタブごとそのペインへ切り替わります — キーボードが届かない focus は focus ではないので意図的な挙動ですが、その分ペイン操作系で最も割り込み度が高いツールです。多用しないでください。
`new_tab(…)`	新しいタブを 1 枚開いてそこへフォーカスを移します。`spawn_pane` と同じ `cwd` オプションが使え、`command` の先頭トークンがちょうど `claude` のときは同じ `claude` 自動アップグレードが効きます。ユーザーの表示を切り替えないバックグラウンド新規タブが欲しい場合は `spawn_pane` の `tab={"new": {}}` を使ってください。タブ数の上限は 16 (`tab_limit_reached`) です。
`inspect_pane(target, …)`	別ペインの可視画面をスナップショットし、プロンプト待ち・警告バナー・モード変化などをそのペイン自身に説明させず検出できます。デフォルトはプレーンテキスト、`format="grid"` で行アドレス付き JSON。`lines=N` は末尾 N 行を返し、ペインの可視高さを超える分はスクロールバック履歴から遡って継ぎ足します (合計上限 2000 行)。小さいペインでも直近の出力に届きます。
`send_keys(target, …)`	別ペインの PTY に生のキー入力 (`Enter` / `Esc` / 矢印 / `Ctrl+<letter>` / 任意テキストなど) を送ります。`send_message` を解釈できない対話プロンプトや TUI を操作したいとき向けです。
`set_pane_identity(target, name?, role?)`	既存ペインの安定 `name` / `role` を付け直す・クリアします。タブスコープは `close_pane` と同じ (#296)。3 ステート: キー省略 = 現状維持、`null` = クリア、文字列 = 設定。全桁数字の name は数値 id と曖昧化するため拒否、解決先ペインのタブ内での name 衝突も拒否します。CLI では `renga rename` でも同じ操作ができます。

サーバ情報の取得

ツール役割

server_info 実際に動いているサーバの capability トークン集合を、gate されたリクエストを一切試さずに返します (#304)。事前確認用です — tab セレクタを送る前に spawn_tab を確認できるので、送ってから [server_too_old] エラー文字列を読んで判断する必要がなくなります。まず status を見てください: connected なら server.capabilities が実サーバの申告そのもので、そこが空配列なら本当に古いサーバという意味です。detached (renga から起動されていない) と unreachable (ソケットが無い) では null になり、これは「不明」であって「無い」ではありません — この 2 つから「トークンが無い」と結論しないでください。判定には effective_capabilities (サーバが申告し、かつこの mcp-peer ビルドが扱えるトークンの積集合) を使います。JSON-RPC エラーは決して返しません。ツール一覧にこのツール自体が無い場合、その renga は capability 公開より前のバージョンで、その不在自体が答えになります。

ツール	役割
`server_info`	実際に動いているサーバの capability トークン集合を、gate されたリクエストを一切試さずに返します (#304)。事前確認用です — `tab` セレクタを送る前に `spawn_tab` を確認できるので、送ってから `[server_too_old]` エラー文字列を読んで判断する必要がなくなります。まず `status` を見てください: `connected` なら `server.capabilities` が実サーバの申告そのもので、そこが空配列なら本当に古いサーバという意味です。`detached` (renga から起動されていない) と `unreachable` (ソケットが無い) では `null` になり、これは「不明」であって「無い」ではありません — この 2 つから「トークンが無い」と結論しないでください。判定には `effective_capabilities` (サーバが申告し、かつこの mcp-peer ビルドが扱えるトークンの積集合) を使います。JSON-RPC エラーは決して返しません。ツール一覧にこのツール自体が無い場合、その renga は capability 公開より前のバージョンで、その不在自体が答えになります。

イベント監視

ツール役割

poll_events(timeout_ms?, since?, types?) pane_started / pane_exited / events_dropped を cursor 付き long-poll で受け取ります。オーケストレータが毎ターン pane 一覧を総当たりせずに、ワーカーの起動・終了だけを追いたいとき向けです。イベントは renga プロセス全体が対象で、呼び出し元のタブに限らず全タブのペインのライフサイクルが届きます。

ツール	役割
`poll_events(timeout_ms?, since?, types?)`	`pane_started` / `pane_exited` / `events_dropped` を cursor 付き long-poll で受け取ります。オーケストレータが毎ターン pane 一覧を総当たりせずに、ワーカーの起動・終了だけを追いたいとき向けです。イベントは renga プロセス全体が対象で、呼び出し元のタブに限らず全タブのペインのライフサイクルが届きます。

spawn_pane / new_tab の作業ディレクトリ指定は cwd フィールドを使ってください。パス解決が構造化されたまま保て、claude 自動アップグレードも維持されます。自動アップグレードは command の先頭トークンがちょうど claude のときだけ発火するので、cd <dir> && ... を埋め込むと一切効かなくなります。

タブ配置 (#290)。 3 つの spawn_* ツールはオプションの tab セレクタで新ペインの配置先タブを選べます: {"name": "workers"} (表示名の完全一致 — 0 件は tab_not_found、複数件は tab_ambiguous)、{"index": 2} (0 始まり。list_peers の報告と同じ index)、{"pane_id": 17} (そのペインが属するタブ — 安定アンカー)、{"new": {}} / {"new": {"name": "workers"}} (単一ペインのバックグラウンド新規タブ。表示中のタブは切り替わらず、direction / target は省略必須、cwd 省略時は呼び出し元ペインの cwd を継承)。既存タブのセレクタでは target は選択タブの内側で解決され、別タブの数値 target は target_tab_mismatch で失敗します。サーバが spawn_tab capability を広告している必要があり、古いサーバへは誤ったタブに spawn する代わりに [server_too_old] で拒否されます。

2 ペインでのやり取りの例


タブ A                         タブ B
┌──────────┬──────────┐        ┌──────────┐
│ claude-1 │ claude-2 │        │ claude-3 │
│          │          │        │          │
│  peers ──┼──▶ ✓     │        │    ▲     │
│  send ◀──┼── msg    │──id=3───────┘     │  ← 数値 id で届く (#289)
└──────────┴──────────┘        └──────────┘

Claude A の会話で：


> list_peers を呼んで
# → id=2 (同じタブの相方 — id でも名前でも指定可)
#    id=3 [tab 1] (別タブ — 数値 id で指定する)

> send_message を to_id=2, message="src/app.rs の handle_split を読んで要約して" で呼んで

Claude B の次のターンのコンテキストには、


<channel source="renga-peers" from_id="1" from_name="leader">
src/app.rs の handle_split を読んで要約して
</channel>

というタグで届きます。Claude B はこのタグを「ユーザーではなく相方からの依頼」として判別し (タグの source 属性で区別)、要件を処理した上で同じ send_message ツールを使って返信します。

相方ペインが対話プロンプトで止まった場合も、同じオーケストレータが会話の中で処理できます。


> inspect_pane を target="2", lines=20 で呼んで
# → "Allow this command? [y/N]" が見える

> send_keys を target="2", text="y", enter=true で呼んで
# → pane 2 の PTY に "y<Enter>" を書き込む

> poll_events を since="<前回の next_since>", types=["pane_started","pane_exited"] で呼んで
# → 毎ターン list_panes を総なめせずにワーカーの増減だけ待てる

配送の仕様

メモリ上、タブが生きている間だけ: renga プロセスが終われば全ペインの受信箱も消えます。永続化はあえて外しています (claude-peers-mcp が必要としている SQLite GC や stale entry の掃除が不要になるため)。
キューは上限付き: ペインあたり 256 件までで、溢れると古いものから捨てられ、EventsDropped というメタイベントが subscriber に通知されます。既存の IPC EventBus を使い回しているので、ここに新しい仕組みを足してはいません。
opt-in のルーティング (#306): IPC の購読は pane を名乗れるようになりました (subscribe のオプション項目 from_pane)。名乗った購読には、その pane 宛の peer_inbox イベントだけが配送されます (同梱の mcp-peer は自分が担当する pane を名乗ります)。pane を名乗らない購読 (renga events を含む) には、これまでどおり全ての peer_inbox が流れます — 既存のストリームの挙動は何も変わりません。どちらの場合も他の種別のイベントは全 subscriber へ broadcast され、メッセージが宛先ペインへ届く経路もこれまでと同じです。pane を名乗ることは defense in depth であって境界ではありません — 同一ユーザーで動くプロセスなら誰でも購読して任意の pane id を名乗れるためです。得られるのは、意図しない別 pane への配送と、全メッセージを全 subscriber にコピーすることで生じていたキュー負荷が無くなることです。リクエストの形は IPC のページを参照してください。
投げっぱなし: send_message には相関 id や到達確認がありません。返事が欲しければ Claude が自分で send_message(to_id=from_id, ...) を呼びます。
タブ横断配送 (#289): 数値 pane id を宛先にした送信はどのタブにも届きます。旧仕様の「別タブ宛は黙って捨てる」(とその列挙耐性) は撤廃されました — エージェント間の隔離は renga のタブ境界ではなく外側のセキュリティ層の仕事です。解決できない宛先 (存在しない / 閉じたペイン、別タブにしか無い名前) は pane_not_found エラーになります。cross_tab_peers capability を広告する server が必要で、古い renga プロセス相手には same-tab 挙動へ黙って劣化せず [server_too_old] で拒否します — renga を再起動してください。

うまく動かないとき

`list_peers` が “renga not reachable from this peer client” を返す

client が renga の外で起動されたか、renga ペインの環境変数を引き継げていない状態です。renga のペイン内から起動し直してください（Claude は Alt+P / renga split --role claude、Codex は renga mcp install --client codex 後の plain codex または spawn_codex_pane）。

具体的には RENGA_PANE_ID という環境変数が MCP サブプロセスまで届いている必要があります。renga 経由でペインを作って中で claude を起動すれば、この変数は PTY → シェル → claude → mcp-peer と自動的に伝わります。

相手に送ったメッセージが `<channel>` タグとして表示されない

起動時のフラグ --dangerously-load-development-channels server:renga-peers を付け忘れています。claude と打ち直す代わりに Alt+P を使うと、フラグ付きのコマンドが入力行に挿入されるので事故りにくくなります。

Codex に送ったのに反応がない

Codex への配送は pane-driven です。renga が check_messages を促す nudge を queue し、Codex ペインが PTY 入力を安全に受けられる状態で、かつ非フォーカスになった時点で流し込みます。busy な間は queue に残ります。フォーカス中に届いた場合は通知 overlay を出し、Alt+Enter / Ctrl+Enter で check_messages 用の文面だけを composer に挿入します。Esc なら無視、Enter を押して実行するかどうかは人間が決めます。後でフォーカスが外れれば、worker と同じ queued nudge 経路に戻ります。

check_messages で受け取った本文が実際の peer 依頼です。単に返事を返すためのチャットではなく、人間からの依頼に近い peer 指示として扱うのが前提です。調査、pane 操作、tool 実行、コード編集などを頼まれたなら、その作業自体を進めてください。

Codex の `pending messages` 表示が残るのに `check_messages` は 0 件

pane-local nudge は queue 状態を常時同期するバナーではなく、check_messages を促す one-shot の入力です。Codex の履歴に残るので、受信箱を drain したあとでも画面上にはしばらく見えます。

check_messages が 0 件なら、それは stale な nudge です。実 inbox 側は空なので、そのまま無視して構いません。

`spawn_codex_pane` が `[codex_not_installed]` で失敗する

ハンドラは事前に Codex の MCP 設定 (~/.codex/config.toml) を検査し、[mcp_servers.renga-peers.env] RENGA_PEER_CLIENT_KIND = "codex" が登録されていることを確認します。ファイルが無い／読めない、エントリ自体が無い、env 値が不一致のいずれかで JSON-RPC -32603 を [codex_not_installed] マーカー付きで返します（黙って claude (push) として再登録される silent bifurcation を防ぐためです）。

renga mcp install --client codex を 1 回実行すれば登録されます。env 値だけが欠落した既存エントリ（旧 renga で入れたもの等）も、同じ install コマンドで self-heal するので、未インストール／部分インストールどちらの状態にも同じ手順で対応できます。

新しい Codex pane でまた承認が出る

Codex の MCP 承認は pane ごとです。Claude Code のような「一度許可したら同じタブの別 pane にも伝播する」共有承認は前提にしていません。

新しい Codex pane を立てた直後に 1 回だけ warm-up してください。

その pane に peer message を 1 通送る
check_messages の承認で Always allow を選ぶ
返信時の send_message の承認でも Always allow を選ぶ

renga mcp install --client codex --codex-auto-approve-peer-tools はこの 2 つを事前設定しようとしますが、Codex 側のバージョンや実行形態によっては、新しい pane で一度だけ承認が必要なことがあります。

`send_keys` が効いていないように見える

send_keys は target ペインの PTY に生の入力バイトを書き込むだけで、UI のボタンを押したり、帯域外で承認を通したりするものではありません。まだストリーミング中だったり、すでにプロセスが終わっていたり、想定と違うプロンプトが見えていたりすると、期待した結果にはなりません。

先に inspect_pane(target=..., lines=20) で画面を確認し、レイアウトが動く運用では target に安定した pane name を使ってください。フォーカス競合や誤送信を減らせます。

`poll_events` が想定より早く `events: []` を返す

多くの場合は types=[...] フィルタの仕様どおりです。条件に合わないイベントでも long-poll 自体は解除され、そのイベントを飛び越えた next_since が返ります。つまり空配列でも cursor は進み、そのイベントは再送されません。

返ってきた next_since をそのまま次回の poll に使ってください。events_dropped が来たときは list_peers で再同期してから続行します。poll_events はプロセス全体が対象なので、対応する全タブのビューは list_peers です — list_panes が返すのは呼び出し元自身のタブだけで、他タブのペインで落ちたイベントは埋め合わせられません。list_peers は自分自身のペインを含まないため、自分のタブを詳細に取り直すときは list_panes と併用してください。

`renga mcp install` が失敗する

選んだ client の CLI が PATH にない → Claude Code / Codex を先にインストールしてください。
すでに別のバージョンが登録されている → --force で上書きするか、renga mcp uninstall してから再度 install してください。

renga をアップグレードしたら繋がらなくなった

登録されているバイナリのパスが古いです。


renga mcp install --client claude --force
renga mcp install --client codex --force

これで今の renga のフルパスに更新されます。

見送っているもの

ブロードキャスト — タブ横断の 1 対 1 メッセージングは #289 で入りましたが、broadcast_tab 的なツールはまだありません。引き続き検討候補です。
履歴の永続化 — タブの寿命と同期する形で十分なので、SQLite などは入れていません。
MCP 以外の peer — mixed support は現状 Claude Code と Codex 向けです。renga 外部の IPC クライアントや普通のシェルペインは相手として登場しません。
添付ファイル / 構造化リクエスト・レスポンス — body はテキストのみで、相関 id もありません。

参考

Issue #97 — 設計の意図決定の流れ
PR #104 — v1 実装
claude-peers-mcp — 兄弟プロジェクト (cwd / repo スコープ版)
Model Context Protocol