commandmate 0.32.0 → 0.33.0

package/dist/server/src/lib/polling/response-checker.js

@@ -303,15 +303,26 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
     // that placeholder is drawn with the same `❯ <text>` shape as a transcript
     // echo, so without the boundary `findRecentUserPromptIndex` anchors the turn
     // on the FOOTER and every reply extracts as empty (#1289's defect, verbatim).
+    //
+    // Issue #2400: codex is the fifth, and the one that had been missing. It pins
+    // the same two rows — `› Ask Codex to do anything` and the `model · cwd`
+    // status bar — and without a boundary the saturated-window anchor (#1670)
+    // walked into them: the newest `›` in the pane was the COMPOSER, so extraction
+    // started on the status bar and every reply on a saturated pane was saved as
+    // that one row. `findCodexChromeStart` reads the composer by its SGR
+    // attributes (#2310) rather than by its placeholder wording, which is what the
+    // previous guard did and why it stopped working at codex 0.15x.
     const chromeStart = cliToolId === 'claude'
         ? (0, cli_patterns_1.findClaudeChromeStart)(lines)
         : cliToolId === 'copilot'
             ? (0, cli_patterns_1.findCopilotChromeStart)(lines)
             : cliToolId === 'command-code'
                 ? (0, cli_patterns_1.findCommandCodeChromeStart)(lines)
-                : openCodeCleanLines
-                    ? (0, cli_patterns_1.findOpenCodeChromeStart)(openCodeCleanLines)
-                    : -1;
+                : cliToolId === 'codex'
+                    ? (0, cli_patterns_1.findCodexChromeStart)(lines)
+                    : openCodeCleanLines
+                        ? (0, cli_patterns_1.findOpenCodeChromeStart)(openCodeCleanLines)
+                        : -1;
     const contentEnd = chromeStart >= 0 ? chromeStart : totalLines;
     const BUFFER_RESET_TOLERANCE = 25;
     const bufferShrank = totalLines > 0 && lastCapturedLine > BUFFER_RESET_TOLERANCE && (totalLines + BUFFER_RESET_TOLERANCE) < lastCapturedLine;
