commandmate 0.39.0 → 0.40.0

package/dist/server/src/lib/detection/tools/codex/cli-patterns.js

@@ -44,7 +44,7 @@
  * ESC[1mESC[38;5;6m› 1. Yes, proceed (y)ESC[0m             approval option  → bold label
  * ESC[1mESC[38;5;6m› [ ] Network proxy  Apply network…     /experimental    → bold label
  * ESC[1mESC[38;5;6m› Global  - Open Agents      unboundESC[0m  /keymap      → bold label
- * ESC[38;5;6m› 1. Yes, continueESC[39m                     trust dialog     → coloured glyph
+ * ESC[38;5;6m› 1. Yes, continueESC[39m                     trust dialog     → glyph colour runs into the label
  * ```
  *
  * `composer-residual-leading-number.txt` is the frame that rules out the cheap
@@ -53,9 +53,37 @@
  * `waiting` — the shape #1883 turned into a send guard that rejected every send.
  *
  * {@link readCodexGlyphRowKind} therefore recognises an option **positively**
- * (bold label, or a non-default foreground on the glyph) instead of defining it
- * as "not the composer". Every unrecognised shape falls to `composer`, which is
- * the direction that costs nothing: it is what the code did before #2310.
+ * (bold label, or the glyph's colour running on into the label) instead of
+ * defining it as "not the composer". Every unrecognised shape falls to
+ * `composer`, which is what the code did before #2310.
+ *
+ * ## codex 0.155.1 colours the composer glyph (Issue #2798)
+ *
+ * Through 0.154.0 a coloured glyph was only ever a dialog's, so "the glyph has a
+ * non-default foreground" was read as an option on its own. 0.155.1 draws the
+ * idle composer's glyph bold AND in truecolor orange
+ * (`tests/fixtures/codex-idle-composer-0155/`):
+ *
+ * ```text
+ * ESC[1mESC[38;2;255;178;66m›ESC[0m ESC[2mAsk Codex to do anythingESC[0m   composer, empty (0.155.1)
+ * ```
+ *
+ * Read by colour alone that is an option, so every finished turn on 0.155.1
+ * published `waiting` / `codex_selection_list` next to a `ghost` composer: the
+ * chat pane stuck on the selection-list card, `commandmate wait` returned
+ * exit 10 instead of completing, and the Pick pad offered the assistant's own
+ * numbered paragraphs as choices. What still separates the two is where the
+ * colour stops. A dialog paints its highlighted row as ONE span — glyph and
+ * label in the same colour, with no attribute change between them — while the
+ * composer resets (`ESC[0m`) right after its glyph, on every measured build, so
+ * its label carries its own styling or none. The rule therefore reads the
+ * colour as option evidence only when the label is drawn in the glyph's colour,
+ * and reads a dim label — the composer's placeholder, the same signal
+ * `composer-text.ts` calls `ghost` — as the composer before it looks at colour.
+ * `codex-pasted-content.capture` (#2464, 0.154.0) is why "the label is coloured
+ * too" is not enough: a composer holding pasted text draws its
+ * `[Pasted Content …]` label cyan, and on 0.155.1 that label would sit next to
+ * an orange glyph.
  *
  * ## Why this duplicates a little of `composer-text.ts`
  *
@@ -84,16 +112,18 @@ exports.CODEX_GLYPH = '›';
  * The codex build these dialog rules were read off.
  *
  * Separate from `CODEX_VERIFIED_AGAINST` on purpose: that stamp is the whole
- * detector's (`tools/verified-against.ts`, outside this Issue's scope) and still
- * names 0.148.0, while the frames below are 0.153.2. Recording the newer
- * measurement here rather than leaving it unrecorded keeps a later reader able
- * to tell "this rule is wrong" from "this rule was right for 0.153.2"; the
- * detector-wide stamp should be raised to match the next time that file is in
- * scope.
+ * detector's (`tools/verified-against.ts`). It was held at 0.148.0 while one
+ * idle frame of the same 0.155.1 probe was misread for a reason outside these
+ * rules — the status-bar boundary — and advanced to 0.155.1 once Issue #2818
+ * fixed that boundary. The dialog frames themselves
+ * all read correctly on 0.155.1 (Issue #2808, `tests/fixtures/codex-dialogs-0155/`):
+ * the command approval, `/model`, `/experimental`, `/keymap` and the
+ * directory-trust screen are `waiting`, and every highlighted row is the
+ * one-span shape these rules key on. The rules were first read off 0.153.2.
  */
 exports.CODEX_DIALOG_RULES_VERIFIED_AGAINST = {
-    version: '0.153.2',
-    capturedAt: '2026-09-04',
+    version: '0.155.1',
+    capturedAt: '2026-09-21',
     paneGeometry: '200x1000',
 };
 /**
@@ -116,12 +146,13 @@ exports.CODEX_DIALOG_RULES_VERIFIED_AGAINST = {
  * | `Press t to trust all; enter to review hooks; esc to close` | hooks list | both |
  * | `Press t to trust; esc to go back` | hooks detail | both |
  * | `Press space to select or enter to save for next conversation` | `/experimental` | 1st |
+ * | `Press space to select or enter to save` | `/experimental` (0.155.1) | 1st |
  * | `left/right group · enter edit shortcut · … · esc close` | `/keymap` | 2nd |
  *
  * No `/g` (keeps `.test()` stateless) and no nested quantifiers (ReDoS-safe).
  */
 exports.CODEX_DIALOG_FOOTER_PATTERN = /press\s+\S+\s+to\s+\S|esc\s+(?:to\s+)?(?:cancel|close|dismiss|quit|exit|back|go\s+back)/i;
-const INITIAL_SGR = { bold: false, dim: false, coloured: false };
+const INITIAL_SGR = { bold: false, dim: false, fg: null };
 /**
  * Apply one SGR parameter list to the running attribute state.
  *
@@ -133,7 +164,7 @@ const INITIAL_SGR = { bold: false, dim: false, coloured: false };
  */
 function applySgr(params, state) {
     const parts = params === '' ? ['0'] : params.split(';');
-    let { bold, dim, coloured } = state;
+    let { bold, dim, fg } = state;
     for (let i = 0; i < parts.length; i++) {
         const code = parts[i] === '' ? 0 : Number(parts[i]);
         if (Number.isNaN(code))
@@ -141,13 +172,9 @@ function applySgr(params, state) {
         if (code === 38) {
             const mode = parts[i + 1] === '' || parts[i + 1] === undefined ? -1 : Number(parts[i + 1]);
             // 5 = 256-colour (one argument), 2 = 24-bit RGB (three arguments).
-            if (mode === 5)
-                i += 2;
-            else if (mode === 2)
-                i += 4;
-            else
-                i += 1;
-            coloured = true;
+            const argCount = mode === 5 ? 2 : mode === 2 ? 4 : 1;
+            fg = parts.slice(i + 1, i + 1 + argCount).join(';');
+            i += argCount;
             continue;
         }
         if (code === 48 || code === 58) {
@@ -164,7 +191,7 @@ function applySgr(params, state) {
         if (code === 0) {
             bold = false;
             dim = false;
-            coloured = false;
+            fg = null;
         }
         else if (code === 1)
             bold = true;
@@ -175,11 +202,11 @@ function applySgr(params, state) {
             dim = false;
         }
         else if (code === 39)
-            coloured = false;
+            fg = null;
         else if ((code >= 30 && code <= 37) || (code >= 90 && code <= 97))
-            coloured = true;
+            fg = String(code);
     }
-    return { bold, dim, coloured };
+    return { bold, dim, fg };
 }
 /**
  * Split one raw pane row into rendered characters tagged with their attributes.
@@ -259,8 +286,21 @@ function readCodexGlyphRowKind(rawRow) {
     if (glyph.dim)
         return 'transcript-echo';
     const label = chars.slice(glyphIndex + 1).find(c => c.ch.trim() !== '');
-    // Positively recognised: the two shapes every measured dialog row has.
-    if (label?.attrs.bold || glyph.coloured)
+    // A dialog renders its highlighted label bold; composer text never is.
+    if (label?.attrs.bold)
+        return 'option';
+    // Issue #2798: a dim label is the placeholder codex paints into an EMPTY
+    // composer (`Ask Codex to do anything`), which is the input box saying so
+    // itself. Checked before the colour, because from 0.155.1 on the composer's
+    // glyph is coloured too.
+    if (label?.attrs.dim)
+        return 'composer';
+    // Issue #2798: a coloured glyph alone is not a dialog — 0.155.1 draws the idle
+    // composer's `›` in orange. A dialog paints glyph and label as one span, so
+    // the colour counts only when the label is drawn in the glyph's own colour;
+    // the composer resets right after its glyph, and its pasted-content label is
+    // cyan, not the glyph's orange.
+    if (glyph.fg !== null && label?.attrs.fg === glyph.fg)
         return 'option';
     return 'composer';
 }

package/dist/server/src/lib/detection/tools/codex/detect.js

@@ -41,10 +41,18 @@ exports.VERIFIED_AGAINST = verified_against_1.CODEX_VERIFIED_AGAINST;
  */
 const CODEX_CONFIRMATION_FOOTER_PATTERN = /press\s+(?:number|enter)\s+to\s+confirm/i;
 const CODEX_NUMBERED_OPTION_PATTERN = /^\s*[❯›●]?\s*\d{1,2}[.)]\s/;
-/** Index of the Codex status bar within the last 10 content rows, or -1. */
+/**
+ * Index of the Codex status bar within the last 10 content rows, or -1.
+ *
+ * Issue #2818: a bar carrying a thread title or the Plan-mode badge after the
+ * path (codex 0.154.0+) is the same bar, so it is a boundary too. Without it
+ * such frames fell to branch D, whose 15-row tail still holds a finished
+ * turn's `• Ran …` record, and an idle session read `running`.
+ */
 function findCodexFooterBoundary(contentLines) {
     for (let ci = contentLines.length - 1; ci >= Math.max(0, contentLines.length - 10); ci--) {
-        if (cli_patterns_1.CODEX_STATUS_BAR_PATTERN.test(contentLines[ci]))
+        const line = contentLines[ci];
+        if (cli_patterns_1.CODEX_STATUS_BAR_PATTERN.test(line) || cli_patterns_1.CODEX_TRAILED_STATUS_BAR_PATTERN.test(line))
             return ci;
     }
     return -1;
@@ -216,7 +224,8 @@ exports.codexStatusDetector = (0, run_detection_1.createToolStatusDetector)({
         // prompts high in scrollback to falsely trigger NavigationButtons.
         //
         // Issue #1150: the status bar is located via CODEX_STATUS_BAR_PATTERN (version-
-        // independent; matches both legacy "N% left ·" and v0.141 "model · path" bars).
+        // independent; matches both legacy "N% left ·" and v0.141 "model · path" bars),
+        // and since #2818 via CODEX_TRAILED_STATUS_BAR_PATTERN too (0.154+ "· <title>").
         const codexFooterBoundary = findCodexFooterBoundary(contentLines);
         let codexContentEnd = codexFooterBoundary >= 0 ? codexFooterBoundary - 1 : contentLines.length - 1;
         while (codexContentEnd >= 0 && contentLines[codexContentEnd].trim() === '') {
@@ -402,6 +411,12 @@ exports.codexStatusDetector = (0, run_detection_1.createToolStatusDetector)({
             // Claude's interrupt-hint net. Gated so idle frames are unaffected:
             // only fires when the tail is NOT the idle › prompt, so an idle session still
             // falls through to the generic composer check.
+            //
+            // That gate does not hold when the bar is drawn but not recognised: the tail
+            // is then the bar, not the `›`, and a finished turn's `• Ran …` record in the
+            // 15-row window reads as running. That is how 0.154's titled bar misread
+            // idle sessions until #2818 taught findCodexFooterBoundary its shape — the
+            // cost of this net whenever codex redraws the bar again.
             let codexTailIdx = contentLines.length - 1;
             while (codexTailIdx >= 0 && contentLines[codexTailIdx].trim() === '') {
                 codexTailIdx--;

package/dist/server/src/lib/detection/tools/command-code/detect.js

@@ -95,6 +95,15 @@
  * reading declines. The move to `beforePrompt` is part of that: see the branch
  * for why the generic parser must not get this frame either before or after.
  *
+ * Issue #2761 put a second reading in `beforePrompt`, ahead of that one: the
+ * plan review overlay (1.58.0), identified by `Approve ctrl+a` / `Cancel esc`.
+ * It is there for the same reason — the shared parser must not get the frame —
+ * but for a different hazard: the rows above its footer are the plan itself, and
+ * a plan that ends in `(y/n)` reads as a yes/no prompt. Issue #2793 extended that
+ * reading to the two states of the overlay #2763 measured and #2761 had not seen:
+ * the action list focused (`❯ Approve  ctrl+a`), and the radio `ctrl+a` asks
+ * with comments pending.
+ *
  * ## What #2304 re-measured, and what it did not change
  *
  * Nothing here changed, and that is the finding. Seven frames were captured
@@ -138,6 +147,43 @@ exports.commandCodeStatusDetector = (0, run_detection_1.createToolStatusDetector
     tool: 'command-code',
     verifiedAgainst: exports.VERIFIED_AGAINST,
     beforePrompt(frame) {
+        // Issue #2761. The plan review overlay, read off its two footer rows.
+        //
+        // `beforePrompt` and not `afterPrompt`, and that placement is the point: the
+        // rows above the footer are the PLAN — free text the agent wrote — and the
+        // last eight of them sit inside the 15-row window the shared parser reads.
+        // A plan whose last line is `Do you want to proceed? (y/n)` or `Approve?` is
+        // read by that parser as a yes/no prompt (measured), which publishes
+        // `hasActivePrompt: true` and lets Auto-Yes type `y` — into the plan, as a
+        // comment. So this screen must be claimed before the parser sees it.
+        //
+        // `waiting` + the selection-list family: the arrows move a line cursor, a
+        // human has to decide, and nothing on this pane moves until they do.
+        // `hasActivePrompt: false` — there is no payload to answer with, and approval
+        // is never something Auto-Yes may do on its own.
+        //
+        // Issue #2793 widened what "this screen" covers, on two frames each that
+        // #2763 measured and this branch had missed:
+        //
+        //  - **the action list focused** (`❯ Approve  ctrl+a` / `❯ Cancel  esc`).
+        //    The footer pattern now takes the `❯` on either row. Missing it was a
+        //    false completion, not a gap: the frame fell through to the composer
+        //    check, `COMMAND_CODE_PROMPT_PATTERN` read the `❯` row as the composer,
+        //    and `wait` exited 0 on a plan nobody had approved;
+        //  - **the approve-with-comments radio** `ctrl+a` opens when comments are
+        //    pending (`←/→ choose · enter confirm · esc back`). The same verdict: it is
+        //    the same overlay, still waiting on a human's decision about the plan,
+        //    and the arrow pad (`◀` `▶` `Enter` `Esc`) is exactly what it asks for.
+        if (selection_shape_1.COMMAND_CODE_PLAN_REVIEW_FOOTER.test(frame.lastLines) ||
+            (0, selection_shape_1.isCommandCodePlanApproveChoice)(frame.lastLines)) {
+            return {
+                status: 'waiting',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.COMMAND_CODE_PLAN_REVIEW,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
         // Issue #2521 recognised this screen; Issue #2522 reads it.
         //
         // `AskUserQuestion` draws no footer, so neither `afterPrompt` branch below

package/dist/server/src/lib/detection/tools/command-code/dialog.js

@@ -139,19 +139,57 @@ const COMMAND_CODE_FREE_TEXT_OPTION_PATTERN = /^[^\S\n]*type\s+something\b/i;
 /**
  * A checkbox option — the row shape of a MULTI-select question.
  *
- * The same expression `prompt-answer-sender` and `prompt-answer-semantic` use to
- * recognise one, restated here (both are private to their modules) because this
- * reader has to DECLINE the screen rather than answer it: 対象外 says Review,
- * multi-select and free-text screens are not to be pushed through the
- * single-select parser, and the reason is mechanical. On a checkbox list the
- * digit TOGGLES a box and the confirm is a separate `Next` row, so a payload
- * that claimed "option 2 is the answer" would have `respond 2` tick a box and
- * stop — leaving the question up and the operator told it was answered.
- *
- * `unsupported` rather than `none`: the screen IS a live question and the human
- * has to be sent to the pane for it, which is exactly #2521's fallback.
+ * Issue #2522 used this to DECLINE the screen: on a checkbox list the digit
+ * toggles a box and the confirm is a separate `Submit` / `Next` row, so a
+ * payload claiming "option 2 is the answer" had `respond 2` tick a box and stop,
+ * leaving the question up and the operator told it was answered.
+ *
+ * Issue #2755 turns it into a READING instead. The prefix is stripped off the
+ * label, the ticked rows are reported as {@link MultipleChoiceOption.checked},
+ * and the payload says `multiSelect: true` so that every consumer that turns a
+ * number into keys branches on it. The decline survives for the one screen that
+ * still cannot be answered — a checkbox list with no confirm row, where nothing
+ * measured says how the question is committed.
+ *
+ * Three tick glyphs, all measured: `[x]` on the 1.54.1 capture #2753 was raised
+ * from, `[✔]` (U+2714) across #2754's twenty-six, and `[X]` because the two
+ * differ only in case and a build that switches is not worth a second Issue.
+ */
+const CHECKBOX_OPTION_PATTERN = /^\[[ xX\u2714]\]\s/;
+/** The tick half of {@link CHECKBOX_OPTION_PATTERN}: a box that is ON. */
+const CHECKBOX_TICKED_PATTERN = /^\[[xX\u2714]\]\s/;
+/**
+ * The confirm row of a multi-select question (Issue #2755).
+ *
+ * `Submit` on the last question of a call, `Next` on every other one, measured
+ * on 1.54.1. It carries NO number — the strict `1.`…`N.` run ends one row above
+ * it — and it is the row `findNumberedOptionBlock` files as `footer` and this
+ * module used to fold into the bottom option's label:
+ *
+ *     options[4].label = "[ ] Type something... Submit Enter to select | …"
+ *
+ * The cursor glyph is optional and is the reason this is not
+ * `/^\s*Submit\s*$/`: 1.54.1 draws `❯ Submit` the moment the cursor parks
+ * there (#2754 実測 1), and a pattern that missed that spelling would fold the
+ * row back into the label on exactly the frames #2755 exists for.
+ */
+const COMMAND_CODE_CONFIRM_ROW_PATTERN = /^[^\S\n]*(?:\u276F[^\S\n]*)?(?:Submit|Next)[^\S\n]*$/;
+/**
+ * 1.54.1's hint bar, which is not part of any option either (Issue #2755).
+ *
+ *     Enter to select | Arrow keys to navigate | 1-9 quick select | n notes | c chat | Esc to cancel
+ *
+ * Drawn only when the call carries more than one question (#2754 実測 3), which
+ * is why it is NOT used as evidence that this screen is up — the most dangerous
+ * spelling, one question with the cursor on `Submit`, draws no footer at all.
+ * It is read here for the one thing it is good for: keeping it out of the last
+ * option's label, where the tail walk would otherwise put it along with its
+ * `requiresTextInput` flag.
+ *
+ * Distinct from {@link COMMAND_CODE_SELECTION_LIST_FOOTER}, which is the `·`
+ * separated picker footer and is left exactly as #2753 left it.
  */
-const CHECKBOX_OPTION_PATTERN = /^\[[ x]\]\s/i;
+const COMMAND_CODE_QUESTION_HINT_BAR_PATTERN = /^[^\S\n]*Enter\s+to\s+select\b.*\|.*\bEsc\s+to\s+cancel[^\S\n]*$/i;
 /**
  * The same tail limits `prompt-detector.ts` applies to `rawContent`
  * (`RAW_CONTENT_MAX_LINES` / `RAW_CONTENT_MAX_CHARS`), restated because that
@@ -182,6 +220,13 @@ function unsupported(reason) {
 function readCommandCodeQuestionDialog(frame) {
     if (!frame)
         return { kind: 'none' };
+    // Issue #2755 §7: the Review page, before the question reading, because the
+    // two are told apart by what the rows SAY and not by their shape. Declined
+    // outright — see `'review-page'` — so neither this reader nor, through
+    // `beforePrompt`'s fallback verdict, the generic parser can turn `1. Submit`
+    // into an answerable default.
+    if ((0, selection_shape_1.readCommandCodeReviewPage)(frame) !== null)
+        return unsupported('review-page');
     // The positive recognition is #2521's, unchanged and not re-derived: the last
     // qualifying rule row, a tab strip under it, a question, a strict `1.`…`N.`
     // run and exactly one `❯` on one of its rows, with the pickers and panels the
@@ -199,6 +244,13 @@ function readCommandCodeQuestionDialog(frame) {
             ? unsupported('numbering-unreadable')
             : { kind: 'none' };
     }
+    // Issue #2755 §2 / §8. The region is this screen and the `❯` is not on a
+    // numbered row: `Submit`, `Next` or the `notes:` input. Nothing here can be
+    // answered — the digits are dead while the cursor is off the list — but the
+    // pane is a live question, so it takes #2521's manual-operation fallback and
+    // NOT the `ready` the composer check would otherwise publish off `❯ Submit`.
+    if (!region.cursorOnOptionRow)
+        return unsupported('cursor-outside-options');
     const lines = frame.replace(/\r\n/g, '\n').split('\n').map(ansi_1.stripAnsi);
     const regionRows = lines.slice(region.firstLineIndex, region.lastLineIndex + 1);
     if (regionRows.length > exports.COMMAND_CODE_QUESTION_MAX_REGION_ROWS) {
@@ -213,16 +265,32 @@ function readCommandCodeQuestionDialog(frame) {
     if (block === null)
         return unsupported('option-block-unreadable');
     const labels = [...block.options];
-    if (block.footer !== '') {
-        // Rows below the bottom option. The region's lower edge is the last row with
-        // content and this screen draws no footer, so they are that option's own
-        // description.
+    // Rows below the bottom option. On 1.53.0 there were none but a wrapped
+    // description, which 確定仕様 A folds into that option. 1.54.1 draws two rows
+    // that are NOT anybody's description — the `Submit` / `Next` confirm and the
+    // hint bar — and folding them produced the label #2754 recorded:
+    //
+    //     "[ ] Type something... Submit Enter to select | Arrow keys to navigate | …"
+    //
+    // Issue #2755 takes them out here rather than in `findNumberedOptionBlock`:
+    // that reader is shared by every tool's `prompt.ts`, and what a row below the
+    // last option MEANS is exactly the per-tool knowledge a tool module owns.
+    const tailRows = block.footer === '' ? [] : block.footer.split('\n');
+    const hasConfirmRow = tailRows.some((row) => COMMAND_CODE_CONFIRM_ROW_PATTERN.test(row));
+    const description = tailRows.filter((row) => !COMMAND_CODE_CONFIRM_ROW_PATTERN.test(row) &&
+        !COMMAND_CODE_QUESTION_HINT_BAR_PATTERN.test(row));
+    if (description.length > 0) {
         const last = labels.length - 1;
-        labels[last] = [labels[last], ...block.footer.split('\n')].join(' ').trim();
+        labels[last] = [labels[last], ...description].join(' ').trim();
     }
     if (labels.length !== region.optionCount)
         return unsupported('option-count-mismatch');
-    if (labels.some((label) => CHECKBOX_OPTION_PATTERN.test(label)))
+    // Issue #2755: a checkbox list is READ rather than declined — but only when
+    // the screen also draws the row that commits it. Without one, the digit
+    // toggles a box and nothing on this frame says what finishes the question, so
+    // #2522's decline stands.
+    const multiSelect = labels.some((label) => CHECKBOX_OPTION_PATTERN.test(label));
+    if (multiSelect && !hasConfirmRow)
         return unsupported('multi-select');
     // The default. Not `selectedGlyph` alone: `findNumberedOptionBlock`'s glyph
     // union is `[❯›●>]` because it serves every CLI, and `●` is this screen's TAB
@@ -259,11 +327,25 @@ function readCommandCodeQuestionDialog(frame) {
     // matters is that the descriptions are inside both: a deny pattern has to see
     // the sentence the option is actually promising.
     const dialogText = (0, prompt_detect_multiple_choice_1.joinApprovalTarget)(regionRows, tabOffset + 1, regionRows.length);
-    const built = (0, prompt_detect_multiple_choice_1.buildMultipleChoiceResult)(question, labels.map((label, index) => ({
+    // Issue #2755: the checkbox comes OFF the label and becomes state. A label
+    // that still read `[ ] calc.js` is what a user reported as "cannot pick more
+    // than one" (#2753's capture), and it is also what every label-matching
+    // consumer downstream — the deny patterns, `respond`'s semantic resolution,
+    // the answer panels — would have had to learn to strip for itself.
+    //
+    // `checked` is written on BOTH states of a multi-select row, because the
+    // sender computes a symmetric difference against it and "absent" would be
+    // indistinguishable from "unticked" at the one place the distinction decides
+    // whether a box is turned OFF. On a single-select row it is written on
+    // neither: 受入基準 (a) pins those payloads with `toStrictEqual`, and an
+    // added `checked: false` is exactly the drift that pin exists to catch.
+    const readOptions = labels.map((label, index) => ({
         number: index + 1,
-        label,
+        label: multiSelect ? label.replace(CHECKBOX_OPTION_PATTERN, '') : label,
         isDefault: index === block.selectedIndex,
-    })), { instructionText: dialogText, approvalTarget: dialogText }, regionRows.join('\n'), truncateRawContent, 
+        ...(multiSelect ? { checked: CHECKBOX_TICKED_PATTERN.test(label) } : {}),
+    }));
+    const built = (0, prompt_detect_multiple_choice_1.buildMultipleChoiceResult)(question, readOptions, { instructionText: dialogText, approvalTarget: dialogText }, regionRows.join('\n'), truncateRawContent, 
     // 確定仕様 D. The measured `QuestionPrompt` hands the ordinary choices to a
     // `SelectInput`, which calls `onSelect` on the DIGIT — so a trailing Enter
     // would land on whatever the tool painted next (the following question, or
@@ -290,10 +372,19 @@ function readCommandCodeQuestionDialog(frame) {
             ...built,
             promptData: {
                 ...promptData,
-                options: promptData.options.map((option) => option.requiresTextInput === true ||
-                    COMMAND_CODE_FREE_TEXT_OPTION_PATTERN.test(option.label)
-                    ? { ...option, requiresTextInput: true }
-                    : option),
+                // Only ever added, never set to `false`: see the `checked` note above.
+                ...(multiSelect ? { multiSelect: true } : {}),
+                // `buildMultipleChoiceResult` rebuilds every option from the three
+                // fields it takes, so `checked` is re-applied here rather than trusted
+                // to survive the shared builder (Issue #2755).
+                options: promptData.options.map((option, index) => {
+                    const checked = readOptions[index]?.checked;
+                    const withState = checked === undefined ? option : { ...option, checked };
+                    return option.requiresTextInput === true ||
+                        COMMAND_CODE_FREE_TEXT_OPTION_PATTERN.test(option.label)
+                        ? { ...withState, requiresTextInput: true }
+                        : withState;
+                }),
             },
         },
     };

package/dist/server/src/lib/detection/tools/verified-against.js

@@ -33,10 +33,37 @@ exports.CLAUDE_VERIFIED_AGAINST = {
     capturedAt: '2026-08-23',
     paneGeometry: '200x1000',
 };
-/** codex-cli these rules were read off (#1628 / #1829 / #1890 fixtures). */
+/**
+ * codex-cli these rules were read off (#1628 / #1829 / #1890 fixtures; re-read
+ * on 0.155.1 by #2808 / #2818).
+ *
+ * ## Held back by Issue #2808, advanced to 0.155.1 by Issue #2818
+ *
+ * #2808 re-captured codex **0.155.1** on a private tmux socket at 200x1000
+ * (`tests/fixtures/codex-dialogs-0155/`, 2026-09-21): the command approval,
+ * `/model`, `/experimental`, `/keymap` and the directory-trust screen all read
+ * `waiting`, each highlighted row the same one-span shape as the 0.146.0-0.153.2
+ * captures, and the idle composers read `ready`. The stamp stayed at 0.148.0
+ * because one frame of that probe was misread: the idle composer after a
+ * declined approval read `running`. From 0.154.0 on the status bar carries the
+ * thread's title after the path, `CODEX_STATUS_BAR_PATTERN` wants the path last,
+ * so the detector found no bar and its bar-independent branch D read the
+ * declined command's lingering `• Ran` row in the 15-row tail.
+ *
+ * #2818 made the titled bar a boundary (`CODEX_TRAILED_STATUS_BAR_PATTERN`) and
+ * probed 0.155.1 again on its own socket (`tests/fixtures/codex-thread-title-probe/`,
+ * 2026-09-21): a turn running `sleep 30` under a titled bar, the same turn after
+ * the command finished and codex was still working, and the idle composer once
+ * it had answered — the last with the `• Ran sleep 30` row still in the tail,
+ * which read `running` before the fix. The two running frames read `running`,
+ * both idle frames read `ready`, and no other frame in the tree changed its
+ * verdict. **The stamp moved to 0.155.1 because every 0.155.1 frame now reads
+ * correctly** (`codex-thread-title-bar-2818.test.ts`,
+ * `codex-dialogs-0155-2808.test.ts`).
+ */
 exports.CODEX_VERIFIED_AGAINST = {
-    version: '0.148.0',
-    capturedAt: '2026-08-15',
+    version: '0.155.1',
+    capturedAt: '2026-09-21',
     paneGeometry: '200x1000',
 };
 /**
@@ -140,10 +167,52 @@ exports.ANTIGRAVITY_VERIFIED_AGAINST = {
  * `detectDialog` declares. The rule itself was read off the 1.40.1 and 1.49.0
  * dialog frames above, and no 1.53.1 frame was added to the fixture directory,
  * so the condition in the previous paragraph is still unmet.
+ *
+ * ## Held back by Issue #2754, advanced to 1.54.1 by Issue #2773
+ *
+ * #2754 finally did the probe the paragraph above asked for: a live **1.54.1**
+ * session on a private tmux socket at 200x1000, twenty-six captures in
+ * `tests/fixtures/command-code-askuserquestion-2754/` (`capturedAt` is the day
+ * that probe ran, 2026-09-20), and every key in the screen's footer sent ONE AT
+ * A TIME with a capture on each side of it. By the letter of that paragraph the
+ * stamp could have moved then. It did not, because what the probe measured was
+ * that **the rules did not answer for 1.54.1**: nine of the 26 captures came out
+ * wrong, and six of those published `ready` / `input_prompt` for a live,
+ * unanswered question — #2521's 偽完了 on a real capture. Stamping 1.54.1 over
+ * frames the rules demonstrably misread would have made the probe report a
+ * measurement that said the opposite of what was measured — the fail-open
+ * version of the #2304 precedent rather than an application of it.
+ *
+ * The defects it found were closed one Issue at a time:
+ *
+ *  - **#2753** added `COMMAND_CODE_TAB_ANSWERED_MARKERS` (`✔`, U+2714), so a
+ *    strip like `✔ Party size | ● Update scope | ◯ Review` passes
+ *    `isCommandCodeQuestionTabRow` and eight frames left the generic parser;
+ *  - **#2755** closed the rest: (a) a `❯` outside the option list (`❯ Submit`,
+ *    `❯ Next`, `❯ notes:`) is named `cursor-outside-options` and hands the human
+ *    the screen instead of publishing `ready`; (b) the Review page is named
+ *    `review-page` and publishes no payload, so its default can no longer COMMIT
+ *    the answers; (c) checkbox lists (`1. [ ] …` / `Submit`) are read as
+ *    multi-select with the box off the label and the 1.54.1 footer off the last
+ *    option.
+ *
+ * **The stamp moved to 1.54.1 because all twenty-six frames now read correctly**
+ * (`askuserquestion-1541-2754.test.ts` pins each): fifteen publish an answerable
+ * payload, six are `cursor-outside-options` and two are `review-page` (both
+ * decline on purpose — a human is sent to the screen, Auto-Yes has nothing to
+ * send), two are `ready` because the question is gone, and one is `running`
+ * because it was caught mid-turn. False completions went from six to zero.
+ * The rules were re-read off THESE frames, so 1.54.1 is the build they were read
+ * off — not the build that happens to be installed. `getDetectorFreshness`
+ * compares this stamp with the CLI installed now and will say `stale` once that
+ * is newer, which is the probe doing its job.
+ *
+ * This stamp answers "which build were these rules read off", and
+ * {@link getDetectorFreshness} turns it into "are they current".
  */
 exports.COMMAND_CODE_VERIFIED_AGAINST = {
-    version: '1.40.1',
-    capturedAt: '2026-09-03',
+    version: '1.54.1',
+    capturedAt: '2026-09-20',
     paneGeometry: '200x1000',
 };
 /**

package/dist/server/src/lib/detection/tui-detection-frame.js

@@ -9,12 +9,27 @@
  * known prompt footers, excludes overlays rendered below the active prompt.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.isClaudeFooter = isClaudeFooter;
 exports.normalizeTuiFrameForDetection = normalizeTuiFrameForDetection;
-const CLAUDE_PROMPT_FOOTER_PATTERN = /Esc\s+to\s+cancel\s*[·•]\s*Tab\s+to\s+amend/i;
-const CLAUDE_PICKER_FOOTER_PATTERN = /Enter\s+to\s+select\b.*\bnavigate\b/i;
+// A real footer starts its row: in every capture measured for Issue 2776 only
+// whitespace precedes it (plus one SGR colour sequence in a raw capture), while
+// every measured quote of it has visible text first (`「`, `- Approval footer: `,
+// `navigate · `). A quote above the live prompt otherwise cut the frame at the
+// quote (Issue 2774: 963 of 1002 rows). The row end is NOT anchored: real
+// footers go on with more key hints (` · Esc to cancel`, ` · ctrl+e to explain`).
+// Position and discard-size limits were measured and rejected — see
+// docs/design/tui-frame-footer-scan-2776.md.
+const CLAUDE_PROMPT_FOOTER_PATTERN = /^(?:\s|\x1b\[[0-9;]*m)*Esc\s+to\s+cancel\s*[·•]\s*Tab\s+to\s+amend/i;
+const CLAUDE_PICKER_FOOTER_PATTERN = /^(?:\s|\x1b\[[0-9;]*m)*Enter\s+to\s+select\b.*\bnavigate\b/i;
 // A prompt/thinking/input anchor below a footer means that footer belongs to an
 // older frame. Task-panel rows intentionally do not match these patterns.
-const CLAUDE_LOWER_INTERACTIVE_ANCHOR = /^\s*[>❯]\s*(?:\d{1,2}[.)])?|esc\s+to\s+interrupt|[✻✽✶✢✳⦿◉●⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏]\s+.+…/i;
+// `›` (U+203A) is codex's composer glyph. Without it, a line anywhere in the
+// transcript that merely QUOTES a picker footer truncates the frame at that
+// line and the live composer below it is discarded — the agent then reads as
+// `running` / `default` forever (Issue 2774). The other six tools draw
+// `>` or `❯`, so this class is what they are already covered by.
+const CLAUDE_LOWER_INTERACTIVE_ANCHOR = /^\s*[>❯›]\s*(?:\d{1,2}[.)])?|esc\s+to\s+interrupt|[✻✽✶✢✳⦿◉●⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏]\s+.+…/i;
+/** Whether `line` is one of Claude's prompt/picker footer rows (not a quote of one). */
 function isClaudeFooter(line) {
     return CLAUDE_PROMPT_FOOTER_PATTERN.test(line) || CLAUDE_PICKER_FOOTER_PATTERN.test(line);
 }

package/dist/server/src/lib/polling/auto-yes-resolver.js

@@ -4,6 +4,8 @@
  *
  * Base rules (unchanged since Issue #479):
  * - yes/no prompt -> 'y'
+ * - multiple_choice with `multiSelect: true` -> null (Issue #2755: the number
+ *   ticks a box, the confirm is a separate row, so a default is half an answer)
  * - multiple_choice with default option -> default option number
  * - multiple_choice without default -> first option number
  * - option requiring text input -> null (skip)
@@ -45,6 +47,12 @@ function resolveBaseAnswer(promptData) {
         return 'y';
     }
     if (promptData.type === 'multiple_choice') {
+        // Issue #2755: a checkbox question. A number ticks a box and the confirm is
+        // a separate row, so "the default option" is not an answer — it is half of
+        // one. Auto-Yes refuses the prompt instead of ticking something and stopping.
+        if (promptData.multiSelect === true) {
+            return null;
+        }
         const defaultOpt = promptData.options.find(o => o.isDefault);
         const target = defaultOpt ?? promptData.options[0];
         if (!target) {