@cocorograph/hub-agent 0.8.0 → 0.8.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cocorograph/hub-agent",
-  "version": "0.8.0",
+  "version": "0.8.1",
   "description": "Hub Hosted Cockpit のローカル常駐 agent。Hub と outbound WSS で接続し、ローカルの tmux/pty を中継する。",
   "type": "module",
   "license": "UNLICENSED",

package/src/claude-stream-bridge.mjs

@@ -85,6 +85,42 @@ const CHAT_RESIDENT_ENABLED = process.env.HUB_AGENT_CHAT_RESIDENT !== "0"
 const CHAT_RESIDENT_RESUME_ENABLED =
   process.env.HUB_AGENT_CHAT_RESIDENT_RESUME !== "0"
 
+/** 受理済み input_id リングの上限 (T06603, 2026-07-25)。queue snapshot に載せて
+ *  browser の「実行完了 vs 未配達」判定に使う。1 セッションの送信待ちは実運用で
+ *  数件〜十数件なので 256 あれば「表示中の楽観チップが評価対象から溢れる」ことは無い。
+ *  溢れた場合も誤って消すのではなく「未配達 (要再送)」側に倒れるため安全側。 */
+const ACCEPTED_INPUT_ID_RING_MAX = 256
+
+/** キュー snapshot の世代 (T06603, 2026-07-25)。
+ *
+ *  版番号 (seq) は **セッションオブジェクト単位**の連番なので、同一プロセス内でも
+ *  session が作り直される (resume / 再 attach) と 1 に戻る。一方 backend の写しキャッシュと
+ *  browser は単調な版を覚えているため、seq だけで比較すると新しい snapshot が永久に
+ *  「古い」と判定されて **表示が凍り付く**。そこで seq の上位に世代を置く。
+ *
+ *  ⚠️ **この値が保証するのは「同一プロセス内」の順序だけ** (cross-review round2)。値は
+ *  壁時計 ms で、プロセス内では必ず前回より大きい値を返す (同一 ms の衝突回避 + 時計が
+ *  巻き戻っても +1 で単調) が、**プロセス再起動をまたぐ順序は保証しない** (NTP のステップ
+ *  補正・手動時刻変更・別ホスト間の時計差で逆転しうる)。
+ *
+ *  そしてその保証は **不要** である (cross-review 3 巡目で設計確定)。browser は
+ *  ① 適用する queue_state を own stream の authoritative コピーだけに限る
+ *  ② attach (claude.ready) のたびに版番号の基準点を外す
+ *  という 2 点により、版番号空間を **1 回の attach の中に閉じている**。agent が再起動すれば
+ *  browser は必ず再 attach するので (agent.status online → reattachSameSession)、
+ *  プロセスを跨いで版を比較する場面が存在しない。
+ *
+ *  ゆえにここで壁時計以上の保証を作り込もうとしないこと。プロセス間の全順序を求めると
+ *  永続採番 (DB sequence) と session 所有権リースが必要になり、表示のために分散合意に近い
+ *  機構を抱えることになる (実際に版番号方式では「時計後退で永久 reject」「非権威 producer に
+ *  よる cache 汚染」の穴が連続して見つかり、設計ごと撤回した)。 */
+let _lastQueueGeneration = 0
+function nextQueueGeneration() {
+  const now = Date.now()
+  _lastQueueGeneration = now > _lastQueueGeneration ? now : _lastQueueGeneration + 1
+  return _lastQueueGeneration
+}
+
 /** MCP control 専用 query のアイドル破棄時間 (2026-06-03)。MCP サーバーは Claude Code
  *  設定 (アカウント単位) で全セッション共有のため、チャットセッションとは独立した
  *  「control 専用 query」を 1 本だけ遅延起動して状態取得・再認証・再接続を行う。
@@ -434,6 +470,24 @@ export class ClaudeStreamSession {
     /** 改修3: 直近 browser へ通知した queue 署名 (件数 + id 列)。変化時のみ emit する。
      *  空キューの署名 ("0:") で初期化し、空→空の冗長 emit を抑止する。 */
     this._lastEmittedQueueSig = "0:"