@@ -333,7 +344,22 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
     const findRecentUserPromptIndex = (windowSize = 60) => {
         let userPromptPattern;
         if (cliToolId === 'codex') {
-            userPromptPattern = /^›\s+(?!Implement|Find and fix|Type|Summarize)/;
+            // Issue #2400: codex's three uses of `›` are separated by their SGR
+            // attributes, not by their text (#2310). This branch used to exclude the
+            // composer with a negative lookahead over its placeholder strings
+            // (`Implement`, `Find and fix`, `Type`, `Summarize`) — codex 0.1x wording,
+            // none of which 0.15x draws. `Ask Codex to do anything` passed the guard,
+            // became the newest "echo", and on a saturated pane (#1670) — the only
+            // path where this anchor decides where extraction STARTS — every reply was
+            // saved as the single status-bar row below it.
+            //
+            // Two independent things now keep the composer out, and the reader needs
+            // both because neither covers the other's frames: `contentEnd` cuts the
+            // composer off structurally when `findCodexChromeStart` located it, and
+            // when it did not, `findCodexUserEchoIndex` steps over the bottom-most
+            // `›` row instead. The second is what still answers on an ANSI-stripped
+            // capture, where none of #2310's attributes survive to be read.
+            return (0, cli_patterns_1.findCodexUserEchoIndex)(lines, contentEnd, windowSize, chromeStart >= 0);
         }
         else if (openCodeCleanLines) {
             // Issue #1911: anchor on the newest ECHOED USER PROMPT, not on the
@@ -453,9 +479,20 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
     if (isPromptBasedComplete || isClaudeComplete || isCommandCodeComplete || isOpenCodeDone) {
         const responseLines = [];
         const startIndex = (0, response_extractor_1.resolveExtractionStartIndex)(lastCapturedLine, totalLines, bufferReset, cliToolId, findRecentUserPromptIndex, captureWindowSaturated);
-        let endIndex = totalLines;
         // `contentEnd` bounds the content only; `endIndex` keeps reporting the full
         // buffer so lineCount bookkeeping in session_states is unchanged (#1289).
+        //
+        // Issue #2400: codex is the exception, and it is the pre-existing behaviour
+        // rather than a new rule. Before this Issue the loop below stopped on the
+        // composer's `›` and wrote that row's index into `endIndex`; now the composer
+        // is outside `contentEnd`, so the break can no longer fire on it and
+        // `endIndex` would silently advance ~3 rows further. Those rows matter for
+        // codex specifically: it renders INLINE, and it repaints the composer band in
+        // place — the next turn's transcript is printed over exactly the rows the
+        // composer occupied in this capture. A cursor parked past them would skip
+        // real content on the following poll. So the cursor stops where the content
+        // stops, which is what it did before.
+        let endIndex = cliToolId === 'codex' ? contentEnd : totalLines;
         for (let i = startIndex; i < contentEnd; i++) {
             const line = lines[i];
             const cleanLine = (0, cli_patterns_1.stripAnsi)(line);
@@ -698,6 +735,26 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
 // ============================================================================
 // checkForResponse (exported for response-poller-core.ts)
 // ============================================================================
+/**
+ * Record what the structured writers said about this turn, for the ticks that
+ * will not get to ask (Issue #2399).
+ *
+ * One line either way, but named because the two calls are a pair and the
+ * failure mode of writing only one of them is silent: mark without settle and
+ * the reader is re-asked forever after a turn it already recorded; settle
+ * without mark and the fix does not exist.
+ *
+ * @param pollerKey - Poller key ("worktreeId:instanceId")
+ * @param recorded - Whether a structured writer owns this turn
+ */
+function markOrSettleStructuredHistoryRecheck(pollerKey, recorded) {
+    if (recorded) {
+        (0, response_dedup_1.settleStructuredHistoryRecheck)(pollerKey);
+    }
+    else {
+        (0, response_dedup_1.markStructuredHistoryRecheckPending)(pollerKey);
+    }
+}
 /**
  * Check for CLI tool response once
  *
@@ -994,6 +1051,66 @@ async function checkForResponse(worktreeId, cliToolId, instanceId) {
                 // are found by one grep.
                 logger.info('duplicate-response-skipped', { worktreeId, cliToolId, instanceId: resolvedInstanceId });
                 (0, db_1.updateSessionState)(db, worktreeId, cliToolId, result.lineCount, resolvedInstanceId);
+                // Issue #2399: the skip above is about the SCREEN, and until this Issue
+                // it also ended the tick for the TRANSCRIPT READER 100 lines below —
+                // which is the one consumer for whom "the frame has not changed" is not
+                // evidence of anything. A pull-mode agent closes its turn in its own
+                // file AFTER the pane has gone quiet, so the reader's single ask (on the
+                // poll that saved the scrape) is systematically too early, and every
+                // later poll returned here. Measured on codex 2026-09-07: one
+                // `codex-transcript-turn-open`, `task_complete` appended 1.8 s later,
+                // and then `duplicate-response-skipped` every 2 s until
+                // `MAX_POLLING_DURATION` ran out. The Markdown row was never written and
+                // the only thing left in History was the scrape — for a saturated pane,
+                // a single footer line.
+                //
+                // So the reader is re-asked from inside the skip, throttled by
+                // `claimStructuredHistoryRecheck` (once on the first duplicate tick,
+                // then every third — see `./response-dedup`). Deliberately the reader
+                // and nothing else: the scrape stays suppressed, the cursor has already
+                // been advanced above, and none of the bookkeeping the guard skips has a
+                // second producer to be asked about.
+                //
+                // Order over the alternative in the Issue (hoist the reader above the
+                // guard): the reader is a WRITE, and hoisting it would run that write on
+                // every one of the 900 ticks of a 30-minute cycle instead of on the ones
+                // that are owed an answer — the same argument the #2317 Phase D comment
+                // below makes for not letting the delegation test short-circuit it.
+                //
+                // What this does NOT do is retract the scraped row the earlier tick
+                // saved. Three reasons, and the first is decisive: nothing here can
+                // identify that row. The hash this guard matched is per pollerKey, not
+                // per turn — it survives the `resume` of a chain paused on a prompt —
+                // so the row it stands for may belong to an earlier turn entirely, and
+                // a scraped row carries no turn key to join on. Second, `archived` in
+                // this schema is the tombstone of an operator clearing History (#168),
+                // written by `archiveMessages` for a whole worktree; reusing it for
+                // "superseded" would make a clear and a handover indistinguishable in
+                // the table. Third, the scrape is not always junk — when a turn is
+                // interrupted the pane holds text the transcript's closed turn does not
+                // — and a duplicated row is visible and recoverable where a deleted one
+                // is neither. Two rows for one turn is the failure this trades for, and
+                // #2401 has already stopped the junk one being picked as a relay's
+                // answer.
+                if ((0, response_dedup_1.claimStructuredHistoryRecheck)(pollerKey)) {
+                    const recaptured = await (0, structured_history_gate_1.captureStructuredHistoryTurn)(worktreeId, cliToolId, instanceId, {
+                        worktreePath: worktree.path,
+                        transcriptPathHint: claudeMetadata?.logFilePath ?? null,
+                    });
+                    if (recaptured) {
+                        (0, response_dedup_1.settleStructuredHistoryRecheck)(pollerKey);
+                        logger.info('structured-history-recheck-captured', {
+                            worktreeId,
+                            cliToolId,
+                            instanceId: resolvedInstanceId,
+                        });
+                        // The turn IS now in History, as the agent's own Markdown, so this
+                        // tick recorded something and says so. Inert for the poller either
+                        // way: `runPollTick` only reads this value after a stop the tick
+                        // raised itself, and this branch raises none.
+                        return true;
+                    }
+                }
                 return false;
             }
         }
@@ -1020,6 +1137,13 @@ async function checkForResponse(worktreeId, cliToolId, instanceId) {
                 worktreePath: worktree.path,
                 transcriptPathHint: claudeMetadata?.logFilePath ?? null,
             }));
+        // Issue #2399: remember which way that went, because the next tick may not
+        // get here. A `false` is the reader saying "not yet, or not mine", and the
+        // dedup guard above turns every following poll of the same static frame into
+        // a return — so unless the fact is written down now, the ask never happens
+        // again. A `true` settles it: the turn is recorded and there is nothing left
+        // to re-ask about.
+        markOrSettleStructuredHistoryRecheck((0, response_poller_core_1.getPollerKey)(worktreeId, cliToolId, instanceId), structuredHistoryLive);
         // Issue #2317 Phase D: the scrape is dropped while the geometry is
         // delegated, and the transcript capture above is what makes that safe.
         //

package/dist/server/src/lib/polling/response-dedup.js

@@ -17,14 +17,69 @@
  * during THIS turn?" and deliberately does NOT persist across turns: an
  * identical response in a later turn is a real response and must be saved.
  * Suppressing it would reproduce the very bug this module fixes.
+ *
+ * ## The second cache: what the dedup skip owes the transcript reader (#2399)
+ *
+ * The guard above answers a question about the SCREEN, and `response-checker`
+ * used to read its answer as a question about the TURN — a duplicate frame ended
+ * the tick before `captureStructuredHistoryTurn` was reached, so for a pull-mode
+ * tool (claude, codex, antigravity, command-code) the transcript reader was
+ * asked exactly once per turn: on the poll that saved the scrape. For a reader
+ * the premise is backwards. "The screen stopped changing" is precisely the
+ * moment BEFORE the agent's own file closes the turn, so the one ask lands too
+ * early, answers false, and the 900 ticks that follow — 30 minutes of
+ * `MAX_POLLING_DURATION` at 2 s each — all return at the guard. Measured on
+ * codex 2026-09-07: `codex-transcript-turn-open` once, then
+ * `duplicate-response-skipped` until the poller's budget ran out, with the
+ * rollout's `task_complete` appended 1.8 s after the single ask.
+ *
+ * So the dedup verdict now carries a caveat, and it lives here rather than in
+ * `response-checker` for one reason: its lifetime is the response hash's
+ * lifetime exactly. `stopPolling`, the `resume` that keeps a paused chain's
+ * hash, and the worktree rename all have to treat the two the same, and the
+ * only way to guarantee that without touching `response-poller-core` (which
+ * owns those three calls) is for one function to clear both.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.STRUCTURED_HISTORY_RECHECK_TICK_INTERVAL = void 0;
 exports.isDuplicateResponse = isDuplicateResponse;
+exports.markStructuredHistoryRecheckPending = markStructuredHistoryRecheckPending;
+exports.settleStructuredHistoryRecheck = settleStructuredHistoryRecheck;
+exports.claimStructuredHistoryRecheck = claimStructuredHistoryRecheck;
 exports.clearResponseHashCache = clearResponseHashCache;
 exports.renameResponseHashCacheKey = renameResponseHashCacheKey;
 const crypto_1 = require("crypto");
 const responseHashCache = globalThis.__responseHashCache ??
     (globalThis.__responseHashCache = new Map());
+/**
+ * In-memory cache: pollerKey -> ticks still to wait before the transcript reader
+ * is asked again (Issue #2399). Absence means nothing is owed.
+ *
+ * On `globalThis` for the same reason `responseHashCache` is, and populated and
+ * cleared at exactly the same moments — see the module comment.
+ */
+const structuredHistoryRecheckCache = globalThis.__structuredHistoryRecheckCache ??
+    (globalThis.__structuredHistoryRecheckCache = new Map());
+/**
+ * How many duplicate ticks separate two asks of the transcript reader (#2399).
+ *
+ * The reader's work is a tail read of the agent's transcript — 4 MiB for codex
+ * — parsed and rendered, so asking on all 900 ticks of a 30-minute cycle is not
+ * free even though the poller has nothing else to do with them. Three is chosen
+ * against the two numbers that bracket it:
+ *
+ *  - the FIRST duplicate tick always asks (the countdown starts at zero), so in
+ *    the ordinary case — the turn closed between the scrape and the next poll —
+ *    the Markdown row lands ~2 s later and the throttle never applies at all;
+ *  - a turn that closes late is then re-asked every ~6 s, which is inside the
+ *    window where a missing reply is still an operator's "it hasn't shown up
+ *    yet" rather than a lost turn.
+ *
+ * The cost this bounds is only ever paid while a turn is BOTH finished on screen
+ * and still open in the transcript; the moment either the reader writes the row
+ * or the cycle ends, the entry is gone.
+ */
+exports.STRUCTURED_HISTORY_RECHECK_TICK_INTERVAL = 3;
 /**
  * Check whether the given response content was already saved during the current
  * polling cycle for the same pollerKey. If it is new, updates the cache.
@@ -41,15 +96,88 @@ function isDuplicateResponse(pollerKey, content) {
     responseHashCache.set(pollerKey, hash);
     return false;
 }
+/**
+ * Note that the transcript reader has unfinished business for this pollerKey
+ * (Issue #2399).
+ *
+ * Called by `response-checker` on every poll that gets PAST the guard above and
+ * finds neither structured writer willing to own the turn — i.e. the push
+ * subscription is not live and the pull reader answered false. That false is the
+ * one the poller used to treat as final, and this records that it was not.
+ *
+ * Idempotent, and deliberately does not restart the countdown: a turn that has
+ * been waiting five ticks for its transcript to close must not be pushed back to
+ * the end of the queue by a sixth poll that learned nothing new.
+ *
+ * The tool is not consulted. `captureStructuredHistoryTurn` answers "does this
+ * tool keep a transcript at all?" in a map lookup and returns false for gemini,
+ * copilot and opencode without touching a file, so an entry for one of them
+ * costs a lookup every third tick and duplicating the gate's own dispatch here
+ * would cost a second place for it to go stale.
+ *
+ * @param pollerKey - Poller key ("worktreeId:instanceId")
+ */
+function markStructuredHistoryRecheckPending(pollerKey) {
+    if (!structuredHistoryRecheckCache.has(pollerKey)) {
+        structuredHistoryRecheckCache.set(pollerKey, 0);
+    }
+}
+/**
+ * Forget the outstanding recheck for this pollerKey (Issue #2399).
+ *
+ * Called when the question has an answer: the reader wrote the row, or a push
+ * subscription turned out to own the turn after all. Nothing is owed and the
+ * next duplicate tick returns at the guard exactly as it did before this Issue.
+ *
+ * @param pollerKey - Poller key ("worktreeId:instanceId")
+ */
+function settleStructuredHistoryRecheck(pollerKey) {
+    structuredHistoryRecheckCache.delete(pollerKey);
+}
+/**
+ * Take this tick's turn at asking the transcript reader again (Issue #2399).
+ *
+ * A claim rather than a query, because the throttle has to be spent exactly once
+ * per tick and the caller is the only thing that knows a tick happened: this
+ * both answers "ask now?" and advances the countdown, so two calls in one tick
+ * would ask twice as often rather than twice.
+ *
+ * False when nothing is owed for this key ({@link markStructuredHistoryRecheckPending}
+ * was never called, or {@link settleStructuredHistoryRecheck} has since run) and
+ * false on the ticks the throttle swallows. True on the first duplicate tick
+ * after a pending mark, and every
+ * {@link STRUCTURED_HISTORY_RECHECK_TICK_INTERVAL} ticks after that.
+ *
+ * @param pollerKey - Poller key ("worktreeId:instanceId")
+ * @returns true when the caller should ask the reader on this tick
+ */
+function claimStructuredHistoryRecheck(pollerKey) {
+    const ticksToWait = structuredHistoryRecheckCache.get(pollerKey);
+    if (ticksToWait === undefined)
+        return false;
+    if (ticksToWait > 0) {
+        structuredHistoryRecheckCache.set(pollerKey, ticksToWait - 1);
+        return false;
+    }
+    structuredHistoryRecheckCache.set(pollerKey, exports.STRUCTURED_HISTORY_RECHECK_TICK_INTERVAL - 1);
+    return true;
+}
 /**
  * Clear the response hash cache for a specific pollerKey.
  * Called during session cleanup / stopPolling, so each new user turn starts
  * with a clean slate.
  *
+ * Issue #2399: the outstanding recheck goes with it. The caveat is a note about
+ * one particular cached hash — "the screen behind it was static before the
+ * transcript closed" — so it can outlive neither the hash nor the cycle, and
+ * carrying it into a new turn would spend reads asking about a turn that is
+ * over.
+ *
  * @param pollerKey - Poller key ("worktreeId:instanceId")
  */
 function clearResponseHashCache(pollerKey) {
     responseHashCache.delete(pollerKey);
+    structuredHistoryRecheckCache.delete(pollerKey);
 }
 /**
  * Move the cached hash from one pollerKey to another.
@@ -71,4 +199,12 @@ function renameResponseHashCacheKey(oldKey, newKey) {
     responseHashCache.delete(oldKey);
     if (hash !== undefined)
         responseHashCache.set(newKey, hash);
+    // Issue #2399: the recheck caveat moves with the hash it is about. Leaving it
+    // behind would strand a turn whose transcript is still open — the new key
+    // starts owing nothing, so every later tick returns at the dedup guard and the
+    // Markdown row is never written.
+    const ticksToWait = structuredHistoryRecheckCache.get(oldKey);
+    structuredHistoryRecheckCache.delete(oldKey);
+    if (ticksToWait !== undefined)
+        structuredHistoryRecheckCache.set(newKey, ticksToWait);
 }

package/dist/server/src/lib/relay/relay-delivery.js

@@ -12,7 +12,10 @@
  *    agent has CLOSED, which is a stronger statement than any amount of quiet,
  *    so the capture is delivered as soon as it lands. Both triggers of that
  *    capture — the Stop hook and the poller — reach the same function, which is
- *    why this module needs one hook and not two.
+ *    why this module needs one hook and not two. For these five the transcript
+ *    is also the ONLY thing a reply may be read from: the poller's own scrape
+ *    of the same turn arrives first and carries junk (Issue #2401), so an
+ *    unmarked row is stepped over and the marked one waited for.
  *  - **Tools without one** (copilot, gemini, vibe-local). What a finished turn
  *    leaves behind is the poller's copy of the SCREEN, judged by a string
  *    analysis of a frame that may still be being drawn. The Issue asks for
@@ -67,6 +70,86 @@ const logger = (0, logger_1.createLogger)('relay-delivery');
 const REPLY_LOOKBACK_MESSAGES = 40;
 /** How many times the scrape path re-reads before it gives up on stability. */
 const SCRAPE_STABILITY_ATTEMPTS = 3;
+/**
+ * The `request_id` shape a transcript reader mints for a finished turn.
+ *
+ * `claude-turn:<uuid>`, `codex-turn:<turn_id>`, `antigravity-turn:<id>`,
+ * `command-code-turn:<id>` and opencode's `oc-turn:<message id>`. Matched as a
+ * SHAPE rather than as a list of five literals for the reason `ask`'s copy of
+ * this line gives (Issue #2386): the sixth reader lands INSIDE the filter
+ * instead of silently outside it. A `:` cannot appear in any of the ids
+ * themselves, so this cannot match a row that merely contains the text.
+ *
+ * Copied rather than imported, deliberately. `src/cli/commands/ask.ts` has the
+ * same regexp, and importing it here would invert the dependency (lib reaching
+ * into the CLI bundle); `AGENT_MARKDOWN_REQUEST_ID_PREFIXES` in
+ * `src/types/agent-transcript.ts` is the LIST form this shape is chosen not to
+ * be. One regexp in each layer is cheaper than either edge.
+ */
+const TURN_REQUEST_ID_PATTERN = /-turn:/;
+/**
+ * Request-id namespaces CommandMate writes ABOUT a session, not for it.
+ *
+ * `chat_messages` has no `system` role, so "reply from X" (Issue #2377) and
+ * "the model changed" (Issue #2357) are both stored as assistant rows and told
+ * apart by their request id. Neither is a word the worker said, and handing the
+ * relay's own notice back to the session it came from is the smallest possible
+ * loop. `ask` steps over exactly these two for the same reason.
+ */
+const SYSTEM_ROW_REQUEST_ID_PREFIXES = [
+    chat_db_1.RELAY_SYSTEM_REQUEST_ID_PREFIX,
+    chat_db_1.MODEL_CHANGE_REQUEST_ID_PREFIX,
+];
+/**
+ * Whether this tool's reply is read out of a transcript rather than off a screen.
+ *
+ * For the five that answer `true` the ledger is authoritative: a row with no
+ * turn marker was written by the SCRAPER, and for these tools a scraped row is
+ * never the answer — it is a footer line, a half-drawn frame or the ANSI dump
+ * the send path flushes (Issues #2398 / #2400). The relay may therefore hold
+ * out for a marked row. For copilot, gemini and vibe-local the scraper's row is
+ * the only record there will ever be, and demanding a marker would deliver
+ * nothing, ever.
+ *
+ * A record and not a `Set`, so a ninth entry in `CLI_TOOL_IDS` fails `tsc` here
+ * instead of quietly defaulting to "screen-scraped" — the idiom
+ * `cli-tools/install-hints` uses for the same reason.
+ *
+ * Deliberately NOT `isPullTranscriptHistory`: that asks who does the READING,
+ * so opencode (whose own server pushes) answers `false` even though its rows
+ * carry `oc-turn:` like the other four. It also lives in `lib/polling`, whose
+ * module graph reaches this file's triggers — importing it would close a cycle
+ * the relay was built to avoid.
+ */
+const TRANSCRIPT_READER_TOOLS = {
+    claude: true,
+    codex: true,
+    antigravity: true,
+    'command-code': true,
+    opencode: true,
+    copilot: false,
+    gemini: false,
+    'vibe-local': false,
+};
+/**
+ * How long the scrape path holds out for the transcript row.
+ *
+ * Issue #2386 measured the gap on codex 0.153.4 at 5.2 s: the scraper writes
+ * the pane into the ledger in the millisecond before the send, and the rollout
+ * reader writes the real answer about five seconds after the completion was
+ * already announced. Three times the measured gap, the same window `ask` holds,
+ * and spent only when the ledger has nothing marked yet — a worker whose
+ * transcript already landed stashes on the first read.
+ *
+ * When it does elapse nothing is delivered. That is the safe direction and not
+ * a lost answer: the relay is a STANDING instruction, so the transcript
+ * reader's own `settled` announcement (or the next completion) still delivers,
+ * and if neither ever comes the requester is told by the expiry notice rather
+ * than by a footer line dressed up as the reply.
+ */
+const RELAY_TURN_ROW_GRACE_MS = 15_000;
+/** How often the grace above re-reads the ledger. */
+const RELAY_TURN_ROW_POLL_MS = 1_000;
 const inFlight = (globalThis.__relayDeliveryInFlight ??= new Set());
 /** Forget every in-flight delivery. Test seam. */
 function resetRelayDeliveryState() {
@@ -77,14 +160,37 @@ function senderLabel(db, relay) {
     const worker = (0, relay_session_ref_1.resolveRelaySession)(db, relay.to);
     return { alias: worker.alias, worktreeId: worker.worktreeId };
 }
+/** Whether a row's `request_id` says a transcript reader wrote it. */
+function isTurnRow(requestId) {
+    return typeof requestId === 'string' && TURN_REQUEST_ID_PATTERN.test(requestId);
+}
+/** Whether a row is CommandMate's own furniture rather than the worker's words. */
+function isSystemRow(requestId) {
+    return typeof requestId === 'string'
+        && SYSTEM_ROW_REQUEST_ID_PREFIXES.some((prefix) => requestId.startsWith(prefix));
+}
+/** Whether this worker's answer is only ever a transcript row. */
+function requiresTurnRow(cliToolId) {
+    return TRANSCRIPT_READER_TOOLS[cliToolId] === true;
+}
 /**
  * The newest thing B actually said, at or after `since`.
  *
- * Three kinds of row are stepped over, and each exclusion is load-bearing:
+ * Four kinds of row are stepped over, and each exclusion is load-bearing:
  * prompt rows (a question is not an answer, and the confirmation notice is a
- * separate delivery), relay SYSTEM rows (this session's own transcript
- * furniture — delivering "Reply from X" back to X is the smallest possible
- * loop), and empty bodies.
+ * separate delivery), CommandMate's own system rows (delivering "Reply from X"
+ * back to X is the smallest possible loop), empty bodies — and, for a tool that
+ * keeps a transcript, every row the SCRAPER wrote.
+ *
+ * That last one is Issue #2401. Until it was added the filter looked only at
+ * shape, never at provenance, so the newest row won whatever had written it:
+ * a codex footer line, a partial scrape, or the raw ANSI the send path flushes
+ * lands in the ledger with `request_id IS NULL` and, being newest, WAS the
+ * reply — forwarded to the requesting agent as the worker's own answer, which
+ * it then summarises. #2386 fixed the identical hole in `ask` by demanding the
+ * turn marker; the relay looked exempt only because its 15-second pump usually
+ * gave the transcript time to land, and a race the timing usually wins is still
+ * a race.
  */
 function findWorkerReply(db, worker, since) {
     const messages = (0, chat_db_1.getMessages)(db, worker.worktreeId, {
@@ -93,13 +199,16 @@ function findWorkerReply(db, worker, since) {
         instanceId: worker.instanceId,
         matchResolvedInstance: true,
     });
+    const requireTurnRow = requiresTurnRow(worker.cliToolId);
     // `getMessages` answers newest-first, so the first candidate IS the newest.
     for (const message of messages) {
         if (message.role !== 'assistant')
             continue;
         if (message.messageType === 'prompt')
             continue;
-        if (message.requestId?.startsWith(chat_db_1.RELAY_SYSTEM_REQUEST_ID_PREFIX))
+        if (isSystemRow(message.requestId))
+            continue;
+        if (requireTurnRow && !isTurnRow(message.requestId))
             continue;
         if (message.content.trim() === '')
             continue;
@@ -153,6 +262,42 @@ function sleep(ms) {
         setTimeout(resolve, ms);
     });
 }
+/**
+ * Hold out for the transcript row this scrape got ahead of, then stash it.
+ *
+ * Called for a tool whose answers come out of a transcript, on the completion
+ * edge the POLLER raised — which is the edge that fires early. #2386 measured
+ * the reader landing about five seconds behind it, so re-reading beats both
+ * giving up on the first look and delivering what is there instead.
+ *
+ * The re-read is {@link stashReplyForOpenRelays} and not
+ * {@link findWorkerReply}, because "is there an answer yet" has to be asked per
+ * relay against that relay's own `createdAt`: a marked row older than the relay
+ * answered somebody else's question and must not end the wait. The stash itself
+ * is guarded on `pending_kind IS NULL`, so asking repeatedly costs reads and
+ * never a second payload.
+ *
+ * Returns having delivered nothing when the grace elapses. See
+ * {@link RELAY_TURN_ROW_GRACE_MS} for why that is the safe direction.
+ */
+async function deliverWhenTranscriptCatchesUp(db, worker) {
+    const deadline = Date.now() + RELAY_TURN_ROW_GRACE_MS;
+    for (;;) {
+        if (stashReplyForOpenRelays(db, worker, Date.now()) > 0) {
+            void pumpRelayDeliveries();
+            return;
+        }
+        if (Date.now() >= deadline)
+            break;
+        await sleep(RELAY_TURN_ROW_POLL_MS);
+    }
+    logger.info('relay-scrape-row-not-transcript-backed', {
+        worktreeId: worker.worktreeId,
+        cliToolId: worker.cliToolId,
+        instanceId: worker.instanceId,
+        graceMs: RELAY_TURN_ROW_GRACE_MS,
+    });
+}
 /**
  * B finished a turn. Deliver it, or arrange to.
  *
@@ -174,6 +319,15 @@ async function notifyRelayTurnCompleted(worker, options) {
                 void pumpRelayDeliveries();
             return;
         }
+        // The scrape path, and it forks on who is allowed to write this worker's
+        // answers. A tool with a transcript has an authoritative record, so the
+        // scraped row this announcement is about is not a candidate at all — the
+        // relay waits for the marked one instead of watching an unmarked one hold
+        // still (Issue #2401).
+        if (requiresTurnRow(worker.cliToolId)) {
+            await deliverWhenTranscriptCatchesUp(db, worker);
+            return;
+        }
         // The scrape path. The row that is newest now may be a frame mid-draw, so
         // the delivery waits until the newest row stops changing — bounded, because
         // an agent that keeps writing is an agent whose next completion will trigger

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "commandmate",
-  "version": "0.32.0",
+  "version": "0.33.0",
   "description": "A local control plane for agent CLIs — orchestration and visibility for Claude Code, Codex, Gemini CLI, and more across Git worktrees",
   "keywords": [
     "claude-code",