@cocorograph/hub-agent 0.8.25 → 0.8.27

package/package.json

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

package/src/claude-history-watch.mjs

@@ -8,15 +8,18 @@
  * 設計:
  * - 対象ファイルのバイトオフセットを記録し、増分だけ読んで行単位でパース
  * - fs.watch(file) の change イベントで増分読み取り (取りこぼし対策に軽いポーリング併用)
- * - DISPLAY_TYPES (user/assistant/system/result) の行だけ onEvent に渡す
+ * - historyEventFromLine が表示対象と判定した行だけ onEvent に渡す
+ *   (DISPLAY_TYPES の 4 種 + queue-operation から復元したタスク終端イベント)
  * - 各行の uuid を含めて渡す (frontend 側で重複排除に使う)
  * - ファイル不在時は出現を待つ (ディレクトリ監視はせず、ポーリングで存在チェック)
  */
 import { watch as fsWatch } from "node:fs"
 import { open, realpath, stat } from "node:fs/promises"
 
-// 履歴 hydrate と live watch で jsonl→SDK message 整形を共通化 (フィールド取りこぼし防止)。
-import { DISPLAY_TYPES, normalizeHistoryEvent } from "./claude-history.mjs"
+// 履歴 hydrate と live watch で「どの行を拾うか + jsonl→SDK message 整形」を共通化
+// (フィールド取りこぼし・片方だけ直すドリフトの防止)。queue-operation からの終端イベント
+// 合成もこの関数の中に閉じているので、live watch も自動的に同じ挙動になる。
+import { historyEventFromLine } from "./claude-history.mjs"
 
 // アダプティブ・ポーリング: 最後の追記から FAST_WINDOW_MS 以内は fast、以降は idle 周期。
 // ~/.claude が iCloud Drive への symlink のため fs.watch (FSEvents) が遅延/不発しやすく、
@@ -98,8 +101,8 @@ export function watchSessionFile({ filePath, onEvent, fromEnd = true, logger })
           } catch {
             continue
           }
