commandmate 0.31.3 → 0.32.1

package/dist/lib/detection/status-reason.d.ts

@@ -61,6 +61,34 @@ export declare const STATUS_REASON: {
      * `Type to search models...` box.
      */
     readonly COMMAND_CODE_SELECTION_LIST: "command_code_selection_list";
+    /**
+     * Issue #2369: a Command Code overlay that only Esc leaves.
+     *
+     * `/usage` opens a read-only panel — a plan header, two usage meters, a
+     * breakdown URL — whose last row is `Press Esc to close`. There is no
+     * highlight to move, no numbered option and no confirm key; the ONE thing the
+     * screen accepts is the dismiss.
+     *
+     * Distinct from {@link STATUS_REASON.COMMAND_CODE_SELECTION_LIST} because the
+     * two screens want different controls, and that is the whole of this Issue:
+     * before it, this panel matched no rule at all, reached the `default` floor
+     * and so raised `isUnclassifiedActive` — which the chat surface answers with
+     * `TerminalEscapeHatch` plus `PromptAnswerKeys`, eighteen buttons (arrows,
+     * Enter, Esc, `1`-`9`, `y`, `n`) of which exactly one does anything. Reporting
+     * the selection-list token instead would put the arrow pad on the card and
+     * tell an operator reading `capture --json` that a moving highlight had been
+     * read off a panel that has none.
+     *
+     * Deliberately NOT a member of `SELECTION_LIST_REASONS`
+     * (`lib/detection/status-detector.ts`): that set is what `isSelectionListActive`
+     * — and therefore the arrow pad — is derived from. The flag this one feeds is
+     * `isDismissablePanelActive`, published beside it.
+     *
+     * The vocabulary is Command Code's alone for now (方針書 §4 D2's tool-by-tool
+     * rule): the SHAPE "an overlay whose footer offers only a dismiss" is general,
+     * the sentence that identifies it was measured on one tool.
+     */
+    readonly COMMAND_CODE_DISMISSABLE_PANEL: "command_code_dismissable_panel";
     readonly COPILOT_SELECTION_LIST: "copilot_selection_list";
     readonly CODEX_SELECTION_LIST: "codex_selection_list";
     /** Issue #1017: Codex pager / edit-previous (transcript) mode. */

package/dist/lib/detection/status-reason.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"status-reason.d.ts","sourceRoot":"","sources":["../../../src/lib/detection/status-reason.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH;;;GAGG;AACH,eAAO,MAAM,aAAa;;;;;IAKxB;;;;;;;;;;;;;;;;;;OAkBG;;IAEH,6EAA6E;;;IAG7E;;;;;;;;;;;;;;;;OAgBG;;;;IAIH,kEAAkE;;IAElE,6EAA6E;;;;;;IAM7E;;;;;;;;;;;;;;;OAeG;;IAEH;;;;;;;;;;;;;;;OAeG;;;CAGK,CAAC"}
+{"version":3,"file":"status-reason.d.ts","sourceRoot":"","sources":["../../../src/lib/detection/status-reason.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH;;;GAGG;AACH,eAAO,MAAM,aAAa;;;;;IAKxB;;;;;;;;;;;;;;;;;;OAkBG;;IAEH,6EAA6E;;;IAG7E;;;;;;;;;;;;;;;;OAgBG;;IAEH;;;;;;;;;;;;;;;;;;;;;;;;;;OA0BG;;;;IAIH,kEAAkE;;IAElE,6EAA6E;;;;;;IAM7E;;;;;;;;;;;;;;;OAeG;;IAEH;;;;;;;;;;;;;;;OAeG;;;CAGK,CAAC"}

package/dist/lib/detection/status-reason.js

@@ -64,6 +64,34 @@ exports.STATUS_REASON = {
      * `Type to search models...` box.
      */
     COMMAND_CODE_SELECTION_LIST: 'command_code_selection_list',
+    /**
+     * Issue #2369: a Command Code overlay that only Esc leaves.
+     *
+     * `/usage` opens a read-only panel — a plan header, two usage meters, a
+     * breakdown URL — whose last row is `Press Esc to close`. There is no
+     * highlight to move, no numbered option and no confirm key; the ONE thing the
+     * screen accepts is the dismiss.
+     *
+     * Distinct from {@link STATUS_REASON.COMMAND_CODE_SELECTION_LIST} because the
+     * two screens want different controls, and that is the whole of this Issue:
+     * before it, this panel matched no rule at all, reached the `default` floor
+     * and so raised `isUnclassifiedActive` — which the chat surface answers with
+     * `TerminalEscapeHatch` plus `PromptAnswerKeys`, eighteen buttons (arrows,
+     * Enter, Esc, `1`-`9`, `y`, `n`) of which exactly one does anything. Reporting
+     * the selection-list token instead would put the arrow pad on the card and
+     * tell an operator reading `capture --json` that a moving highlight had been
+     * read off a panel that has none.
+     *
+     * Deliberately NOT a member of `SELECTION_LIST_REASONS`
+     * (`lib/detection/status-detector.ts`): that set is what `isSelectionListActive`
+     * — and therefore the arrow pad — is derived from. The flag this one feeds is
+     * `isDismissablePanelActive`, published beside it.
+     *
+     * The vocabulary is Command Code's alone for now (方針書 §4 D2's tool-by-tool
+     * rule): the SHAPE "an overlay whose footer offers only a dismiss" is general,
+     * the sentence that identifies it was measured on one tool.
+     */
+    COMMAND_CODE_DISMISSABLE_PANEL: 'command_code_dismissable_panel',
     COPILOT_SELECTION_LIST: 'copilot_selection_list',
     CODEX_SELECTION_LIST: 'codex_selection_list',
     /** Issue #1017: Codex pager / edit-previous (transcript) mode. */

package/dist/server/locales/en/worktree.json

@@ -459,6 +459,7 @@
         "bannerLabel": "You can act on this here",
         "reasonPager": "A pager is open. Scroll it and quit it from here, with the screen below in view.",
         "reasonSelectionList": "A selection list is open. Move and confirm from here, with the screen below in view.",
+        "reasonDismissablePanel": "This screen only closes. Press Esc here, with it in view below.",
         "reasonUnclassified": "Chat can't tell what this screen is. It is shown as-is below, so you can drive it with the keys here.",
         "reasonPromptUnreadable": "Waiting for an answer, and the options couldn't be read. Read the screen below and answer with a number or y/n.",
         "openTerminal": "Open terminal",
@@ -919,6 +920,11 @@
         "toolbarLabel": "Dialog answer keys",
         "caption": "Answer"
     },
+    "dismissPanelKeys": {
+        "toolbarLabel": "Close this screen",
+        "close": "Close (Esc)",
+        "closeAria": "Close this screen (Esc)"
+    },
     "selectionKeys": {
         "numbersToolbarLabel": "Option number keys",
         "numbersCaption": "Pick",
@@ -1018,6 +1024,23 @@
         "degradedTitle": "Structured events are not arriving",
         "healthyTitle": "Receiving structured events"
     },
+    "relay": {
+        "badgeOwed": "Reply due to {alias}",
+        "badgeOwedMany": "Replies due ({count})",
+        "badgeAwaiting": "Waiting on {alias}",
+        "badgeAwaitingMany": "Waiting on {count} replies",
+        "badgePrompt": "Confirmation reported",
+        "owedTitle": "This session owes a delegated reply. It is delivered automatically when the turn ends.",
+        "awaitingTitle": "This session is waiting for a delegated reply. It arrives in the composer as a relay message.",
+        "promptTitle": "The other session stopped on a confirmation; the requester has been told.",
+        "stripAwaiting": "Delegated to {alias}; waiting for the reply.",
+        "stripAwaitingMany": "Waiting for {count} delegated replies.",
+        "stripPrompt": "{alias} is waiting for a confirmation.",
+        "stripOwed": "Owed to {alias}: this session's reply is delivered when the turn ends.",
+        "historyBadge": "relay",
+        "historyBadgeTitle": "Delivered by another agent session (Issue #2377 relay).",
+        "historyCount": "{count} relayed message(s) in view"
+    },
     "agentModel": {
         "label": "Model",
         "modelLabel": "Model: {model}",

package/dist/server/locales/ja/worktree.json

@@ -459,6 +459,7 @@
         "bannerLabel": "ここで操作できます",
         "reasonPager": "ページャ表示中です。下の画面を見ながら、ここでスクロールと終了ができます。",
         "reasonSelectionList": "選択リストが開いています。下の画面を見ながら、ここで項目の移動と決定ができます。",
+        "reasonDismissablePanel": "閉じるだけの画面です。下の画面を見ながら、ここで Esc を押せます。",
         "reasonUnclassified": "チャットでは種類を判別できない画面です。下にそのまま表示しているので、ここでキーを送って操作できます。",
         "reasonPromptUnreadable": "応答待ちですが選択肢を読み取れませんでした。下の画面を見て、番号か y／n で答えられます。",
         "openTerminal": "ターミナルで確認",
@@ -919,6 +920,11 @@
         "toolbarLabel": "ダイアログへの回答キー",
         "caption": "回答"
     },
+    "dismissPanelKeys": {
+        "toolbarLabel": "この画面を閉じる",
+        "close": "閉じる (Esc)",
+        "closeAria": "この画面を閉じる (Esc)"
+    },
     "selectionKeys": {
         "numbersToolbarLabel": "選択肢の番号キー",
         "numbersCaption": "選択",
@@ -1018,6 +1024,23 @@
         "degradedTitle": "構造化イベントが届いていません",
         "healthyTitle": "構造化イベントを受信中"
     },
+    "relay": {
+        "badgeOwed": "{alias} へ返信予定",
+        "badgeOwedMany": "返信予定 {count} 件",
+        "badgeAwaiting": "{alias} の返信待ち",
+        "badgeAwaitingMany": "返信待ち {count} 件",
+        "badgePrompt": "確認待ちを通知済み",
+        "owedTitle": "このセッションは委任された返信を抱えています。ターン完了時に自動で届きます。",
+        "awaitingTitle": "このセッションは委任した返信を待っています。届くとコンポーザーに relay メッセージとして入ります。",
+        "promptTitle": "相手セッションが確認待ちで止まり、依頼元へ通知済みです。",
+        "stripAwaiting": "{alias} へ委任、返信待ち",
+        "stripAwaitingMany": "返信待ち {count} 件",
+        "stripPrompt": "{alias} が確認待ち",
+        "stripOwed": "{alias} へ返信予定: ターン完了時に届きます",
+        "historyBadge": "relay",
+        "historyBadgeTitle": "別のエージェントセッションから届いたメッセージです（Issue #2377 relay）。",
+        "historyCount": "表示範囲に relay メッセージが {count} 件"
+    },
     "agentModel": {
         "label": "モデル",
         "modelLabel": "モデル: {model}",

package/dist/server/src/lib/auto-yes-poller.js

@@ -59,7 +59,7 @@ exports.getAutoYesPollerCompositeKeys = getAutoYesPollerCompositeKeys;
 exports.stopAutoYesPollingByWorktree = stopAutoYesPollingByWorktree;
 exports.isAnyPollerActiveForWorktree = isAnyPollerActiveForWorktree;
 const cli_session_1 = require("./session/cli-session");
-const prompt_detector_1 = require("./detection/prompt-detector");
+const response_checker_1 = require("./polling/response-checker");
 const auto_yes_resolver_1 = require("./polling/auto-yes-resolver");
 const auto_yes_policy_1 = require("./polling/auto-yes-policy");
 const auto_yes_suppression_state_1 = require("./polling/auto-yes-suppression-state");
@@ -281,12 +281,27 @@ function processStopConditionDelta(compositeKey, pollerState, cleanOutput) {
 async function detectAndRespondToPrompt(worktreeId, pollerState, cliToolId, cleanOutput, precomputedLines, instanceId) {
     const compositeKey = (0, auto_yes_state_1.buildCompositeKey)(worktreeId, cliToolId, instanceId);
     try {
-        // 1. Detect prompt
-        const promptOptions = (0, cli_patterns_1.buildDetectPromptOptions)(cliToolId);
-        const promptDetection = (0, prompt_detector_1.detectPrompt)(cleanOutput, {
-            ...promptOptions,
-            ...(precomputedLines && { precomputedLines }),
-        });
+        // 1. Detect prompt.
+        //
+        // Issue #2368: through `detectPromptOnCleanFrame`, the entry the status
+        // path and the response poller already read frames on — NOT the generic
+        // `detectPrompt` this used to call. #2364 gave agy its own dialog reader and
+        // wired it into three of the four consumers of one frame; this poller was
+        // the fourth, and it stayed on the generic multiple-choice parser. That
+        // parser folds a wrapped option label only when the continuation row is
+        // indented, short or path-shaped (#372, for codex prose), and agy prints the
+        // approved command INSIDE the label and wraps it at column 0 — so every
+        // Bash approval read as `isPrompt: false` here and Auto-Yes answered
+        // nothing, while `/current-output` published the same screen as a waiting
+        // four-option prompt. Everything after this point is unchanged: the
+        // duplicate key (#306), codex's launch dialogs (#1829), the dialog gate
+        // (#1928) and the contract policy (#1547) all still run. What changed is
+        // only whether the frame can be READ.
+        //
+        // `cleanOutput` is handed over already stripped, and the clean-frame entry
+        // is the one that does not strip again (`stripBoxDrawing` is not
+        // idempotent), so this poller and the response poller judge identical text.
+        const promptDetection = (0, response_checker_1.detectPromptOnCleanFrame)(cleanOutput, cliToolId, precomputedLines);
         if (!promptDetection.isPrompt || !promptDetection.promptData) {
             pollerState.lastAnsweredPromptKey = null;
             pollerState.lastAnsweredAt = null;
@@ -312,7 +327,7 @@ async function detectAndRespondToPrompt(worktreeId, pollerState, cliToolId, clea
         // '2', '1' — each without a trailing Enter), but only during startSession,
         // while this poller runs on its own 2s phase for the life of the session.
         // Whichever sees the dialog first decides, so the fix is to leave them all
-        // to the tool. Auto-answer layer only: detectPrompt above still reports the
+        // to the tool. Auto-answer layer only: the detection above still reports the
         // prompt, so the human keeps seeing the screen and the response poller
         // still notifies them about it.
         const launchDialog = cliToolId === 'codex' ? (0, cli_patterns_1.getCodexLifecycleDialog)(cleanOutput) : null;
@@ -334,7 +349,7 @@ async function detectAndRespondToPrompt(worktreeId, pollerState, cliToolId, clea
             return 'no_answer';
         }
         // 3.5. Issue #1928 (§4 D1 decision 4): the generic numbered-list inference is
-        // not enough to send an answer. `detectPrompt` above judges the ROWS, and the
+        // not enough to send an answer. The detection above judges the ROWS, and the
         // rows of an agent's own reply can be indistinguishable from a dialog's --
         // opencode 1.18 answering "list three options and ask which one" is the
         // reported case (#1896), and the `1` this poller sent in reply was not
@@ -369,8 +384,8 @@ async function detectAndRespondToPrompt(worktreeId, pollerState, cliToolId, clea
             return 'no_answer';
         }
         // 4. Resolve auto answer under the execution contract's policy (Issue #1547).
-        // Auto-Yes calls detectPrompt directly instead of going through
-        // status-detector, so this is the only place the policy can gate an
+        // Auto-Yes reads the frame itself instead of going through status-detector
+        // (it shares the reader, not the verdict), so this is the only place the policy can gate an
         // auto-answer: a prompt the policy withholds is left for a human, and the
         // response poller's prompt path (WS broadcast + Web Push, see
         // polling/response-checker.ts) is what tells them it is waiting.

package/dist/server/src/lib/db/chat-db.js

@@ -6,7 +6,7 @@
  * Issue #479: Extracted from db.ts for single-responsibility separation
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.MODEL_CHANGE_REQUEST_ID_PREFIX = exports.UNKEYED_USER_MESSAGE_LIMIT = exports.ACTIVE_FILTER = void 0;
+exports.RELAY_SYSTEM_REQUEST_ID_PREFIX = exports.RELAY_REQUEST_ID_PREFIX = exports.MODEL_CHANGE_REQUEST_ID_PREFIX = exports.USER_TURN_CANDIDATE_LIMIT = exports.ACTIVE_FILTER = void 0;
 exports.getLastAssistantMessageAt = getLastAssistantMessageAt;
 exports.createMessage = createMessage;
 exports.updateMessageContent = updateMessageContent;
@@ -29,6 +29,11 @@ exports.updatePromptData = updatePromptData;
 exports.markPendingPromptsAsAnswered = markPendingPromptsAsAnswered;
 exports.recordAnsweredPrompt = recordAnsweredPrompt;
 exports.createModelChangeMessage = createModelChangeMessage;
+exports.relayRequestId = relayRequestId;
+exports.parseRelayRequestId = parseRelayRequestId;
+exports.getLastUserMessageForInstance = getLastUserMessageForInstance;
+exports.getLatestOpenPromptMessage = getLatestOpenPromptMessage;
+exports.createRelaySystemMessage = createRelaySystemMessage;
 const crypto_1 = require("crypto");
 const logger_1 = require("../../lib/logger");
 const logger = (0, logger_1.createLogger)('chat-db');
@@ -245,16 +250,17 @@ function findMessageByRequestId(db, worktreeId, requestId) {
     return row ? mapChatMessage(row) : null;
 }
 /**
- * How many candidate rows {@link findUnkeyedUserMessages} returns.
+ * How many candidate rows a user-row candidate lookup returns.
  *
  * The caller compares content in JavaScript, so this bounds the work rather than
  * the correctness. Twenty is far above the number of user rows one instance can
  * accumulate inside the caller's few-minute window and still small enough that
  * the query is never the expensive part of a poll.
  */
-exports.UNKEYED_USER_MESSAGE_LIMIT = 20;
+exports.USER_TURN_CANDIDATE_LIMIT = 20;
 /**
- * User rows for one instance that no producer has claimed yet (Issue #2196).
+ * User rows for one instance that no producer has claimed yet (Issue #2196) —
+ * and, on request, the one keyed row that is a duplicate of one (Issue #2392).
  *
  * The lookup behind "the operator's input is already in History — `/send` put it
  * there". A row qualifies when it is this instance's, is a `user` row, sits in
@@ -278,15 +284,40 @@ exports.UNKEYED_USER_MESSAGE_LIMIT = 20;
  * `ACTIVE_FILTER` applies: an archived row has been cleared out of History, and
  * adopting one would key a turn to a row nobody can see.
  *
+ * ## The one keyed row this will hand back, and only when asked
+ *
+ * Issue #2392. `relay-delivery` writes the answer it types into the requesting
+ * session's composer as a `relay` user row keyed `relay:<ledgerId>`, and that
+ * session's own transcript reader then reads the delivered body back as a prompt
+ * it was handed — 662ms later, measured — and duplicated it, because the row it
+ * should have recognised was keyed and therefore invisible here.
+ *
+ * `includeRelayDelivered` widens the predicate to `request_id IS NULL OR (a
+ * relay row keyed `relay:…`)`. It is an OR and an opt-in, so no existing caller
+ * sees a row it did not see before; `message_type` and the key prefix are both
+ * required, because a relay *prompt* delivery is a `relay` row with no key at
+ * all and stays an ordinary unkeyed candidate, while a `relay-sys:` row is
+ * transcript furniture that is not the delivery.
+ *
+ * **A row that comes back with a `requestId` must not be claimed.** That key is
+ * how `relay-service`'s `findParentRelayHops` reads the ledger back out of the
+ * row (#2387), so re-pointing one at a transcript key would silently un-chain
+ * every relay opened from the session. {@link setMessageRequestId}'s
+ * `request_id IS NULL` predicate refuses the write in any case; the caller is
+ * expected to branch on `requestId` rather than rely on that.
+ *
  * @returns Candidate rows, newest first
  */
 function findUnkeyedUserMessages(db, query) {
+    const keyFilter = query.includeRelayDelivered
+        ? `AND (request_id IS NULL OR (message_type = 'relay' AND request_id LIKE ?))`
+        : 'AND request_id IS NULL';
     const stmt = db.prepare(`
     SELECT id, worktree_id, role, content, summary, timestamp, log_file_name, request_id, message_type, prompt_data, cli_tool_id, instance_id, archived
     FROM chat_messages
     WHERE worktree_id = ?
       AND role = 'user'
-      AND request_id IS NULL
+      ${keyFilter}
       AND COALESCE(cli_tool_id, 'claude') = ?
       AND COALESCE(instance_id, cli_tool_id, 'claude') = ?
       AND timestamp >= ? AND timestamp <= ?
@@ -294,8 +325,14 @@ function findUnkeyedUserMessages(db, query) {
     ORDER BY timestamp DESC
     LIMIT ?
   `);
-    const rows = stmt.all(query.worktreeId, query.cliToolId, query.instanceId, query.fromMs, query.toMs, query.limit ?? exports.UNKEYED_USER_MESSAGE_LIMIT);
-    return rows.map(mapChatMessage);
+    const rows = stmt.all(query.worktreeId, ...(query.includeRelayDelivered ? [`${exports.RELAY_REQUEST_ID_PREFIX}%`] : []), query.cliToolId, query.instanceId, query.fromMs, query.toMs, query.limit ?? exports.USER_TURN_CANDIDATE_LIMIT);
+    // A bare `relay:` names no ledger entry and so is not a delivery — the rule
+    // `parseRelayRequestId` already states for the loop guard, applied here so the
+    // two readers cannot disagree about what counts as one. A no-op without the
+    // option, where nothing that comes back is keyed at all.
+    return rows
+        .map(mapChatMessage)
+        .filter((message) => !message.requestId || parseRelayRequestId(message.requestId) !== null);
 }
 /**
  * Claim an unkeyed row for a producer, without touching anything else on it
@@ -697,3 +734,120 @@ function createModelChangeMessage(db, params) {
         instanceId: params.instanceId ?? params.cliToolId,
     });
 }
+// ===========================================================================
+// Relay rows (Issue #2377)
+// ===========================================================================
+/**
+ * The `request_id` prefix a RELAYED message carries.
+ *
+ * The delivered body is an ordinary user row — session B's answer, typed into
+ * session A's composer — and `relay:<relayId>` is what turns that row back into
+ * a pointer at the ledger entry that produced it. Two readers depend on that
+ * direction:
+ *
+ *  - the ledger's own idempotency, because the id is also
+ *    `session_relays.sent_request_id` and that column carries a UNIQUE index;
+ *  - the loop guard, which asks "was the last thing this session was told a
+ *    relayed message, and if so, whose?" — the answer is the parent relay, and
+ *    its `hops` is what the new relay's depth is measured from.
+ *
+ * Same shape and same reasoning as {@link MODEL_CHANGE_REQUEST_ID_PREFIX}: a
+ * prefix rather than a wording, because the wording is localized at write time.
+ */
+exports.RELAY_REQUEST_ID_PREFIX = 'relay:';
+/** The `request_id` prefix a relay SYSTEM row carries (`relay-sys:<relayId>:<kind>`). */
+exports.RELAY_SYSTEM_REQUEST_ID_PREFIX = 'relay-sys:';
+/** Build the relay message's request id from the ledger id. */
+function relayRequestId(relayId) {
+    return `${exports.RELAY_REQUEST_ID_PREFIX}${relayId}`;
+}
+/**
+ * The ledger id inside a relayed row's request id, or null.
+ *
+ * Null for every other row, including a relay SYSTEM row: those are transcript
+ * furniture, not the delivery, and treating one as the delivery would let a
+ * session's own "delegated, waiting" line count as an inbound relay.
+ */
+function parseRelayRequestId(requestId) {
+    if (!requestId || !requestId.startsWith(exports.RELAY_REQUEST_ID_PREFIX))
+        return null;
+    const id = requestId.slice(exports.RELAY_REQUEST_ID_PREFIX.length);
+    return id === '' ? null : id;
+}
+/**
+ * The newest user-authored row for ONE agent instance.
+ *
+ * {@link getLastUserMessage} answers the same question for a whole worktree,
+ * which is the wrong scope for the loop guard: a worktree runs several sessions
+ * and "was I asked this by a relay?" is a question about one of them.
+ *
+ * `matchResolvedInstance`'s expression is spelled out here rather than reused
+ * through `getMessages` because this read wants the newest USER row and
+ * `getMessages` bounds by rows of every role — a turn with thirty assistant
+ * rows in it would push the user row out of any sane limit.
+ */
+function getLastUserMessageForInstance(db, worktreeId, cliToolId, instanceId) {
+    const stmt = db.prepare(`
+    SELECT id, worktree_id, role, content, summary, timestamp, log_file_name, request_id, message_type, prompt_data, cli_tool_id, instance_id, archived
+    FROM chat_messages
+    WHERE worktree_id = ? AND role = 'user' ${exports.ACTIVE_FILTER}
+      AND COALESCE(cli_tool_id, 'claude') = ?
+      AND COALESCE(instance_id, cli_tool_id, 'claude') = ?
+    ORDER BY timestamp DESC
+    LIMIT 1
+  `);
+    const row = stmt.get(worktreeId, cliToolId, instanceId);
+    return row ? mapChatMessage(row) : null;
+}
+/**
+ * The newest unanswered prompt row for one agent instance, or null.
+ *
+ * What the confirmation notice is written from. `promptData.status` is the
+ * only thing consulted — the row's own wording is what the notice quotes — and
+ * a row whose data is one of #1738's degraded records simply yields no options,
+ * which the notice renders as a question with no choices rather than dropping.
+ */
+function getLatestOpenPromptMessage(db, worktreeId, cliToolId, instanceId) {
+    const stmt = db.prepare(`
+    SELECT id, worktree_id, role, content, summary, timestamp, log_file_name, request_id, message_type, prompt_data, cli_tool_id, instance_id, archived
+    FROM chat_messages
+    WHERE worktree_id = ? AND message_type = 'prompt' ${exports.ACTIVE_FILTER}
+      AND COALESCE(cli_tool_id, 'claude') = ?
+      AND COALESCE(instance_id, cli_tool_id, 'claude') = ?
+    ORDER BY timestamp DESC
+    LIMIT 1
+  `);
+    const row = stmt.get(worktreeId, cliToolId, instanceId);
+    if (!row)
+        return null;
+    const message = mapChatMessage(row);
+    return message.promptData?.status === 'answered' ? null : message;
+}
+/**
+ * Persist "this session delegated / got an answer" into the transcript (#2377).
+ *
+ * An assistant row with a marker request id, exactly as
+ * {@link createModelChangeMessage} writes the model-change line, and for the
+ * same reasons: `chat_messages` has no `system` role, the transcript groups a
+ * leading assistant row as a standalone reply, and the row is `normal` so
+ * nothing scanning for open dialogs mistakes it for one. Writing it here rather
+ * than inventing a fourth history surface is what puts the line in the chat
+ * pane AND the History tab from one write.
+ *
+ * Idempotent by construction at the call site: the request id is
+ * `relay-sys:<relayId>:<kind>` and the callers probe
+ * {@link findMessageByRequestId} before writing, so a retried delivery does not
+ * leave two "waiting for the reply" lines in one transcript.
+ */
+function createRelaySystemMessage(db, params) {
+    return createMessage(db, {
+        worktreeId: params.worktreeId,
+        role: 'assistant',
+        content: params.content,
+        messageType: 'normal',
+        timestamp: new Date(params.at),
+        requestId: `${exports.RELAY_SYSTEM_REQUEST_ID_PREFIX}${params.relayId}:${params.kind}`,
+        cliToolId: params.cliToolId,
+        instanceId: params.instanceId ?? params.cliToolId,
+    });
+}

package/dist/server/src/lib/db/migrations/index.js

@@ -43,6 +43,7 @@ const v56_gate_result_source_1 = require("./v56-gate-result-source");
 const v57_push_subscription_defaults_notice_1 = require("./v57-push-subscription-defaults-notice");
 const v58_agent_session_costs_1 = require("./v58-agent-session-costs");
 const v59_opencode_instance_settings_1 = require("./v59-opencode-instance-settings");
+const v60_session_relays_1 = require("./v60-session-relays");
 /**
  * Complete ordered list of all migrations.
  * Used internally by the barrel file (db-migrations.ts); NOT exported from the barrel (DR2-004).
@@ -89,4 +90,5 @@ exports.migrations = [
     ...v57_push_subscription_defaults_notice_1.v57_migrations,
     ...v58_agent_session_costs_1.v58_migrations,
     ...v59_opencode_instance_settings_1.v59_migrations,
+    ...v60_session_relays_1.v60_migrations,
 ];

package/dist/server/src/lib/db/migrations/runner.js

@@ -17,7 +17,7 @@ const path_1 = __importDefault(require("path"));
  * Current schema version
  * Increment this when adding new migrations
  */
-exports.CURRENT_SCHEMA_VERSION = 59;
+exports.CURRENT_SCHEMA_VERSION = 60;
 /**
  * Get current schema version from database
  */

package/dist/server/src/lib/db/migrations/v60-session-relays.js

@@ -0,0 +1,110 @@
+"use strict";
+/**
+ * Migration v60: the relay ledger (Issue #2377).
+ *
+ * ## What a row is
+ *
+ * One row is one standing instruction: "when session B finishes the turn it is
+ * working on, put its answer into session A's composer". Until this Issue that
+ * instruction existed only as a shape in session A's own control flow — `send`,
+ * then `wait`, then `capture` — which is why A had to stay blocked to collect a
+ * reply it had already asked for. A ledger row is the same intent written down
+ * somewhere the server can act on, so A can go and do something else.
+ *
+ * ## Why `from` is the requester and `to` is the worker
+ *
+ * The row is named after the DELEGATION, not after the delivery: `from` is the
+ * session that asked (and is therefore owed the answer), `to` is the session
+ * that was asked. So `commandmate relays` reads "mine, out" as
+ * `from = me` and "mine, in" as `to = me`, and the badges the Agent pane draws
+ * read the same way round — B's row says it owes A a reply, A's row says it is
+ * waiting on n of them.
+ *
+ * ## The columns that are not just bookkeeping
+ *
+ * - **`sent_request_id`** is the idempotency key the Issue asks for. The turn's
+ *   end is judged by two independent producers (the Stop hook and the poller,
+ *   see `lib/polling/structured-history-gate`), so the delivery has to be
+ *   claimable exactly once. It carries the `relay:<id>` request id of the row
+ *   written into A's history, which is also what makes the delivered message
+ *   findable from the ledger and the ledger findable from the message — that
+ *   second direction is what the loop guard reads.
+ * - **`pending_kind` / `pending_body`** hold a delivery that has been decided
+ *   but not yet made. A is frequently mid-turn when B finishes, and typing into
+ *   a running composer interrupts it (#1737's problem, one layer up), so the
+ *   body waits in the ledger — durable across a restart — and the pump retries.
+ *   `pending_kind IS NULL` is also the "nobody has captured this turn yet"
+ *   guard that makes the two producers cost one delivery.
+ * - **`prompt_signature`** dedupes the confirmation notice. A wait that lasts
+ *   twenty minutes must reach A once, not once per poll.
+ * - **`hops`** is the chain depth. 1 for a relay a human or an unrelated turn
+ *   started; n+1 for one created while answering a relay-delivered message.
+ *
+ * `state` is CHECK-constrained for the reason v50's `tasks.status` is: the five
+ * words are the point of the table, and a typo landing as a sixth would create
+ * a bucket nothing queries.
+ *
+ * Both worktree columns declare a foreign key so `getWorktreeChildTables()`
+ * finds them by introspection — the pair follows a worktree id rename (v54/v55)
+ * and is swept when either side is deleted, which is the right lifetime: a relay
+ * whose requester or whose worker is gone can never be delivered.
+ *
+ * Timestamps are epoch milliseconds (INTEGER), matching v44 onward.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.v60_migrations = void 0;
+exports.v60_migrations = [
+    {
+        version: 60,
+        name: 'session-relays',
+        up: (db) => {
+            db.exec(`
+        CREATE TABLE IF NOT EXISTS session_relays (
+          id TEXT PRIMARY KEY,
+          from_worktree_id TEXT NOT NULL,
+          from_instance_id TEXT NOT NULL,
+          to_worktree_id TEXT NOT NULL,
+          to_instance_id TEXT NOT NULL,
+          state TEXT NOT NULL CHECK (state IN ('pending','delivered','prompt','expired','cancelled')),
+          hops INTEGER NOT NULL DEFAULT 1,
+          sent_request_id TEXT,
+          pending_kind TEXT,
+          pending_body TEXT,
+          prompt_signature TEXT,
+          created_at INTEGER NOT NULL,
+          updated_at INTEGER NOT NULL,
+          expires_at INTEGER NOT NULL,
+          delivered_at INTEGER,
+
+          FOREIGN KEY (from_worktree_id) REFERENCES worktrees(id) ON DELETE CASCADE,
+          FOREIGN KEY (to_worktree_id) REFERENCES worktrees(id) ON DELETE CASCADE
+        );
+      `);
+            // The idempotency key, enforced rather than merely intended. Partial so
+            // the many rows that have not been delivered yet do not collide on NULL.
+            db.exec(`
+        CREATE UNIQUE INDEX IF NOT EXISTS idx_session_relays_sent_request
+          ON session_relays(sent_request_id)
+          WHERE sent_request_id IS NOT NULL;
+      `);
+            // The two lookups every reader makes: "what does this session owe" and
+            // "what is this session waiting for".
+            db.exec(`
+        CREATE INDEX IF NOT EXISTS idx_session_relays_to
+          ON session_relays(to_worktree_id, to_instance_id, state);
+      `);
+            db.exec(`
+        CREATE INDEX IF NOT EXISTS idx_session_relays_from
+          ON session_relays(from_worktree_id, from_instance_id, state);
+      `);
+            // The sweep's own read: everything still open, oldest deadline first.
+            db.exec(`
+        CREATE INDEX IF NOT EXISTS idx_session_relays_open
+          ON session_relays(state, expires_at);
+      `);
+        },
+        down: (db) => {
+            db.exec('DROP TABLE IF EXISTS session_relays;');
+        },
+    },
+];