commandmate 0.30.2 → 0.31.0

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

@@ -0,0 +1,392 @@
+"use strict";
+/**
+ * Codex's dialog rules, read off the frame's STRUCTURE rather than its wording
+ * (Issue #2310).
+ *
+ * ## The defect these rules exist for
+ *
+ * Until #2310 the only thing that told `detect.ts` "a codex dialog is on screen"
+ * was a footer whitelist — `CODEX_SELECTION_LIST_PATTERN`, i.e. the literal
+ * words `press enter to confirm` / `press enter to select`. Every dialog codex
+ * closes with any other sentence fell straight through to the two branches that
+ * read `^›` as the idle composer (branch B of `afterThinking`, and the shared
+ * chain's step 3), and those publish **`ready`**. Two live captures of
+ * codex-cli 0.153.2 at the production 200x1000 geometry, both blocked on a
+ * keypress and both reported `ready` before this module existed
+ * (`tests/unit/lib/detection/fixtures/codex-live-2310/`):
+ *
+ * | screen | footer | why the whitelist missed it |
+ * |---|---|---|
+ * | `/experimental` | `Press space to select or enter to save for next conversation` | `press SPACE to select`, not `press enter to select` |
+ * | `/keymap` | `left/right group · enter edit shortcut · … · esc close` | no `press … to …` clause at all |
+ *
+ * A `ready` there is not cosmetic: Auto-Yes concludes there is nothing to
+ * answer, the sidebar dot goes green, and `commandmate wait` takes the frame as
+ * its `scraper_ready` completion — a false "Completed" on a session that has not
+ * moved since the operator's last keypress.
+ *
+ * Note what BOTH real leaks have in common and what the Issue's own analysis
+ * assumed they would not: **neither list is numbered.** A rule written only
+ * around `findNumberedOptionBlock` would still report both as `ready`, so the
+ * primary rule here is the attribute one below and the numbered block is the
+ * corroborating second reading, not the other way round.
+ *
+ * ## Why the attributes and not the text
+ *
+ * codex puts `›` (U+203A) at column 0 in three different places, and after
+ * `stripAnsi` all three are the same byte. The measured separation (0.153.2,
+ * cross-checked against the 0.148.0 / 0.151.0 captures already in the tree) is:
+ *
+ * ```text
+ * ESC[1m›ESC[0m ESC[2mAsk Codex to do anythingESC[0m      composer, empty  → composer
+ * ESC[1m›ESC[0m 1. buy milk                               composer, typed  → composer
+ * ESC[1;2m› ESC[0mCreate a file scripts/greet.sh          transcript echo  → dim glyph
+ * 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
+ * ```
+ *
+ * `composer-residual-leading-number.txt` is the frame that rules out the cheap
+ * text guard: it is a composer holding the hand-typed string `1. buy milk`, so
+ * "a `›` followed by a digit and a dot is an option" would call an idle session
+ * `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.
+ *
+ * ## Why this duplicates a little of `composer-text.ts`
+ *
+ * That module has the same SGR scan and the same three-way measurement, and it
+ * is the right module to share it from. It is outside this Issue's `scope.allow`
+ * and its `isCodexComposerRow` is not exported, so the scan is re-stated here.
+ * The two differ on purpose in one place — `composer-text.ts` accepts a row with
+ * a plain glyph and a plain label as the composer, which is right when the job
+ * is "find the input box near the bottom" and wrong here, where the same shape
+ * is the 0.151+ trust dialog's option. If they are ever merged, that difference
+ * is the one to carry across, not to smooth over.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.CODEX_DIALOG_FOOTER_PATTERN = exports.CODEX_DIALOG_RULES_VERIFIED_AGAINST = exports.CODEX_GLYPH = void 0;
+exports.readCodexGlyphRowKind = readCodexGlyphRowKind;
+exports.findCodexBottomGlyphRow = findCodexBottomGlyphRow;
+exports.readCodexDialogFrame = readCodexDialogFrame;
+exports.reportCodexDialogFooterDrift = reportCodexDialogFooterDrift;
+exports.resetCodexDialogFooterDriftForTests = resetCodexDialogFooterDriftForTests;
+const logger_1 = require("../../../../lib/logger");
+const dialog_block_1 = require("../dialog-block");
+const logger = (0, logger_1.createLogger)('codex-dialog-rules');
+/** codex's selection-cursor / composer glyph, U+203A. */
+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.
+ */
+exports.CODEX_DIALOG_RULES_VERIFIED_AGAINST = {
+    version: '0.153.2',
+    capturedAt: '2026-09-04',
+    paneGeometry: '200x1000',
+};
+/**
+ * The footer vocabulary codex closes its dialogs with — a SECONDARY signal.
+ *
+ * Deliberately not a gate. #2310 exists because a footer whitelist was load
+ * bearing, and widening the whitelist would only move the next wording change
+ * one sentence further away. What this pattern is for is the opposite: when
+ * {@link readCodexDialogFrame} recognises a dialog by structure and this pattern
+ * does NOT recognise its footer, that is a codex rewording worth a line in the
+ * log ({@link reportCodexDialogFooterDrift}) rather than a silent miss.
+ *
+ * Every measured footer matches one of the two alternatives:
+ *
+ * | footer | screen | alternative |
+ * |---|---|---|
+ * | `Press enter to confirm or esc to cancel` | approval | both |
+ * | `Press enter to confirm or esc to go back` | `/model`, `/permissions` | both |
+ * | `Press enter to continue` | trust, sign-in | 1st |
+ * | `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 |
+ * | `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 };
+/**
+ * Apply one SGR parameter list to the running attribute state.
+ *
+ * The extended-colour introducers are consumed with their arguments because
+ * those arguments would otherwise be read as attributes: `ESC[38;5;2m` is
+ * "foreground = palette colour 2", and a naive scan sees the `2` and marks the
+ * rest of the row dim — which is exactly codex's own option colouring
+ * (`ESC[38;5;6m`) and would turn every dialog row into a transcript echo.
+ */
+function applySgr(params, state) {
+    const parts = params === '' ? ['0'] : params.split(';');
+    let { bold, dim, coloured } = state;
+    for (let i = 0; i < parts.length; i++) {
+        const code = parts[i] === '' ? 0 : Number(parts[i]);
+        if (Number.isNaN(code))
+            continue;
+        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;
+            continue;
+        }
+        if (code === 48 || code === 58) {
+            // Background / underline colour: same argument shapes, no bearing here.
+            const mode = parts[i + 1] === '' || parts[i + 1] === undefined ? -1 : Number(parts[i + 1]);
+            if (mode === 5)
+                i += 2;
+            else if (mode === 2)
+                i += 4;
+            else
+                i += 1;
+            continue;
+        }
+        if (code === 0) {
+            bold = false;
+            dim = false;
+            coloured = false;
+        }
+        else if (code === 1)
+            bold = true;
+        else if (code === 2)
+            dim = true;
+        else if (code === 22) {
+            bold = false;
+            dim = false;
+        }
+        else if (code === 39)
+            coloured = false;
+        else if ((code >= 30 && code <= 37) || (code >= 90 && code <= 97))
+            coloured = true;
+    }
+    return { bold, dim, coloured };
+}
+/**
+ * Split one raw pane row into rendered characters tagged with their attributes.
+ *
+ * Escape sequences are consumed, never emitted: CSI (`ESC[…letter`) updates the
+ * attribute state when it ends in `m` and is otherwise skipped, and OSC
+ * (`ESC]…BEL` or `ESC]…ESC\`, which tmux emits for hyperlinks) is skipped whole.
+ */
+function scanAttributedChars(row) {
+    const out = [];
+    let state = INITIAL_SGR;
+    let i = 0;
+    while (i < row.length) {
+        const ch = row[i];
+        if (ch !== '\x1b') {
+            out.push({ ch, attrs: state });
+            i++;
+            continue;
+        }
+        const next = row[i + 1];
+        if (next === '[') {
+            let j = i + 2;
+            while (j < row.length && !/[A-Za-z]/.test(row[j]))
+                j++;
+            if (j >= row.length)
+                break; // truncated sequence: nothing renderable follows
+            if (row[j] === 'm')
+                state = applySgr(row.slice(i + 2, j), state);
+            i = j + 1;
+            continue;
+        }
+        if (next === ']') {
+            let j = i + 2;
+            while (j < row.length) {
+                if (row[j] === '\x07') {
+                    j++;
+                    break;
+                }
+                if (row[j] === '\x1b' && row[j + 1] === '\\') {
+                    j += 2;
+                    break;
+                }
+                j++;
+            }
+            i = j;
+            continue;
+        }
+        // Any other two-byte escape (charset switch, etc.): drop it.
+        i += 2;
+    }
+    return out;
+}
+/**
+ * Classify one RAW pane row whose first rendered glyph is `›`.
+ *
+ * @param rawRow - One row of the capture, ANSI intact
+ * @returns the row's kind, or `null` when the row is not a `›` row at all or
+ *   carries no attributes to read it by
+ *
+ * `null` for an attribute-free row is the load-bearing case, not a formality:
+ * Auto-Yes hands the detection layer a capture that has already been through
+ * `stripAnsi`, and on that input every one of the three `›` uses is the same
+ * text. Answering `'option'` there would call an idle composer `waiting`, so the
+ * absence of attributes is reported as "cannot tell" and the callers fall back
+ * to the reading they had before #2310.
+ */
+function readCodexGlyphRowKind(rawRow) {
+    if (!rawRow.includes('\x1b'))
+        return null;
+    const chars = scanAttributedChars(rawRow);
+    const glyphIndex = chars.findIndex(c => c.ch.trim() !== '');
+    if (glyphIndex < 0 || chars[glyphIndex].ch !== exports.CODEX_GLYPH)
+        return null;
+    const glyph = chars[glyphIndex].attrs;
+    // The transcript echo of a message the operator already sent. Checked first:
+    // codex draws it `ESC[1;2m`, so it is bold as well as dim.
+    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)
+        return 'option';
+    return 'composer';
+}
+/**
+ * Find and classify the bottom-most `›` row of a raw capture.
+ *
+ * "Bottom-most" is the whole point, and it is the same rule `isCodexPromptReady`
+ * and `codexActiveRegionLines` already apply for their own questions: codex
+ * draws on the normal screen, so a dialog the operator answered minutes ago is
+ * still in the frame with its options intact (Issue #1160). Only the LAST `›`
+ * row says what the pane is doing now — and when a turn is generating, that row
+ * is the composer, which is why this reads `running` frames as `composer` and
+ * leaves them to the thinking branches.
+ *
+ * @param raw - The capture exactly as it arrived, ANSI intact
+ */
+function findCodexBottomGlyphRow(raw) {
+    const rows = raw.split('\n');
+    for (let i = rows.length - 1; i >= 0; i--) {
+        const kind = readCodexGlyphRowKind(rows[i]);
+        if (kind !== null)
+            return { kind, row: i };
+    }
+    return null;
+}
+/** How many non-blank rows below the dialog are read as its footer. */
+const FOOTER_SCAN_ROWS = 8;
+function readFooterBelow(contentLines, fromExclusive, endExclusive) {
+    const rows = [];
+    for (let i = fromExclusive + 1; i < endExclusive && rows.length < FOOTER_SCAN_ROWS; i++) {
+        const row = contentLines[i].trim();
+        if (row === '')
+            continue;
+        rows.push(row);
+    }
+    return rows.join('\n');
+}
+/**
+ * Does this frame show a codex dialog the operator has to answer?
+ *
+ * Two independent readings, either of which is enough:
+ *
+ *  1. **the glyph rule** — the bottom-most `›` row of the RAW capture is an
+ *     option row ({@link readCodexGlyphRowKind}). This is the one that catches
+ *     the unnumbered menus #2310 was raised for.
+ *  2. **the numbered block** — `findNumberedOptionBlock` found a `›`-selected
+ *     run of options ending within a few rows of the content end. This is the
+ *     reading that survives `stripAnsi`, and it is vetoed by the glyph rule when
+ *     that positively says the row is the composer, so a composer holding the
+ *     hand-typed text `1. buy milk` cannot be adopted as a dialog.
+ *
+ * Neither reading consults the footer. The footer is reported back so the caller
+ * can log a codex rewording; see {@link CODEX_DIALOG_FOOTER_PATTERN}.
+ *
+ * @param raw - The capture with ANSI intact (`NormalizedFrame.raw`)
+ * @param contentLines - The ANSI-stripped rows with trailing padding removed
+ * @param contentEnd - Exclusive end of the conversation region (the row above
+ *   codex's status bar, or `contentLines.length` when the bar is not on screen)
+ */
+function readCodexDialogFrame(raw, contentLines, contentEnd) {
+    const glyphRow = findCodexBottomGlyphRow(raw);
+    const block = (0, dialog_block_1.findNumberedOptionBlock)(contentLines, contentEnd);
+    const blockIsDialog = block !== null && block.selectedGlyph === exports.CODEX_GLYPH;
+    const by = glyphRow?.kind === 'option'
+        ? 'glyph'
+        : blockIsDialog && glyphRow?.kind !== 'composer' && glyphRow?.kind !== 'transcript-echo'
+            ? 'numbered-block'
+            : null;
+    if (by === null)
+        return null;
+    // The block's own footer when there is a block; otherwise the rows under the
+    // highlighted row. `block.lastRow` and the glyph row are indices into the same
+    // ANSI-stripped `contentLines`, so both spellings read the same rows.
+    const footer = block !== null
+        ? block.footer
+        : readFooterBelow(contentLines, findLastGlyphContentRow(contentLines, contentEnd), contentEnd);
+    return {
+        by,
+        options: block?.options ?? [],
+        footer,
+        footerRecognised: exports.CODEX_DIALOG_FOOTER_PATTERN.test(footer),
+    };
+}
+/** Index of the bottom-most `›` row within the content region, or -1. */
+function findLastGlyphContentRow(contentLines, endExclusive) {
+    for (let i = Math.min(endExclusive, contentLines.length) - 1; i >= 0; i--) {
+        if (contentLines[i].trimStart().startsWith(exports.CODEX_GLYPH))
+            return i;
+    }
+    return -1;
+}
+/**
+ * Footers already reported, so a rewording costs one log line and not one per
+ * poll tick.
+ *
+ * Bounded because the key is frame text: a footer that varies (a countdown, a
+ * path) would otherwise grow the set without bound. At the cap the tracker stops
+ * recording rather than evicting — the point is the FIRST sighting of a new
+ * wording, and a process that has already seen 64 of them has been told.
+ */
+const reportedFooters = new Set();
+const REPORTED_FOOTER_CAP = 64;
+/**
+ * Record that a structurally recognised codex dialog closed with a footer this
+ * layer does not know (Issue #2310).
+ *
+ * The detection still stands — that is the whole point of judging the structure
+ * — so this is not a warning about the verdict. It is the tripwire on the thing
+ * that actually rots: codex's wording. #2310 was reported months after
+ * `/experimental` and `/keymap` started falling through, because nothing in the
+ * pipeline said so out loud.
+ */
+function reportCodexDialogFooterDrift(footer) {
+    const key = footer.slice(0, 200);
+    if (reportedFooters.has(key))
+        return;
+    if (reportedFooters.size >= REPORTED_FOOTER_CAP)
+        return;
+    reportedFooters.add(key);
+    logger.warn('codexDialogFooterUnrecognised', {
+        footer: key,
+        verifiedAgainst: exports.CODEX_DIALOG_RULES_VERIFIED_AGAINST.version,
+        hint: 'codex reworded a dialog footer; widen CODEX_DIALOG_FOOTER_PATTERN after re-capturing the frame',
+    });
+}
+/** Test-only: forget the footers already reported. */
+function resetCodexDialogFooterDriftForTests() {
+    reportedFooters.clear();
+}

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

