@cocorograph/hub-agent 0.8.26 → 0.8.27

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cocorograph/hub-agent",
-  "version": "0.8.26",
+  "version": "0.8.27",
   "description": "Hub Hosted Cockpit のローカル常駐 agent。Hub と outbound WSS で接続し、ローカルの Claude / Codex チャットと tmux セッションを中継する。",
   "type": "module",
   "license": "UNLICENSED",

package/src/codex-stream-bridge.mjs

@@ -315,6 +315,29 @@ export function deriveResumeTurnState(thread) {
   return { threadStatus, lastTurnStatus, turnActive, activeTurnId }
 }
 
+/**
+ * sibling 依頼の識別子 (`request_id`) から配送 ID を **決定的に** 導出する (2026-08-05)。
+ *
+ * ⚠️ なぜランダムではいけないか: `_deliverInjection` は導出した値を `input({inputId})` に渡し、
+ * `input()` はその id を `session.acceptedInputIds` に控えて **同じ id の再到着を no-op にする**
+ * (重複ガード)。ここが `randomUUID()` だと同一依頼の再処理 (hub-agent 再起動後の sweep で同じ
+ * 要求ファイルを読み直す / 送信側がタイムアウトと誤認して同じ依頼を投げ直す) が毎回「別物」と
+ * 見なされ、ガードが一度も効かない = 同じ本文が二重に実行される。
+ *
+ * ⚠️ 冪等キーなので **異なる依頼同士で衝突させてはいけない**。`request_id` は要求ファイル名
+ * (cockpit_orch.py は uuid4 の hex) であり依頼ごとに一意なので、加工せず丸ごと使う (切り詰め・
+ * 正規化をすると衝突の余地が生まれる)。`sib-` の接頭辞は browser 入力の inputId と名前空間を
+ * 分けるためだけのもの。
+ *
+ * @param {unknown} requestId sibling 要求ファイルの `<request_id>`
+ * @returns {string|null} 導出した配送 ID。識別子が無い経路では null (呼び出し側が randomUUID)
+ */
+export function siblingDeliveryId(requestId) {
+  if (typeof requestId !== "string") return null
+  const trimmed = requestId.trim()
+  return trimmed ? `sib-${trimmed}` : null
+}
+
 /**
  * 配達保証 (S2, 2026-07-05): `input()` が reject したエラーを `codex.input.nack` の
  * `reason` へ分類する。
@@ -1216,6 +1239,21 @@ export class CodexStreamBridge extends EventEmitter {
     }
   }
 
+  /**
+   * 重複ガードの台帳から id を取り消す (2026-08-05)。
+   *
+   * `input()` は turn/start を打つ **前** に `_recordAcceptedInput` するため、RPC が失敗して
+   * 「1 度もターンが起きていない」ときでも id が受理済みとして残る。sibling 注入はここで
+   * `delivery_failed` (= 再送してよい) を返すので、id を残したままだと**正当な再送を重複と
+   * 誤判定して握り潰す**。受理を取り消した経路だけで呼ぶこと。
+   */
+  _forgetAcceptedInput(session, inputId) {
+    const ids = session?.acceptedInputIds
+    if (!Array.isArray(ids) || typeof inputId !== "string" || !inputId) return
+    const at = ids.indexOf(inputId)
+    if (at !== -1) ids.splice(at, 1)
+  }
+
   _pendingInputItems(session) {
     if (!session || !Array.isArray(session.inputQueue)) return []
     return session.inputQueue.filter((item) => item !== session.dispatchingInput)
@@ -2158,15 +2196,18 @@ export class CodexStreamBridge extends EventEmitter {
    *
    * @param {string} cwd
    * @param {string} text
+   * @param {'peer'|'orchestrator'} [source]
+   * @param {string} [requestId] sibling 要求の識別子 (配送 ID を決定的に導出し重複を止める)
    * @returns {Promise<
    *   {status:"delivered", session:object, delivery_id:string, accepted_via:string}
+   *   | {status:"delivery_queued", session:object, delivery_id:string, accepted_via:string, reason:string}
    *   | {status:"delivery_unconfirmed", session:object, delivery_id:string, accepted_via:string, reason:string}
    *   | {status:"delivery_failed", session:object, delivery_id:string, reason:string}
    *   | {status:"ambiguous", candidates:object[]}
    *   | {status:"not_found"}
    * >}
    */
-  async sendToCwd(cwd, text, source) {
+  async sendToCwd(cwd, text, source, requestId) {
     if (!cwd || !text) return { status: "not_found" }
     // 案B: distinct session で走査（多対一 Map の重複を除く）。
     const cands = this._liveSessions().filter((s) => s.cwd === cwd)
@@ -2206,6 +2247,7 @@ export class CodexStreamBridge extends EventEmitter {
       cwd,
       selection: "sole-candidate",
       candidates: this.describeLiveSessions(cwd).length,
+      request_id: requestId,
     })
   }
 
@@ -2234,9 +2276,11 @@ export class CodexStreamBridge extends EventEmitter {
    * @param {string} cwd 呼び出し元がトークン検証した cwd (この cwd のセッションにのみ注入)
    * @param {string} id 宛先 stream_id (一意・推奨) または thread_id
    * @param {string} text
+   * @param {'peer'|'orchestrator'} [source]
+   * @param {string} [requestId] sibling 要求の識別子 (配送 ID を決定的に導出し重複を止める)
    * @returns {Promise<object>}
    */
-  async sendToStream(cwd, id, text, source) {
+  async sendToStream(cwd, id, text, source, requestId) {
     if (!cwd || !id || !text) return { status: "not_found" }
     let bySid = null
     const byThread = []
@@ -2266,6 +2310,7 @@ export class CodexStreamBridge extends EventEmitter {
       cwd,
       requested_id: id,
       selection: bySid ? "stream_id" : "thread_id",
+      request_id: requestId,
     })
   }
 
@@ -2274,10 +2319,41 @@ export class CodexStreamBridge extends EventEmitter {
    * dispatched (本関数開始) → accepted (turn RPC成功) →
    * delivered (同一sessionの userMessage item/completed echo) → durable (rollout監査、別層)。
    * ここでは delivered までを同期的に確認し、echo timeout は成功扱いしない。
+   *
+   * ⚠️ 例外は「相手が応答生成中」(2026-08-05)。この場合メッセージは次ターン FIFO に受理される
+   * だけで **echo は次のターンが始まるまで来ない**ので、待つと最長でターン 1 本ぶん (実測 30 分)
+   * ブロックする。旧実装は `inputId` を渡していなかったため `input()` の即時 resolve 経路にも
+   * 乗らず、送信元 CLI が待ちきれず「hub-agent が起動していない」と誤報 → 再送 → 二重配送を
+   * 起こしていた。キューが「待たせる席」なので、hub-agent が送信元を待たせる必要は無い。
+   * 順番待ちは `delivery_queued` (echo 欠落 = `delivery_unconfirmed` とは別の状態) で即返す。
    */
   async _deliverInjection(session, text, source, context = {}) {
-    const deliveryId = randomUUID()
+    // 冪等キー: sibling 依頼の識別子から決定的に導出する (無い経路のみランダム)。
+    const deliveryId = siblingDeliveryId(context.request_id) || randomUUID()
     const sourceStreamId = session.stream_id
+    // 同一依頼の再処理 (hub-agent 再起動後の sweep 等) は、ここで打ち切って二重実行しない。
+    // 見ているのは `input()` の重複ガードと同じ `acceptedInputIds` なので判定は原理的に一致する
+    // (ここで弾き損ねても input() 側が turn を二重に起こさない = 二段構え)。
+    if (deliveryId && session.acceptedInputIds?.includes(deliveryId)) {
+      this.logger?.info?.(
+        {
+          ...context,
+          delivery_id: deliveryId,
+          stream_id: sourceStreamId,
+          thread_id: session.threadId,
+          delivery_state: "queued",
+          reason: "duplicate_request",
+        },
+        "codex sibling injection duplicate request ignored (already accepted)",
+      )
+      return {
+        status: "delivery_queued",
+        session: this._describe(session),
+        delivery_id: deliveryId,
+        accepted_via: "duplicate",
+        reason: "duplicate_request",
+      }
+    }
     const injectHandle = this._recordInjectSource(
       session,
       text,
@@ -2320,8 +2396,16 @@ export class CodexStreamBridge extends EventEmitter {
         stream_id: sourceStreamId,
         message: { role: "user", content: text },
         deliveryId,
+        // ⚠️ inputId を渡すのが「順番待ちで即返す」の肝。渡さないと input() の
+        //    `acceptedAsQueued = queuedAtArrival && !!inputId` が常に false になり、
+        //    実際に turn/start を打つまで promise が解決しない (= 相手のターンが終わるまで
+        //    送信元をブロックする)。browser 送信は既に inputId を渡して即返しになっている。
+        inputId: deliveryId,
       })
     } catch (err) {
+      // turn/start は 1 度も成功していない = 再送してよい。重複ガードの台帳から取り消して
+      // おかないと、同じ request_id での正当な再送を「重複」と誤判定して握り潰す。
+      this._forgetAcceptedInput(session, deliveryId)
       this._removeInjectSource(session, injectHandle)
       this.logger?.error?.(
         {
@@ -2355,6 +2439,39 @@ export class CodexStreamBridge extends EventEmitter {
       },
       "codex sibling injection accepted",
     )
+    if (accepted?.method === "queued") {
+      // 相手が応答生成中 (または pump 進行中): 次ターン FIFO に受理済み。echo は次のターンが
+      // 始まるまで来ないので **待たない** (待てばターン 1 本ぶんブロックする)。injectHandle は
+      // 消さずに残す — 後で届く userMessage echo を _tagInjectSourceOnItem が拾い、受け手画面で
+      // 連携カードとして表示するために要る。
+      // 永続記録は claude 版と同じ「受理時点」で行う (hub-agent 再起動後の hydrate で、この注入を
+      // 通常の user 依頼として表示しないため)。
+      recordInjectSourcePersistent(session.cwd, text, source).catch(() => {})
+      this.logger?.info?.(
+        {
+          ...context,
+          delivery_id: deliveryId,
+          stream_id: sourceStreamId,
+          current_stream_id: session.stream_id,
+          thread_id: session.threadId,
+          accepted_via: accepted?.method || null,
+          delivery_state: "queued",
+          reason: "queued_behind_active_turn",
+          queued: this._pendingInputItems(session).length,
+          active_turn_id: session.activeTurnId || null,
+        },
+        "codex sibling injection queued behind active turn",
+      )
+      return {
+        // ⚠️ delivery_unconfirmed と混ぜない。あちらは「届いたか分からない」、こちらは
+        //    「受理済み・順番待ち・再送不要」で、送信元が取るべき行動が正反対になる。
+        status: "delivery_queued",
+        session: this._describe(session),
+        delivery_id: deliveryId,
+        accepted_via: accepted?.method || null,
+        reason: "queued_behind_active_turn",
+      }
+    }
     const delivery = await this._waitInjectDelivery(injectHandle)
     if (!delivery?.delivered) {
       this.logger?.warn?.(

package/src/sibling-inject.mjs

@@ -37,6 +37,15 @@
  * candidates_nameable?}` を書く (`candidates_nameable` は曖昧系エラーのときのみ。CLI が
  * 「候補を実行可能な `--to` として並べてよいか」を hint の文言に依存せず判定するための boolean)。
  *
+ * ⚠️ codex の `delivery_state` は 4 値ある (2026-08-05 に `queued` を追加):
+ *   - `delivered`            … userMessage echo まで確認済み (ok:true)
+ *   - `queued`               … **相手が応答生成中**。次ターンのキューに受理済みで、echo は次の
+ *                              ターンが始まるまで来ない。**再送不要** (ok:true)
+ *   - `accepted_unconfirmed` … turn RPC は通ったが echo を確認できない (ok:false)
+ *   - `failed`               … turn RPC が失敗。再送してよい (ok:false)
+ * `queued` を待たずに即返すのが要点で、待つと相手のターン (実測 30 分) ぶん送信元がブロックし、
+ * 待ちきれない CLI が「hub-agent が起動していない」と誤報して再送 → 二重配送になる。
+ *
  * ⚠️ 曖昧系のエラーコードは 2 つある (2026-08-02 クロスレビュー round2 major):
  *   - `ambiguous_target`            … 候補を `--to` で名指しできる (解消手段がある)
  *   - `ambiguous_target_unnameable` … 名指しでは解消できない (session_id 未確定 / resume 競合)
@@ -64,6 +73,17 @@ const DELIVERY_UNCONFIRMED_HINT =
   "再送すると重複配送になります。再送前に対象セッションの受信状態または rollout 監査を確認してください。"
 const DELIVERY_FAILED_HINT =
   "turn RPC の受付前または受付中に失敗しました。対象セッションを確認して再送してください。"
+/**
+ * 「受理済み・順番待ち」= 相手が応答生成中なのでメッセージは次ターンのキューに入った (2026-08-05)。
+ *
+ * ⚠️ `delivery_unconfirmed` と語彙を分ける。あちらは「届いたか分からない (再送すると重複の恐れ)」、
+ * こちらは「確実に受理された。相手のターンが終われば実行される」で、**送信元が取るべき行動が違う**
+ * (前者は受信状態の確認、後者は待つだけ)。旧実装はここで hub-agent が送信元をブロックし続け、
+ * 待ちきれない CLI が「hub-agent が起動していない」と誤報して再送 → 二重配送を起こしていた。
+ */
+const DELIVERY_QUEUED_HINT =
+  "相手セッションが応答生成中のため、メッセージは次ターンのキューに入りました (受理済み)。" +
+  "相手のターンが終わり次第そのまま実行されるので、再送は不要です。"
 
 /** 曖昧だが `--to` で名指しして解消できる (候補を実行可能な宛先として案内してよい)。 */
 export const AMBIGUOUS_TARGET_ERROR = "ambiguous_target"
@@ -148,7 +168,9 @@ function claudeCandidatesNameability(candidates) {
  */
 function ambiguousTargetOutcome(cliKind, targetSessionId, candidates) {
   // 名指し可否の判定はここ 1 回だけ。error も hint もこの値から導くので三者は原理的に一致する。
-  // codex は stream_id が常に一意なので候補を見るまでもなく名指しできる。
+  // codex は候補ごとに必ず一意な接続 ID (stream_id) を持つため、候補を見るまでもなく名指しで
+  // 解消できる (既定の宛先は会話 ID = thread_id だが、同じ会話に複数の接続がぶら下がると会話 ID
+  // では一意に定まらない。そのときに接続 ID で絞り込む、という降格した位置づけ)。
   const nameability = cliKind === "codex" ? "nameable" : claudeCandidatesNameability(candidates)
   const nameable = nameability === "nameable"
   const lead = targetSessionId
@@ -158,7 +180,19 @@ function ambiguousTargetOutcome(cliKind, targetSessionId, candidates) {
     : `この cwd には live な ${cliKind} セッションが複数あるため、宛先を省略すると一意に定まりません。`
   let remedy
   if (cliKind === "codex") {
-    remedy = `stream_id で名指ししてください (--list で確認)。`
+    // ⚠️ 「stream_id を指定」とだけ案内しない (2026-08-05)。--list / --list-all が既定で表示する
+    //    宛先は **会話 ID (thread_id)** で、stream_id は「同じ会話に複数の接続がある稀なケース」の
+    //    曖昧解消用へ降格した。利用者が画面で見ているのは --list が候補に併記する `stream=…` の
+    //    表記なので、案内もその表記に合わせる (見えていない用語を指示すると手詰まりになる)。
+    // ⚠️ 曖昧の中身は 2 通りで、必要な id が違うので案内も分ける:
+    //    - 宛先省略 (targetSessionId 無し) … **別々の会話**が同居している。会話 ID で名指しできる。
+    //    - 明示宛先が曖昧 (会話 ID 指定)   … **同じ会話に複数の接続**。会話 ID では絞れず接続 ID が要る。
+    remedy = targetSessionId
+      ? `同じ会話に複数の接続がぶら下がっているため、会話 ID では一意に定まりません。` +
+        `--list が候補に併記する接続 ID (stream=…) を --to に指定してください。`
+      : `--list が表示する宛先 (会話 ID) を --to に指定して名指ししてください。` +
+        `同じ会話に複数の接続がぶら下がっていて会話 ID でも一意に定まらない場合は、` +
+        `--list が併記する接続 ID (stream=…) を --to に指定してください。`
   } else if (nameability === "nameable") {
     remedy =
       `候補はそれぞれ別の会話で session_id が異なるため、session_id で名指しできます ` +
@@ -191,6 +225,27 @@ function deliveredStateFor(kind) {
   return kind === "codex" ? "delivered" : "dispatched"
 }
 
+/**
+ * 「受理済み・順番待ち」(`delivery_queued`) の結果を組み立てる。
+ *
+ * ⚠️ 明示宛先 / 宛先省略の **両分岐で同じ形**を返すため 1 箇所に置く (delivered /
+ * delivery_unconfirmed は 2 か所に書かれており、実際にキーが片方だけずれる余地がある)。
+ * `ok: true` にするのは、これが失敗ではなく **受理** だから。送信元に「失敗した」と読ませると
+ * 再送を誘発し、キューに 2 通並ぶ (今回直した二重配送そのもの)。ただし配達済みとも読ませない
+ * よう `delivery_state` は `delivered` ではなく `queued` にし、hint で待てばよいことを伝える。
+ */
+function queuedResult(r) {
+  return {
+    ok: true,
+    delivered_to: r.session ?? null,
+    delivery_id: r.delivery_id,
+    delivery_state: "queued",
+    accepted_via: r.accepted_via,
+    reason: r.reason,
+    hint: DELIVERY_QUEUED_HINT,
+  }
+}
+
 export class SiblingInjectBridge {
   /**
    * @param {{dir?: string, claudeBridge?: object, codexBridge?: object, logger?: object}} [opts]
@@ -343,8 +398,10 @@ export class SiblingInjectBridge {
       } else if (isExplicit) {
         // 明示宛先: session_id (claude) / stream_id|thread_id (codex) で cwd 一致下に確定解決。
         // sendToStream は {status:"delivered"|"not_found"|"ambiguous"} を返す。
+        // request_id を渡すのは、bridge 側が配送 ID を **決定的に** 導出して同一依頼の再処理を
+        // 重複ガードで止められるようにするため (claude bridge は余分な引数を無視する)。
         const r = bridge?.sendToStream
-          ? await bridge.sendToStream(cwd, target_session_id, message, injectSource)
+          ? await bridge.sendToStream(cwd, target_session_id, message, injectSource, request_id)
           : { status: "not_found" }
         if (r.status === "delivered") {
           result = {
@@ -356,6 +413,8 @@ export class SiblingInjectBridge {
             accepted_via: r.accepted_via,
             item_id: r.item_id,
           }
+        } else if (r.status === "delivery_queued") {
+          result = queuedResult(r)
         } else if (r.status === "delivery_unconfirmed" || r.status === "delivery_failed") {
           result = {
             ok: false,
@@ -410,7 +469,7 @@ export class SiblingInjectBridge {
         //    あった。sendToCwd を status 返却にして解決と配送を 1 呼び出しに統合し、delivered_to は
         //    **実配送先 (r.session)** を返す。
         const r = bridge?.sendToCwd
-          ? await bridge.sendToCwd(cwd, text, injectSource)
+          ? await bridge.sendToCwd(cwd, text, injectSource, request_id)
           : { status: "not_found" }
         if (r.status === "delivered") {
           result = {
@@ -422,6 +481,8 @@ export class SiblingInjectBridge {
             accepted_via: r.accepted_via,
             item_id: r.item_id,
           }
+        } else if (r.status === "delivery_queued") {
+          result = queuedResult(r)
         } else if (r.status === "delivery_unconfirmed" || r.status === "delivery_failed") {
           result = {
             ok: false,
@@ -467,6 +528,7 @@ export class SiblingInjectBridge {
               delivery_id: result.delivery_id,
               delivery_state: result.delivery_state,
               durable_state: result.durable_state,
+              reason: result.reason,
             }
           : {
               error: result.error,
@@ -478,7 +540,9 @@ export class SiblingInjectBridge {
       result.ok
         ? result.delivery_state === "delivered"
           ? "sibling-inject delivered"
-          : "sibling-inject dispatched"
+          : result.delivery_state === "queued"
+            ? "sibling-inject queued"
+            : "sibling-inject dispatched"
         : "sibling-inject failed",
     )
     await this._writeResult(request_id, result)