+    /** キュー snapshot の版番号 (T06603, 2026-07-25)。emit するたびに単調増加する。
+     *  browser は「受け取った snapshot が手元より新しいときだけ適用する」ことで、
+     *  ①遅延した relay / backend キャッシュの古い snapshot による巻き戻し
+     *  ②stream group と session group の二重配送
+     *  を無害化できる。**欠落の検知には使わない** (snapshot は全状態を含むので、
+     *  落ちた版があっても次に届いた版を適用すれば正しくなる)。落ちたまま次が来ない
+     *  ケースの救済は browser 側の pull (claude.queue.request) が担う。 */
+    this._queueStateSeq = 0
+    /** この session オブジェクトの世代 (T06603)。上記 nextQueueGeneration の説明を参照。
+     *  **同一プロセス内の順序のみ**を保証する (プロセス間は backend の接続フェンスが担う)。 */
+    this._queueGeneration = nextQueueGeneration()
+    /** 配達確認の再表明用 (T06603): この session が受理 (キュー投入 or 直接配送) した
+     *  input_id の直近リング。`claude.input.ack` は一度きりのユニキャストで、WS 切断が
+     *  30s を超えると ws-client の ctrl バッファから破棄され二度と再送されない。その結果
+     *  browser は「実際には届いて実行されたのに未配達扱い」で送信待ちチップを固着させる。
+     *  snapshot にこのリングを載せることで、ack を取りこぼした browser も
+     *  「キューに無い ＋ 受理済み ＝ 実行完了」と判定でき、pull だけで自己回復できる。 */
+    this._acceptedInputIds = []
 
     /** 連携カード種別タグ (Phase 2, 2026-07-23): ask-sibling/orchestrate 等の **別セッションからの
      *  注入** を、受け手画面で「青い自分バブル」ではなく専用の連携依頼カードで表示させるため、
@@ -950,6 +1004,19 @@ export class ClaudeStreamSession {
    * `accepted:false` のときは呼び出し元 (ClaudeStreamBridge.input) が nack を組み立てる。
    */
   async sendMessage(message, opts = {}) {
+    const result = await this._sendMessageInner(message, opts)
+    // 配達確認の再表明 (T06603): 受理 (= ack を返す) の記録を **1 箇所に集約**する。
+    // 投入経路は busy キュー / resident 直行 / fresh start / per-message と 4 通りあり、
+    // 各経路に散らすと新経路追加のたびに記録漏れが起き、browser が「未配達」と誤判定して
+    // チップを固着させる。ack を返す条件 (accepted) と同じ場所で 1 回だけ記録する。
+    const inputId =
+      typeof opts?.input_id === "string" && opts.input_id ? opts.input_id : null
+    if (inputId && result?.accepted) this._recordAcceptedInput(inputId)
+    return result
+  }
+
+  /** sendMessage 本体 (受理記録は呼び出し元の sendMessage が funnel で行う)。 */
+  async _sendMessageInner(message, opts = {}) {
     if (this._closed) return { accepted: false, reason: "queue_dead" }
     const prompt = extractPromptText(message)
     if (!prompt) return { accepted: false, reason: "empty_message" }
@@ -1227,7 +1294,7 @@ export class ClaudeStreamSession {
       return
     }
     const next = this._pendingMessages.shift()
-    this._emitQueueState([next.text])
+    this._emitQueueState([next.text], { startedIds: [next.id] })
     this._runPerMessage(next.text, { ultracode: next.ultracode === true }).catch(
       (err) => {
         this.logger?.error(
@@ -1245,10 +1312,37 @@ export class ClaudeStreamSession {
     // (楽観チップの id と一致させ、確認前キャンセルを可能にする)。無ければ従来の qN。
     const id =
       typeof inputId === "string" && inputId ? inputId : `q${++this._queueSeq}`
+    // 二重投入ガード (T06603, 2026-07-25): 同一 input_id が既にキューに居るなら積まない。
+    // main.mjs の in-flight dedup (claudeInflightByInputId) で通常は到達しないが、
+    // 「in-flight レジストリから外れた直後 (settle 済み・seen 登録前) の再送」等の窓では
+    // ここが最後の砦になる。id 重複を許すと ①同じ本文が 2 回実行される
+    // ②drain 後も同 id の項目がキューに残り送信待ちチップが消えない、の二重障害になる。
+    if (this._pendingMessages.some((m) => m.id === id)) {
+      this.logger?.info(
+        { stream_id: this.stream_id, id },
+        "duplicate input_id already queued, skipped",
+      )
+      return id
+    }
     this._pendingMessages.push({ id, text: prompt, ultracode: ultracode === true })
     return id
   }
 
+  /** 配達確認の再表明 (T06603): 受理済み input_id をリングへ記録する。
+   *  snapshot の `accepted` として browser へ載せ、ack 喪失時の自己回復に使う。 */
+  _recordAcceptedInput(inputId) {
+    if (typeof inputId !== "string" || !inputId) return
+    const at = this._acceptedInputIds.indexOf(inputId)
+    if (at !== -1) this._acceptedInputIds.splice(at, 1)
+    this._acceptedInputIds.push(inputId)
+    if (this._acceptedInputIds.length > ACCEPTED_INPUT_ID_RING_MAX) {
+      this._acceptedInputIds.splice(
+        0,
+        this._acceptedInputIds.length - ACCEPTED_INPUT_ID_RING_MAX,
+      )
+    }
+  }
+
   /** キャンセル機能 (0.6.26): browser から id 指定で送信待ちメッセージを 1 件取り消す。
    *  実行開始済み (既に drain された) メッセージは pending に残っていないので no-op になる。
    *  削除に成功したら queue_state を再 emit して送信待ちチップを更新する。 */
@@ -1269,9 +1363,30 @@ export class ClaudeStreamSession {
         { stream_id: this.stream_id, id, queued: this._pendingMessages.length },
         "queued message canceled",
       )
-      this._emitQueueState()
     }
-    return removed
+    // T06603 cross-review 5 巡目: **「消えた」だけでは取消成功と実行開始済みを区別できない**。
+    // drain の started フレームが落ちていると、browser は「キューに無い ＋ 受理済み」で
+    // 実行完了と判定してチップを消すが、ユーザーから見ると「取り消せた」ようにしか見えず、
+    // しかも started 欠落で発言バブルも出ていない。ここで結末を明示する。
+    //   - pending から除去できた            → cancelled
+    //   - pending に無い ＋ 受理済み        → already_started (もう走っている)
+    //   - pending に無い ＋ 未受理          → cancelled (先着キャンセルガードを張ったので、
+    //                                       後から届く同 id の input は破棄される)
+    const outcome = removed
+      ? "cancelled"
+      : this._acceptedInputIds.includes(id)
+        ? "already_started"
+        : "cancelled"
+    // ⚠️ T06603 cross-review 6 巡目: **snapshot をここで emit しない**。
+    // 従来はここで force 再表明していたが、そのフレームは outcome 応答より先に browser へ
+    // 届く (backend は agent の到着順に relay する)。先に届いた空 snapshot が「キューに無い
+    // ＋ 受理済み = 実行完了」の判定でチップを消してしまい、後続の outcome は対象不在で
+    // no-op になる → already_started のバブル補償が発火しない。
+    // 呼び出し元が outcome を送ってから flush() を呼ぶことで、配送順を確定させる。
+    return {
+      outcome,
+      flush: () => this._emitQueueState([], { force: true }),
+    }
   }
 
   /** 改修3: pending キューの現状を browser へ通知する (送信待ちチップ表示用)。
@@ -1285,6 +1400,12 @@ export class ClaudeStreamSession {
    *   署名が前回と同一でも browser がライブ配信を取りこぼしている可能性があるため。 */
   _emitQueueState(started = [], opts = undefined) {
     const force = opts?.force === true
+    // 実行開始した項目の input_id (started と parallel。T06603 cross-review major#2)。
+    // 本文テキストだけだと、同一本文を連投したときに 2 通目のユーザー発言バブルが
+    // 「既に同じ本文のバブルがある」と誤判定されて永久に出ない。id で突合させる。
+    const startedIds = Array.isArray(opts?.startedIds)
+      ? opts.startedIds
+      : started.map(() => null)
     const count = this._pendingMessages.length
     // 署名 = 件数 + id 列。件数が同じでもキャンセルで中身が変われば通知する。
     const sig = `${count}:${this._pendingMessages.map((m) => m.id).join(",")}`
@@ -1311,19 +1432,47 @@ export class ClaudeStreamSession {
       // 昇格させるため、ここで切り詰めると本文が欠ける。チップの省略表示は CSS 側で行う。
       // items は id 付きでキャンセルボタンの対象特定に使う (0.6.26)。
       this.onEvent?.({
-        type: "queue_state",
-        pending: count,
-        messages: this._pendingMessages.map((m) => m.text),
-        items: this._pendingMessages.map((m) => ({ id: m.id, text: m.text })),
+        ...this._buildQueueSnapshot(),
         started,
         // started と parallel。連携注入なら 'peer'|'orchestrator'、通常は null。
         startedSources,
+        // started と parallel。キュー由来なら input_id、注入等で id が無ければ null。
+        startedIds,
       })
     } catch {
       /* ignore */
     }
   }
 
+  /** キュー snapshot (T06603, 2026-07-25): 現在の権威キュー状態を 1 個のオブジェクトに
+   *  まとめる。ライブ配信 (_emitQueueState) と pull 応答 (claude.queue.request) の
+   *  **両方がこの 1 関数を通る**ため、経路によって形が食い違うことがない。
+   *  版番号 (seq) はここで採番する = 「browser へ出す状態が 1 つ進んだ」の唯一の定義。 */
+  _buildQueueSnapshot() {
+    this._queueStateSeq += 1
+    return {
+      type: "queue_state",
+      // 世代 (T06603 cross-review blocker): 再起動 / resume で seq が 1 に戻っても、
+      // 受け手が「古い」と誤判定しないよう上位キーとして必ず載せる。
+      generation: this._queueGeneration,
+      seq: this._queueStateSeq,
+      pending: this._pendingMessages.length,
+      messages: this._pendingMessages.map((m) => m.text),
+      items: this._pendingMessages.map((m) => ({ id: m.id, text: m.text })),
+      // 受理済み input_id (直近リング)。browser は「キューに無い ＋ ここに有る ＝ 実行完了」
+      // と判定して楽観チップを消し、「キューに無い ＋ ここにも無い ＝ 未配達」なら
+      // 消さずに再送導線を出す (無言削除の回帰を作らないための 2 軸判定)。
+      accepted: [...this._acceptedInputIds],
+    }
+  }
+
+  /** pull 型再同期 (T06603): 現在のキュー snapshot を返す (emit はしない)。
+   *  browser の claude.queue.request に対して claude.queue.response で返す。
+   *  純粋な読み取りなので Read-plane (並行レーン) から呼んでよい。 */
+  queueSnapshot() {
+    return this._buildQueueSnapshot()
+  }
+
   /** 連携カード種別 (Phase 2, cross-review major#1): **idle 直接送信経路**用。busy→queue→drain は
    *  _emitQueueState([text]) を通るが、idle 直接実行 (resident fresh start / per-message 即時) は
    *  started を出さないため、注入の source が startedSources に載らずカード化されない。ここで
@@ -1527,7 +1676,11 @@ export class ClaudeStreamSession {
       // codex-review minor: session が close 中 (outcome==="closed") は next を配送していない。
       // started 通知 (queue_state に [next.text] を載せる) を出すと未配送メッセージが「開始済み」に
       // 見えるため抑止する。closed は終端状態なので pending へ戻さず破棄でよい (session 撤去中)。
-      if (outcome !== "closed") this._emitQueueState([next.text])
+      // T06603 (2026-07-25): ただし破棄したこと自体は通知する (started 無しの force 再表明)。
+      // 従来は shift 済みなのに emit しないため、当該項目のチップが browser に残り続けていた。
+      if (outcome !== "closed")
+        this._emitQueueState([next.text], { startedIds: [next.id] })
+      else this._emitQueueState([], { force: true })
     } catch (err) {
       this._busy = false
       this._pendingMessages.unshift(next)
@@ -1709,7 +1862,7 @@ export class ClaudeStreamSession {
           toSDKUserMessage(next.text),
           next.ultracode === true,
         )
-        this._emitQueueState([next.text])
+        this._emitQueueState([next.text], { startedIds: [next.id] })
       }
       // マスク (2026-06-23): 常駐 query 終了後 (= CLI が jsonl を掴んでいない) のこの地点で、
       // closed 済みならオンディスク jsonl をマスクする。reap 経路は close() 内で実行済み。
@@ -1868,7 +2021,12 @@ export class ClaudeStreamSession {
   close() {
     this._closed = true
     // 改修3: 未処理の pending を破棄 (セッション終了後に drain しないため)。
+    const hadPending = this._pendingMessages.length > 0
     this._pendingMessages = []
+    // T06603 (2026-07-25): 破棄したことを必ず通知する。従来は無言で捨てていたため、
+    // 「セッションが畳まれた後もチップだけが残る」表示が残留していた。破棄は状態変化なので
+    // force で貫通させる (started=[] なのでバブル昇格は起きない)。
+    if (hadPending) this._emitQueueState([], { force: true })
     // 常駐 query は input キューを閉じて generator を終わらせ query を完走させる。
     if (this._inputQueue) this._inputQueue.close()
     this.abortTurn()
@@ -2932,11 +3090,26 @@ export class ClaudeStreamBridge extends EventEmitter {
     const s = this.sessions.get(stream_id)
     if (!s) {
       this.logger?.warn({ stream_id, id }, "claude.queue.cancel but stream missing")
-      return false
+      // T06603 cross-review 4/5 巡目: **結末を必ず browser へ返す**。browser はキャンセル
+      // 要求時にチップを消さず「取消中」の印を付けて権威の確認を待つ設計なので、
+      // 無応答だと印が外れる契機が無く「取消中」のまま固着する。
+      return { outcome: "stream_missing", flush: () => {} }
     }
     return s.cancelQueued(id)
   }
 
+  /** pull 型再同期 (T06603, 2026-07-25): browser の claude.queue.request に答えるため、
+   *  現在の権威キュー snapshot を返す。stream が無ければ null (browser 側は
+   *  「まだ attach していない」として扱い、ready 後に引き直す)。 */
+  queueSnapshot({ stream_id }) {
+    const s = this.sessions.get(stream_id)
+    if (!s) {
+      this.logger?.warn({ stream_id }, "claude.queue.request but stream missing")
+      return null
+    }
+    return { session_id: s.sessionId || null, snapshot: s.queueSnapshot() }
+  }
+
   /**
    * セッション停止 (graceful)。実行中ターンは中断せず完走させ、完走後に
    * onReap で Map から撤去する。アイドルなら即時撤去。

package/src/main.mjs

@@ -327,7 +327,11 @@ export function isReadOnlyRpc(type) {
   return (
     type === "claude.history.request" ||
     type === "claude.sessions.request" ||
-    type === "codex.sessions.request"
+    type === "codex.sessions.request" ||
+    // T06603 (2026-07-25): キュー snapshot の pull。in-memory 配列を読むだけで副作用が無く、
+    // かつ「直列キュー前方の重い処理で再同期が遅延する」と送信待ちチップの固着が長引く
+    // (再同期は固着を直すための経路なので、詰まりやすい経路に置いてはならない)。
+    type === "claude.queue.request"
   )
 }
 
@@ -2859,6 +2863,13 @@ const seenCodexChatInputIds = makeSeenInputIdRegistry()
 // Promise へ合流させる (settle 時に元の .then/.catch が 1 回だけ ack/nack を出す)。
 const codexInflightByInputId = new Map()
 
+// T06603 (2026-07-25): claude.input の **in-flight** dedup 用レジストリ (input_id -> Promise)。
+// 上の codex 版と同じ理由・同じ流儀。claude 側は sendMessage が resident query への
+// reconcile (applyFlagSettings の control request 往復) を await するため settle まで数秒
+// かかることがあり、その窓で ackWatchdog(5s) の再送が入ると `seen` 未登録のまま二重投入され、
+// 同一 input_id がキューに 2 件積まれて drain 後も 1 件残る (送信待ちチップが消えない)。
+const claudeInflightByInputId = new Map()
+
 /**
  * input_id 付き pty.data (tracked 入力) の処理。write 成功で pty.input.ack を返し、
  * stream 不在なら pty.error を返して browser の再 attach → 再送に繋げる。
@@ -2933,7 +2944,20 @@ export function handleClaudeChatInput(msg, ctx) {
     ctx.client.send({ type: "claude.input.ack", stream_id, input_id })
     return undefined
   }
-  return ctx.claudeBridge
+  if (input_id && claudeInflightByInputId.has(input_id)) {
+    // T06603 (2026-07-25): **処理中** の同一 input_id (browser の ackWatchdog が 5s で
+    // 再送してくるが、こちらはまだ settle していない窓)。codex 側は round4 major#1 で
+    // 対処済みだったが claude 側だけ欠けており、`seen` は settle 後にしか登録されないため
+    // 再送がそのまま二重投入されていた (同じ本文が 2 回実行され、かつ同一 id の項目が
+    // キューに 2 つ積まれて drain 後も 1 つ残る = 「実行されたのにキューから消えない」)。
+    // 既存 Promise へ合流させ、ack/nack は元の 1 回だけ出す。
+    ctx.logger?.info?.(
+      { stream_id, input_id },
+      "claude.input in-flight dedup (join, no re-dispatch)",
+    )
+    return claudeInflightByInputId.get(input_id)
+  }
+  const p = ctx.claudeBridge
     .input({
       stream_id,
       message: msg.message,
@@ -2972,6 +2996,13 @@ export function handleClaudeChatInput(msg, ctx) {
         })
       }
     })
+    .finally(() => {
+      // in-flight レジストリから外す (成功時は seen が以降の再送を dedup、
+      // 失敗時は再送で正当にリトライさせる)。codex 版と同じ流儀。
+      if (input_id) claudeInflightByInputId.delete(input_id)
+    })
+  if (input_id) claudeInflightByInputId.set(input_id, p)
+  return p
 }
 
 /**
@@ -3386,6 +3417,12 @@ async function dispatch(msg, ctx) {
             // 旧 agent にはこのフラグが無く、browser は楽観アイテムの×を出さない (ゴースト
             // 実行防止のフォールバック)。
             supports_queue_input_id: true,
+            // pull 型再同期 capability (T06603, 2026-07-25): この agent は
+            // claude.queue.request に claude.queue.response で答え、queue_state に
+            // 版番号 (seq) と受理済み input_id (accepted) を載せることを通知する。
+            // 旧 agent はこのフラグが無く、browser は従来の「配信到達に依存する」
+            // 挙動へフォールバックする (混在期間も安全に段階デプロイできる)。
+            supports_queue_snapshot: true,
           })
           // dispatch全体はWSメッセージ順を守る直列キュー上にある。ここで履歴I/Oをawaitすると
           // 同一接続のpermission/input等まで停止するため、readyの同期送信後は非同期でpushする。
@@ -3770,11 +3807,67 @@ async function dispatch(msg, ctx) {
         }
         return
       }
-      case "claude.queue.cancel":
+      case "claude.queue.cancel": {
         // 送信待ち (pending) メッセージを id 指定で取り消す (0.6.26)。
-        if (!ctx.claudeBridge) return
-        ctx.claudeBridge.cancelQueued({ stream_id: msg.stream_id, id: msg.id })
+        // T06603 cross-review 4 巡目: 取り消せなかった (stream 不在) ときは browser へ
+        // 失敗を返す。browser は要求時にチップを消さず「取消中」印を付けて権威の確認を
+        // 待つため、無応答だと印が外れず固着する。request_id をエコーして相関させる。
+        // T06603 cross-review 5 巡目: 結末 (cancelled / already_started / stream_missing) を
+        // **必ず** 返す。「pending から消えた」だけでは取消成功と実行開始済みを区別できず、
+        // 特に drain の started フレームを取りこぼしていると、browser は取消成功に見せかけた
+        // まま実行を続行してしまう (発言バブルも欠けたまま)。request_id + input_id で相関させる。
+        const cancelRes = {
+          type: "claude.queue.response",
+          stream_id: msg.stream_id,
+          request_id: msg.request_id || null,
+          input_id: msg.id || null,
+        }
+        if (!ctx.claudeBridge) {
+          ctx.client.send({ ...cancelRes, outcome: "stream_missing" })
+          return
+        }
+        const canceled = ctx.claudeBridge.cancelQueued({
+          stream_id: msg.stream_id,
+          id: msg.id,
+        })
+        // ⚠️ T06603 cross-review 6 巡目: **outcome を先に送る**。キュー snapshot の再表明を
+        // 先に流すと、backend は到着順に relay するため browser は空 snapshot で
+        // 「キューに無い ＋ 受理済み = 実行完了」と判定してチップを消し、後続の outcome は
+        // 対象不在で no-op になる (already_started のバブル補償が発火しない)。
+        ctx.client.send({
+          ...cancelRes,
+          outcome: canceled?.outcome || "stream_missing",
+        })
+        canceled?.flush?.()
+        return
+      }
+      case "claude.queue.request": {
+        // pull 型再同期 (T06603, 2026-07-25): browser が権威キュー snapshot を引きにくる。
+        // 従来キュー表示の是正手段は「agent が turn settle 毎に force 再送する queue_state」
+        // だけで、その配信が 1 通落ちると browser には自己修復の手段が無く送信待ちチップが
+        // 恒久固着した。ここで「いつでも引き直せる」経路を与えるのが根治の中核。
+        // 応答は要求元 stream へ返す (backend が cockpit_stream_<stream_id> へ relay)。
+        const queueReq = {
+          type: "claude.queue.response",
+          stream_id: msg.stream_id,
+          request_id: msg.request_id || null,
+        }
+        if (!ctx.claudeBridge) {
+          ctx.client.send({ ...queueReq, error: "stream_missing" })
+          return
+        }
+        const got = ctx.claudeBridge.queueSnapshot({ stream_id: msg.stream_id })
+        if (!got) {
+          ctx.client.send({ ...queueReq, error: "stream_missing" })
+          return
+        }
+        ctx.client.send({
+          ...queueReq,
+          session_id: got.session_id,
+          event: got.snapshot,
+        })
         return
+      }
       case "claude.detach":
         if (!ctx.claudeBridge) return
         ctx.claudeBridge.detach({ stream_id: msg.stream_id })