@@ -19,6 +19,7 @@ exports.isCodexStalePrompt = isCodexStalePrompt;
 const cli_patterns_1 = require("../../cli-patterns");
 const prompt_detector_1 = require("../../prompt-detector");
 const status_reason_1 = require("../../status-reason");
+const cli_patterns_2 = require("./cli-patterns");
 const prompt_1 = require("./prompt");
 const frame_1 = require("../frame");
 const run_detection_1 = require("../run-detection");
@@ -139,6 +140,19 @@ function isCodexApprovalRequest(promptDetection, selectionWindow) {
     const question = promptDetection.promptData?.question?.trim() ?? '';
     return question.endsWith('?') || cli_patterns_1.CODEX_APPROVAL_FOOTER_PATTERN.test(selectionWindow);
 }
+/**
+ * Issue #2310: does the RAW frame positively show that its bottom-most `›` row
+ * is a dialog's highlighted row rather than the composer?
+ *
+ * The one question the ANSI-stripped `contentLines` cannot answer, asked in the
+ * two places that would otherwise publish `ready` off `CODEX_PROMPT_PATTERN`
+ * alone. False only means "not shown to be a dialog" — a stripped capture, a
+ * transcript echo and a genuine composer all answer false — so this can withhold
+ * an `ready` but never create one.
+ */
+function isCodexDialogGlyphTail(raw) {
+    return (0, cli_patterns_2.findCodexBottomGlyphRow)(raw)?.kind === 'option';
+}
 exports.codexStatusDetector = (0, run_detection_1.createToolStatusDetector)({
     tool: 'codex',
     verifiedAgainst: exports.VERIFIED_AGAINST,
@@ -240,6 +254,61 @@ exports.codexStatusDetector = (0, run_detection_1.createToolStatusDetector)({
                 };
             }
         }
+        // 0.85. Codex: every OTHER dialog — recognised by structure (Issue #2310)
+        //
+        // Branch 0.8 above is a footer whitelist, and a dialog codex closes with any
+        // other sentence walks straight past it into the two branches that read `^›`
+        // as the idle composer (branch B below, and the shared chain's step 3), both
+        // of which publish `ready`. Measured on codex-cli 0.153.2 at 200x1000:
+        // `/experimental` ends on "Press space to select or enter to save for next
+        // conversation" and `/keymap` on "left/right group · enter edit shortcut · …
+        // · esc close"; both were reported `ready` while blocked on a keypress, which
+        // is what makes Auto-Yes see nothing to answer, the sidebar dot go green and
+        // `commandmate wait` close on `scraper_ready` mid-task.
+        //
+        // So this branch does not read the footer at all — `readCodexDialogFrame`
+        // judges the shape: the bottom-most `›` row of the RAW frame carrying a
+        // dialog's attributes rather than the composer's, or a `›`-selected numbered
+        // block at the foot of the content region (the reading that still answers
+        // once ANSI has been stripped). Neither of the two live leaks is numbered,
+        // which is why the attribute rule is the primary one.
+        //
+        // The verdict deliberately mirrors what the chain would have said one step
+        // later, so no frame that already resolved changes: a dialog `detectPrompt`
+        // can parse is still `PROMPT_DETECTED` with `hasActivePrompt` (step 1's
+        // answer — the trust dialog and any reworded approval keep exit 10 for
+        // `wait --on-prompt agent`), and everything else is a navigable selection
+        // list. The #1160 staleness guard applies as it does in 0.8: an answered
+        // block with codex working below it is scrollback, not a dialog — and the
+        // glyph rule agrees independently, because the bottom-most `›` on such a
+        // frame is the composer codex draws while it works.
+        const codexDialogFrame = (0, cli_patterns_2.readCodexDialogFrame)(frame.raw, contentLines, findCodexContentEnd(contentLines));
+        if (codexDialogFrame && !isCodexStalePrompt(contentLines)) {
+            // The footer is not consulted for the verdict; an unrecognised one means
+            // codex reworded a screen, which is worth saying out loud exactly once.
+            if (!codexDialogFrame.footerRecognised) {
+                (0, cli_patterns_2.reportCodexDialogFooterDrift)(codexDialogFrame.footer);
+            }
+            const codexPromptDetection = (0, prompt_detector_1.detectPrompt)((0, cli_patterns_1.stripBoxDrawing)(frame.clean), (0, cli_patterns_1.buildDetectPromptOptions)('codex'));
+            if (codexPromptDetection.isPrompt) {
+                return {
+                    status: 'waiting',
+                    confidence: 'high',
+                    reason: status_reason_1.STATUS_REASON.PROMPT_DETECTED,
+                    hasActivePrompt: true,
+                    evidence: 'positive',
+                    promptDetection: codexPromptDetection,
+                };
+            }
+            return {
+                status: 'waiting',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.CODEX_SELECTION_LIST,
+                hasActivePrompt: false,
+                evidence: 'positive',
+                promptDetection: codexPromptDetection,
+            };
+        }
         return null;
     },
     isStalePrompt(frame) {
@@ -292,7 +361,17 @@ exports.codexStatusDetector = (0, run_detection_1.createToolStatusDetector)({
                 //
                 // The evidence stays `positive` here: codex has no measured idle rule yet
                 // (see the module docstring), so DR2-002 keeps its pre-#1927 reading.
-                if (cli_patterns_1.CODEX_PROMPT_PATTERN.test(contentLines[lastContentIdx].trim())) {
+                //
+                // Issue #2310: `^›` alone does not say "composer". codex draws the same
+                // glyph on a dialog's highlighted row, and reading one as the input line
+                // is what published `ready` for a session blocked on a keypress. Branch
+                // 0.85 already turns those frames back before the chain reaches here, so
+                // this is the second reading of the same fact rather than the only one —
+                // and it is written as a veto, not a test: only a RAW frame that
+                // positively shows a dialog row withholds `ready`, so a capture whose
+                // ANSI has been stripped still reports idle exactly as it did before.
+                if (cli_patterns_1.CODEX_PROMPT_PATTERN.test(contentLines[lastContentIdx].trim()) &&
+                    !isCodexDialogGlyphTail(frame.raw)) {
                     return {
                         status: 'ready',
                         confidence: 'high',
@@ -327,7 +406,9 @@ exports.codexStatusDetector = (0, run_detection_1.createToolStatusDetector)({
             while (codexTailIdx >= 0 && contentLines[codexTailIdx].trim() === '') {
                 codexTailIdx--;
             }
-            const codexTailIsIdlePrompt = codexTailIdx >= 0 && cli_patterns_1.CODEX_PROMPT_PATTERN.test(contentLines[codexTailIdx].trim());
+            const codexTailIsIdlePrompt = codexTailIdx >= 0 &&
+                cli_patterns_1.CODEX_PROMPT_PATTERN.test(contentLines[codexTailIdx].trim()) &&
+                !isCodexDialogGlyphTail(frame.raw);
             if (!codexTailIsIdlePrompt && (0, cli_patterns_1.detectThinking)('codex', frame.lastLines)) {
                 return {
                     status: 'running',

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

@@ -0,0 +1,159 @@
+"use strict";
+/**
+ * Command Code status detector (Issue #2250, 方針書 §4 D2).
+ *
+ * Command Code renders inline and pins a claude-shaped composer block to the
+ * bottom of the pane, so the shared chain does most of the work: the permission
+ * dialog is a numbered list with a `❯` cursor, which step 1's `detectPrompt`
+ * already reads, and the status row carries a spinner + `…` and `esc to
+ * interrupt`, which step 2's `detectThinking` already reads.
+ *
+ * What this module adds is `afterThinking`, and it exists because the generic
+ * composer check at step 3 would otherwise answer `ready` for a frame in which
+ * the composer is drawn and a turn is still in flight. That is not hypothetical
+ * on Command Code: the composer block stays on screen for the whole turn (see
+ * `turn-thinking.txt`, where `❯ Ask your question...` sits three rows under
+ * ` ⌘ Planning…  esc to interrupt`). Step 2's window is
+ * `THINKING_TAIL_LINE_COUNT` = 5 lines, and the status row is 4 rows above the
+ * last content row on that frame, so it fits today — but a wrapped composer adds
+ * rows between them and pushes it out, which is exactly the #805 failure claude
+ * had to add a wider footer window for. Re-checking thinking here, against the
+ * 15-line `lastLines` window, is that wider window.
+ *
+ * No `readIdleEvidence`: per §4 D1 決定 1's tool-by-tool rollout (DR2-002) a rule
+ * has to be read off the tool's OWN frames before it can gate anything, and the
+ * five frames captured for this Issue cover launch / thinking / done / dialog /
+ * tool-use rather than the awkward idle states (after a `/clear`, after an Esc
+ * interrupt) a completion rule has to survive. `detection-evidence-config` ships
+ * `legacy` to match.
+ *
+ * **Issue #2304 captured both of those idle states, and pinned the cost of not
+ * having the rule.** `tests/unit/detection/tools/command-code/fixtures.test.ts`
+ * defuses the busy vocabulary on a running frame and measures the answer:
+ * `ready` / `input_prompt` / `evidence: 'positive'` — a completion declared on
+ * the *absence* of a busy marker, which is exactly what D1 forbids. It costs
+ * nothing in production while the rollout says `legacy`, because
+ * `resolveIdleEvidence` short-circuits before a tool rule is consulted; what it
+ * costs is the rollout itself. The two frames a rule needs are now in
+ * `tests/fixtures/command-code-live-2250/`:
+ *
+ *  - after `/clear` — `boot-idle-1490.txt`, because the pane after `/clear` is
+ *    **byte-identical** to the launch screen. Unlike claude, which leaves
+ *    `new task? /clear to save …` behind and is the reason its own rule went
+ *    back to `observe` (#2011), Command Code repaints the banner;
+ *  - after an Esc interrupt — `idle-after-interrupt-1490.txt`, where Esc landed
+ *    before the agent had written anything, so the newest turn is a prompt echo
+ *    followed straight by `✻ Worked for 4s` with no `⠶` reply row at all.
+ *
+ * Building the rule, and measuring its `observe` rate before it enforces
+ * anything, is deliberately a separate Issue: the table it would have to move
+ * lives in `@/config/detection-evidence-config`, and `afterThinking`'s idle
+ * branch below publishes `'positive'` outright rather than through
+ * `resolveIdleEvidence`, so a rule added without changing that would never run.
+ *
+ * No `detectDialog` either: Epic #2249 決定 3 keeps Auto-Yes on the legacy
+ * numbered-response path, because Command Code fires `PreToolUse` AFTER the
+ * dialog is answered, so a hook-driven permission decision cannot dismiss it.
+ *
+ * `afterPrompt` arrived with Issue #2297, for the one screen the shared chain
+ * genuinely could not read: the picker `/model` opens. It is a provider-grouped
+ * list of model NAMES — no option numbers — over a `› Type to search models...`
+ * row, closed by `type to search · ↑/↓ navigate · shift+↑/↓ jump provider ·
+ * enter to select · esc to cancel`. None of `detectPrompt`, `detectThinking` or
+ * the composer check matches any of that, so the frame reached the `default`
+ * floor and the chat surface offered it the answer characters — into the search
+ * box. Measured live on v1.40.1 at the production 200x1000 geometry; the capture
+ * is `tests/fixtures/chat-dialog-card-2254/command-code-model-1-40-1.txt`.
+ *
+ * ## What #2304 re-measured, and what it did not change
+ *
+ * Nothing here changed, and that is the finding. Seven frames were captured
+ * live on **1.49.0** — nine minor versions past the build these rules were read
+ * off — at the same 200x1000 geometry, and every rule answers identically,
+ * state for state. `verifiedAgainst` therefore still records 1.40.1: that is
+ * the build the rules were *read off*, and
+ * `tests/unit/detection/tools/command-code/fixtures.test.ts` is the receipt that
+ * they still hold. It also pins the picker's verdict for the three 1.47.1
+ * captures, which had none before — `afterPrompt` reading one build's picker was
+ * an assumption about the next.
+ *
+ * Two 1.49.0 observations are worth carrying here because they bound what the
+ * rules rest on:
+ *
+ *  - **A status verb can be three words with no `…`.** ` ✧ Shell command
+ *    allowed  esc to interrupt • 19s • ↓ 1.7k` is not read by
+ *    `COMMAND_CODE_THINKING_PATTERN`'s spinner branch, which wants
+ *    `[spinner] <one word>…`. Only the third alternative — the `esc to
+ *    interrupt` tail — reads it, and the tool drops that tail below 42 columns.
+ *    CommandMate panes are 200 wide, so it holds; a narrower pane would not.
+ *    The capture is `turn-shell-running-1490.txt`.
+ *  - **Evidence can be layered.** That same frame carries ` ✻ Thinking… (72
+ *    lines) [ctrl+o to expand]` two rows above the status row, so it stays
+ *    `running` when the status row alone is defused. The single-marker frames
+ *    (`turn-thinking.txt`, `turn-thinking-1490.txt`) do not, which is the D1 gap
+ *    described above.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.commandCodeStatusDetector = exports.VERIFIED_AGAINST = void 0;
+const cli_patterns_1 = require("../../cli-patterns");
+const selection_shape_1 = require("../../selection-shape");
+const status_reason_1 = require("../../status-reason");
+const run_detection_1 = require("../run-detection");
+const verified_against_1 = require("../verified-against");
+/** Command Code build these rules were read off (value in ../verified-against). */
+exports.VERIFIED_AGAINST = verified_against_1.COMMAND_CODE_VERIFIED_AGAINST;
+exports.commandCodeStatusDetector = (0, run_detection_1.createToolStatusDetector)({
+    tool: 'command-code',
+    verifiedAgainst: exports.VERIFIED_AGAINST,
+    afterPrompt(frame) {
+        // Issue #2297. Command Code's pickers (`/model` measured live on v1.40.1 at
+        // 200x1000) are arrow-driven overlays with a search box and a lower-case
+        // hint-bar footer. Nothing in the shared chain reads that footer, so before
+        // this branch the frame fell through to the `default` floor — which the chat
+        // surface renders as `unclassified`, i.e. with the `1`-`9` / `y` / `n`
+        // answer keys, and every one of those characters is typed into the picker's
+        // `Type to search models...` box rather than selecting anything.
+        //
+        // `waiting` + `positive`, exactly as claude's selection-list branch reports:
+        // a human has to move the highlight and press enter, and the frame says so
+        // in as many words.
+        if (selection_shape_1.COMMAND_CODE_SELECTION_LIST_FOOTER.test(frame.lastLines)) {
+            return {
+                status: 'waiting',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.COMMAND_CODE_SELECTION_LIST,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        return null;
+    },
+    afterThinking(frame) {
+        // The composer is drawn throughout a turn, so "running" has to be resolved
+        // before the generic composer check can say "ready". Widened window; see the
+        // module docblock.
+        if ((0, cli_patterns_1.detectThinking)('command-code', frame.lastLines)) {
+            return {
+                status: 'running',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.THINKING_INDICATOR,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        // Idle: the composer row is on screen and nothing is in flight. Same verdict
+        // the generic step 3 would reach, resolved here so the two cannot disagree
+        // about which window they read.
+        const { promptPattern } = (0, cli_patterns_1.getCliToolPatterns)('command-code');
+        if (promptPattern.test(frame.lastLines)) {
+            return {
+                status: 'ready',
+                confidence: 'high',
+                reason: status_reason_1.STATUS_REASON.INPUT_PROMPT,
+                hasActivePrompt: false,
+                evidence: 'positive',
+            };
+        }
+        return null;
+    },
+});