セッション間メッセージは、同じマシン上で同じユーザーアカウントで動作している 2 つの Qoder CLI セッションが、互いを検出してメッセージをやり取りできるようにする機能です。あるセッションから別のセッションに Task を引き継いだり、ファイルを渡したり、質問したりできます。ターミナル間でテキストをコピーする必要はありません。
作業が自然に複数のセッションにまたがる場合に向いています。たとえば、一方のターミナルでバックエンド、もう一方でフロントエンドを扱う場合や、長時間動作しているセッションに別のウィンドウから作業を渡す場合です。
有効にすると、各セッションは専用の socket を待ち受け、そのパスをユーザーごとのレジストリに記録します。他のセッションはそのレジストリを読んで peer を検出し、直接接続してメッセージを配信します。
socket とそのディレクトリは、自分のユーザーアカウントからのみ読み取れます。同じマシン上の他のユーザーのセッションからは、参照も接続もできません。
Agent に到達可能な相手を一覧するよう依頼できます。Agent 自身が
セッションの名前は現在のタイトルです。そのため
Agent は teammate に送るときと同じ
各セッションは
信頼の判断を自動で決められずにメッセージが保留された場合、セッションは直接あなたに確認します。
この確認は、このセッションが画面に出すもののうち最後に来ます。回答途中の権限確認やダイアログを中断することはなく、他に回答を求めているものがないときにだけ表示されます。承認すると次のターンで配信され、拒否するとメッセージは破棄され、その旨が送信側に伝えられます。表示される本文は短縮されており、承認時に配信されるのは全文です。添付ファイルは件数のみ示されます。メッセージ到着時にすでにコピーされており、拒否すると削除されるためです。
確認は同時に 1 件だけ、しかも画面が空いているときだけ行われます。他の確認やダイアログの表示中に届いたメッセージは保留され、そちらは
出力の 1 行目には、有効な受信ポリシーとその出所 — 自分の設定、リポジトリの設定、または権限モードによるフォールバック — が常に表示されます。フォールバックの場合は、個々のメッセージの判定結果ではなくルール自体が示されます。メッセージがまったく届かないときは、まずこの行を確認してください。リポジトリ設定による
承認するとメッセージは次のターンに投入されます。拒否すると破棄され、送信側には拒否されたことが通知されます。
peer からのメッセージは、あなた本人の指示ではなく同僚からの依頼として扱われます。
分離はファイル権限に依存しています。socket とそのディレクトリは自分のユーザーアカウントに限定されます。その境界の内側では、送信元が名乗る名前は暗号的に検証されないため、すでにあなたの権限で動作しているプロセスであれば任意の peer になりすませます。セッション間メッセージの信頼度は「自分のアカウントで動作しているすべてのもの」と同程度と考え、高い権限で動作しているセッションでは
Beta セッション間メッセージは現在 beta 機能であり、デフォルトでは有効になっていません。Qoder CLI を起動する前に環境変数で有効化します:QODER_FEATURE_CROSS_SESSION=1 qoder。QODER_FEATURE_CROSS_SESSION=1をユーザーレベル設定の.envに保存すると、以降のセッションで自動的に有効になります。ユーザーレベル設定のデフォルトパス:$HOME/.qoder/.env。.envを変更したら Qoder CLI を再起動してください。 この機能は Unix domain socket を使用するため、macOS と Linux でのみ利用できます。
仕組み
有効にすると、各セッションは専用の socket を待ち受け、そのパスをユーザーごとのレジストリに記録します。他のセッションはそのレジストリを読んで peer を検出し、直接接続してメッセージを配信します。
peer の検出
Agent に到達可能な相手を一覧するよう依頼できます。Agent 自身が ListAgents を呼ぶこともあります。一覧は 2 つのグループに分かれます。現在のセッション内部の Agent と、マシン上の他の peer セッションです。
/rename を実行したときや、Agent が会話のタイトルを付け直したときに変わります。ステータス列も同じようにセッションを追跡し、Agent が作業中なら busy、確認を求めているなら waiting、ユーザーが shell プロンプトにいるなら shell、それ以外は idle になります。
タイトルのないセッションは、作業ディレクトリ名にそのセッションの handle（上の -7c）を付けた名前になります。これがないと同じディレクトリで作業しているセッションはすべて同じ名前になり、どれも指定できません。そのため /home/dev/api の 2 つのセッションは api が 2 つではなく、api-7c と api-3f として表示されます。
peer は行のラベルで指定するか、handle だけでも指定できます。handle はそのセッションが待ち受ける socket から導かれるので、どのセッションの一覧でも同じ値になり、セッションの名前が変わっても変わりません。-7c は、そのとき何という名前であってもそのセッションに届きます。タイトルのあるセッションは名前に handle を含まないため、行に handle -3f と明記されます。
/peers を実行すると、同じ一覧に加えて、このセッション自身の handle も確認できます。
メッセージの送信
Agent は teammate に送るときと同じ SendMessage ツールを使い、宛先に peer の名前を指定します。絶対パスでファイルを添付でき、ファイルは受信側にコピーされて読めるようになります。
送信結果は正確に報告されます。一覧取得後から送信までの間に peer が終了していた場合、成功を装わずにその旨を返し、再度一覧を取得するよう促します。
受信内容の制御
各セッションは security.crossSessionInbound 設定によって、受信した peer メッセージの扱いを自分で決めます。
accept: そのセッションの次のターンに配信します。hold: 確認待ちとして保留します。承認するまで Agent からは見えません。refuse: すべて拒否します。配信されず、添付ファイルもディスクに書き込まれません。
security.crossSessionInbound に accept を明示的に設定してください。自分で設定した値は、そのようなセッションでも常に尊重されます。
プロジェクトレベルの設定は制限を強める方向にのみ働きます。リポジトリにコミットされた設定で accept を hold に強めることはできますが、hold を accept に緩めることはできません。リポジトリの設定が自分の選択を上書きし得るため、/peers は有効な設定とその出所となるファイルを常に表示します。
保留されたメッセージの承認
信頼の判断を自動で決められずにメッセージが保留された場合、セッションは直接あなたに確認します。
/peers で確認します。表示中の確認が他のものに画面を譲った場合も、そのメッセージは期限を待たずにキューへ戻ります。
確認を待つ時間は general.dialogExpiry で決まり、既定は 5 分です。時間切れになるとメッセージは破棄され、送信側には「拒否された」ではなく「期限切れ」と伝わります。この違いは送信側の Agent が判断に使えます。never は他のダイアログの期限を取り除きますが、この確認には適用されません。応答のない確認が 1 件あるだけで、以降のすべてのメッセージが確認の機会を失うことを防ぐためです。
自分で hold を設定したために保留されたメッセージは、確認なしで保留されます。自分自身の恒常的な設定は問いかけではないからです。これらは /peers で確認します。
一方、リポジトリの設定ファイル由来の hold は確認を求めます。値は同じですが、それはあなたではなくリポジトリが下した判断なので、本来表示されるはずだった確認を黙って取り除くのではなく、あなたに問いかけます。
保留されたメッセージの確認
/peers を実行すると、有効なポリシー、到達可能な peer、確認待ちのメッセージを表示できます。
refuse は、理由を示す保留メッセージを一切生成しません。
保留された各メッセージには id、送信元、保留理由、内容のプレビューが表示されます。送信元は、相手が返信先として示したアドレスから導いた handle で識別され、/peers はそのアドレスに到達できるセッションがまだあるかどうかも示します。そのアドレスも隣の名前も検証されたものではありません。誰が送ったかを証明できるセッションはないからです。ただし handle は上の peer 一覧と突き合わせられます。名前は読むことしかできません。
id を指定して承認または拒否します。
peer メッセージにできること、できないこと
peer からのメッセージは、あなた本人の指示ではなく同僚からの依頼として扱われます。
- 保留中の権限確認に対する、あなたの承認とは決してみなされません。
- peer メッセージの先頭の
/はプレーンテキストとして扱われ、slash command としては実行されません。 - 権限の境界はセッションごとです。ある peer が拒否された操作を別のセッションに代行させようとした場合、受信側の Agent はそれを拒否し、あなたに報告します。
セキュリティに関する注意
分離はファイル権限に依存しています。socket とそのディレクトリは自分のユーザーアカウントに限定されます。その境界の内側では、送信元が名乗る名前は暗号的に検証されないため、すでにあなたの権限で動作しているプロセスであれば任意の peer になりすませます。セッション間メッセージの信頼度は「自分のアカウントで動作しているすべてのもの」と同程度と考え、高い権限で動作しているセッションでは hold の使用を推奨します。
設定リファレンス
security.crossSessionInbound:accept、hold、refuseのいずれか。このセッションが受信する peer メッセージの扱いを制御します。general.dialogExpiry:60s、5m、10m、neverのいずれか。承認の確認が何分待ってからメッセージを期限切れとして破棄するかを決めます。既定は5m。自分の設定からのみ読み込み、リポジトリの設定からは読み込みません。