-          if (!obj || !DISPLAY_TYPES.has(obj.type)) continue
-          const event = normalizeHistoryEvent(obj)
+          const event = historyEventFromLine(obj)
+          if (!event) continue
           try {
             onEvent(event)
           } catch (err) {

package/src/claude-history.mjs

@@ -10,6 +10,8 @@
  * - cwd エンコード規則: `/`, `.`, `_` などの非英数字を `-` 置換 (Claude CLI と同じ)
  * - 1 行 = 1 JSON。`type` が 'user' / 'assistant' / 'system' / 'result' のものだけ抽出
  *   (内部 type 'attachment' / 'last-prompt' / 'permission-mode' 等は UI 表示対象外)
+ *   例外として `queue-operation` の未配送タスク通知だけは終端イベントへ合成する
+ *   (synthesizeTaskNotificationEvent 参照。行そのものを表示するわけではない)
  * - 上限 MAX_HISTORY_LINES (デフォルト 500) で末尾から切る
  * - ファイル不在 (新規セッション) なら空配列を返す (エラーにしない)
  */
@@ -210,6 +212,149 @@ export function normalizeHistoryEvent(obj) {
   return event
 }
 
+const TASK_NOTIFICATION_MARKER = "<task-notification>"
+const TASK_NOTIFICATION_CLOSE = "</task-notification>"
+// ヘッダ領域の終わり。ここから先は自由文 (報告全文) なので、鍵と状態の抽出対象にしない。
+const TASK_NOTIFICATION_BODY_TAGS = ["<result>", "<summary>", "<note>"]
+// マスクを素通りする経路なので、長さでも歯止めを掛ける (実データの tool_use_id は 30〜40 字)。
+const MAX_TOOL_USE_ID_LEN = 200
+const MAX_STATUS_LEN = 64
+
+/**
+ * 「通知の体裁を持つのに合成しなかった」件数。**内容は一切持たない**。
+ *
+ * ⚠️ これは観測窓であって判定ではない。封筒の検査を厳しくすると、Claude CLI が将来ラッパー・
+ * 空白・タグ順を変えたときに**正当な通知まで落ちて幽霊カードが静かに戻る**。その「静かな戻り」に
+ * 気づけるよう、件数だけを数える (内容をログへ出すと、まさに伏せ字を回避したい本文が漏れる)。
+ */
+let taskNotificationEnvelopeDrops = 0
+
+/** 封筒の検査で合成しなかった**累計**件数を返す (テスト用)。 */
+export function getTaskNotificationEnvelopeDrops() {
+  return taskNotificationEnvelopeDrops
+}
+
+/** 前回 drain 以降に増えた分を返して 0 に戻す (ログへ出す側が使う)。 */
+let taskNotificationEnvelopeDropsReported = 0
+export function drainTaskNotificationEnvelopeDrops() {
+  const delta = taskNotificationEnvelopeDrops - taskNotificationEnvelopeDropsReported
+  taskNotificationEnvelopeDropsReported = taskNotificationEnvelopeDrops
+  return delta
+}
+
+/** `<tag>…</tag>` の **最初の** 中身を返す。見つからなければ ""。 */
+function firstTagValue(text, tag) {
+  const open = `<${tag}>`
+  const start = text.indexOf(open)
+  if (start < 0) return ""
+  const from = start + open.length
+  const end = text.indexOf(`</${tag}>`, from)
+  if (end < 0) return ""
+  return text.slice(from, end).trim()
+}
+
+/**
+ * `queue-operation` 行に埋まっている「タスク終端の宣言」を、画面が扱える最小イベントへ
+ * 合成する (2026-08-05)。
+ *
+ * ## なぜ必要か
+ * サブエージェント / バックグラウンドタスクの完了通知は、CLI がまず **キューへ積む**
+ * (`type:"queue-operation", operation:"enqueue"`) 形で jsonl に書かれ、その後キューから
+ * 取り出された時に初めて `type:"user"` の行として配送される。ところが配送前に
+ * セッションが閉じる・`remove` されるなどで **user 行が書かれないまま終わる**ケースが多く
+ * (2026-08-05 に手元の全 jsonl 2,136 本を走査した実測で、終端宣言 788 件 (tool_use_id
+ * ユニーク) のうち 332 件 = 42% が未配送。内訳 completed 285 / failed 29 / killed 18)、
+ * 画面側の台帳はそのカードを
+ * 「実行中」のまま抱え続ける (= リロードで残る幽霊カード)。
+ *
+ * enqueue 行の `content` には `<status>` と `<tool-use-id>` が入っており、これは
+ * **CLI 自身が書いた終端宣言**なので、時間で推測せずに終端を復元できる。
+ *
+ * ## ⚠️ 載せてよいのは「鍵」と「状態」と「時刻」だけ
+ * `<result>` にはサブエージェントの報告全文が入る (実データで確認済み)。しかしマスク処理
+ * `maskMessageObject` (src/tool-result-mask.mjs:165-168) は `const message = obj.message;
+ * if (!message …) return obj` で **即 return** するため、`message` を持たないこの合成イベントは
+ * **マスクを素通りする**。よって `<result>` / `<summary>` / `<note>` / `<output-file>` の本文は
+ * 絶対に載せない (載せると秘匿情報がマスクされないまま browser へ流れる)。`<task-id>` も
+ * 画面側が使っていないので載せない。
+ *
+ * 画面側 (Hub 本体 frontend/lib/cockpit/agentRequest.ts の applyTaskNotificationEvent) は
+ * `type:"system" / subtype:"task_notification" / tool_use_id / status` を終端として処理し、
+ * `requireRegistered: true` なので未知の tool_use_id で幻のカードが増えることはない。
+ * `timestamp` は猶予表示の起点になるので必ず載せる。
+ *
+ * @param {Record<string, unknown>} obj jsonl 1 行をパースした生 object
+ * @returns {Record<string, unknown>|null} 合成イベント。対象外なら null
+ */
+export function synthesizeTaskNotificationEvent(obj) {
+  if (!obj || obj.type !== "queue-operation" || obj.operation !== "enqueue") return null
+  const content = obj.content
+  if (typeof content !== "string") return null
+  const trimmed = content.trim()
+  // ⚠️ **「通知を含む」ではなく「通知そのものである」ことを要求する** (2026-08-05 のクロス
+  // レビュー minor)。含むだけで拾うと、**利用者が通知の文面を本文へ貼っただけの入力**を終端
+  // 宣言として扱ってしまう。実測でも、このレビューのやり取り自体がキューに積まれ、状態として
+  // 日本語の文章を、鍵として 215 字の文字列を拾っていた (実データ 1,692 行中 2 件)。
+  // 実データでは正規の通知 1,648 件すべてが `<task-notification>` で始まり、閉じタグを持つ。
+  if (!trimmed.startsWith(TASK_NOTIFICATION_MARKER)) {
+    if (trimmed.includes(TASK_NOTIFICATION_MARKER)) taskNotificationEnvelopeDrops += 1
+    return null
+  }
+  // ⚠️ 閉じタグは **最後の出現**を採る。最初の出現にすると、`<result>` の本文が
+  // `</task-notification>` を引用しているだけで封筒が途中で切れ、正当な通知を落とす。
+  const closeAt = trimmed.lastIndexOf(TASK_NOTIFICATION_CLOSE)
+  if (closeAt < TASK_NOTIFICATION_MARKER.length) {
+    taskNotificationEnvelopeDrops += 1
+    return null
+  }
+  // 閉じタグの後ろに本文が続くものは通知そのものではない (貼り付けの typical な形)。
+  if (trimmed.slice(closeAt + TASK_NOTIFICATION_CLOSE.length).trim()) {
+    taskNotificationEnvelopeDrops += 1
+    return null
+  }
+  const block = trimmed.slice(TASK_NOTIFICATION_MARKER.length, closeAt)
+  // 鍵と状態は **ヘッダ領域** (自由文の本文タグより前) からだけ採る。本文に紛れたタグや、
+  // 正規の `<status>` が欠けたときに本文側のタグを拾い上げることを防ぐ。
+  let headerEnd = block.length
+  for (const tag of TASK_NOTIFICATION_BODY_TAGS) {
+    const at = block.indexOf(tag)
+    if (at >= 0 && at < headerEnd) headerEnd = at
+  }
+  const header = block.slice(0, headerEnd)
+  const tool_use_id = firstTagValue(header, "tool-use-id")
+  const status = firstTagValue(header, "status")
+  // 鍵か状態が欠けた通知は画面側でも無視されるので、流すだけ無駄 → 合成しない。
+  if (!tool_use_id || !status) {
+    taskNotificationEnvelopeDrops += 1
+    return null
+  }
+  // マスクを素通りする経路なので、長さでも歯止めを掛ける (異常に長い値は封筒が壊れたサイン)。
+  if (tool_use_id.length > MAX_TOOL_USE_ID_LEN || status.length > MAX_STATUS_LEN) {
+    taskNotificationEnvelopeDrops += 1
+    return null
+  }
+  const event = { type: "system", subtype: "task_notification", tool_use_id, status }
+  if (obj.timestamp !== undefined) event.timestamp = obj.timestamp
+  return event
+}
+
+/**
+ * jsonl 1 行 (パース済み) を UI 表示用イベントに変換する。表示対象外なら null。
+ *
+ * ⚠️ **認識と合成はこの 1 関数に閉じる**。履歴 hydrate (readSessionHistory) と live watch
+ * (claude-history-watch.mjs) の両方がここを通ること。過去、行のフィルタ / 整形が 2 箇所に
+ * 分散して片方だけ更新されるドリフトが起きているため (normalizeHistoryEvent の注記参照)。
+ *
+ * @param {Record<string, unknown>} obj
+ * @returns {Record<string, unknown>|null}
+ */
+export function historyEventFromLine(obj) {
+  if (!obj || typeof obj !== "object") return null
+  // 1 行から出すイベントは最大 1 個 (画面側の終端は先勝ちなので重複は無害だが、増やさない)。
+  if (DISPLAY_TYPES.has(obj.type)) return normalizeHistoryEvent(obj)
+  return synthesizeTaskNotificationEvent(obj)
+}
+
 /**
  * cwd 文字列を Claude Code の project dir 名に変換する。
  * 例: `/Users/kaz/hub/projects/D00585_partition-lab`
@@ -297,10 +442,10 @@ export async function readSessionHistory(filePath, { maxLines = MAX_HISTORY_LINE
     } catch {
       continue
     }
-    if (!obj || typeof obj !== "object") continue
-    if (!DISPLAY_TYPES.has(obj.type)) continue
-    // SDK message と同じ shape にする (余分な meta は落とす)。整形は共通関数に集約。
-    let event = normalizeHistoryEvent(obj)
+    // SDK message と同じ shape にする (余分な meta は落とす)。認識・整形・合成は
+    // historyEventFromLine 1 箇所に集約 (live watch も同じ関数を通る)。
+    let event = historyEventFromLine(obj)
+    if (!event) continue
     // 秘匿情報 / 非公開スキルプロンプト本文を hydrate 時にも伏せる (古いセッション再表示対策)。
     if (MASK_ENABLED) event = maskMessageObject(event, toolNames)
     events.push(event)

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/main.mjs

@@ -54,6 +54,7 @@ import { enforceTotalLiveBound } from "./warm-bounds-total.mjs"
 import { UploadManager } from "./claude-upload.mjs"
 import { requestSelfUninstall } from "./service-install.mjs"
 import {
+  drainTaskNotificationEnvelopeDrops,
   fetchSessionHistory,
   listSessions,
 } from "./claude-history.mjs"
@@ -4401,6 +4402,18 @@ async function dispatch(msg, ctx) {
           projectsRoot,
           logger: ctx.logger,
         })
+        // ⚠️ **観測窓を必ずどこかから読む**。タスク終端通知の封筒検査は、Claude CLI が
+        // ラッパー・タグ順・空白を変えると正当な通知まで落とし、**幽霊カードが静かに戻る**。
+        // 誰も読まないカウンタは「対策した気になるだけの飾り」になる (バンドル自己更新の
+        // 通知で発火率 0 の検査を残していた前例あり)。件数だけを出す (中身は伏せ字を
+        // 素通りするので絶対に出さない)。
+        const envelopeDrops = drainTaskNotificationEnvelopeDrops()
+        if (envelopeDrops > 0) {
+          ctx.logger?.info?.(
+            { drops: envelopeDrops },
+            "history: task-notification の封筒検査で合成しなかった行があります (CLI の形式変更なら通知の復元が効かなくなります)",
+          )
+        }
         ctx.client.send({
           type: "claude.history.response",
           stream_id,

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)