commandmate 0.36.1 → 0.38.0

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

@@ -0,0 +1,104 @@
+"use strict";
+/**
+ * Command Code's permission dialog, read for the `detectDialog` seam
+ * (Issue #2574).
+ *
+ * ## What this is for, and what it is not
+ *
+ * Epic #2249 決定 3 left Command Code without a `detectDialog`, and its reason
+ * still holds: `PreToolUse` fires AFTER the dialog is answered, so a hook-driven
+ * permission decision cannot dismiss it, and Auto-Yes stays on the numbered
+ * response path. That decision is about who ANSWERS the dialog. It says nothing
+ * about how an answer has to be TYPED, which is the other thing `detectDialog`
+ * declares — `answerMode` for #2033's key guard, and `submitMode` for whether
+ * the sender follows the digit with an Enter. This module fills only that half;
+ * the Auto-Yes rollout for this tool stays `legacy` (see
+ * `AUTO_YES_DIALOG_GATE_DEFAULT_MODE`).
+ *
+ * ## Why the Enter is the defect
+ *
+ * Measured live on 1.53.1 at 200x1000: a bare `1` (or `2`) closes the dialog and
+ * runs the command — the digit is a hotkey. With no `submitMode` on the prompt,
+ * `sendPromptAnswer` resolved `answer_then_enter` and sent `C-m` a moment later,
+ * by which time the composer was back. A draft typed while the agent was
+ * thinking sat in that composer, and the Enter submitted it as a new user
+ * message. Declaring `answer_only` here moves that decision onto the frame the
+ * answer is actually sent at, so the Auto-Yes poller, `respond` and the chat
+ * surface all get it without each consumer having to re-read the screen.
+ *
+ * ## The shape, on every build captured
+ *
+ * The same rows on 1.40.1 (`dialog-create-file.txt`, `dialog-shell-command.txt`),
+ * 1.49.0 (`dialog-shell-1490.txt`, `dialog-kill-task-1490.txt`) and a live
+ * 1.53.1 pane:
+ *
+ *     ──────────────────────────… (200 columns)
+ *     Execute Shell Command
+ *     Command Code needs to execute sleep 25 && echo done.
+ *     Press [ctrl+e] to explain this command
+ *     ❯ 1. Yes
+ *       2. Yes, don't ask again for `sleep` commands in this project
+ *       3. No, tell Command Code what to do differently
+ *     ↑/↓ navigate · enter select · ctrl+e explain · Run cmd --yolo to bypass all permissions (Docs ↗)
+ *
+ * The rule is positional as well as textual: the hint bar must be the LAST
+ * content row and the numbered run must sit directly on top of it. Command Code
+ * draws its composer at the bottom of the pane for the whole of a turn and after
+ * it, so the only frames whose last row is not the composer are the ones where
+ * an overlay took its place. An agent reply that quotes the hint bar still has
+ * the composer under it, and an answered dialog is repainted as the tool call
+ * with the composer back below.
+ *
+ * ## Input contract
+ *
+ * Either spelling of the capture: as captured, or through
+ * `stripBoxDrawing(stripAnsi(...))` as Auto-Yes holds it. Nothing below reads
+ * the rule row `stripBoxDrawing` blanks, so both reach the same verdict.
+ *
+ * ## Deliberately not recognised
+ *
+ * `AskUserQuestion` (`./dialog.ts`, no footer), the `/model` picker (`enter to
+ * select · esc to cancel`) and the `/usage` panel (`Press Esc to close`). Their
+ * prompts already carry what they need, or have no prompt to answer, and while
+ * the rollout is `legacy` a `null` here gates nothing.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.COMMAND_CODE_PERMISSION_FOOTER_PATTERN = void 0;
+exports.detectCommandCodePermissionDialog = detectCommandCodePermissionDialog;
+const dialog_block_1 = require("../dialog-block");
+/**
+ * The hint bar under a permission dialog.
+ *
+ * `enter select` — not `enter to select`, which is the `/model` picker's — and
+ * the `to bypass all permissions` tail, which is what makes it a PERMISSION
+ * dialog rather than any other numbered overlay. `ctrl+e explain ·` sits
+ * between the two on shell commands and is absent on file edits, so the middle
+ * is not spelled out.
+ */
+exports.COMMAND_CODE_PERMISSION_FOOTER_PATTERN = /^\s*↑\/↓\s+navigate\s+·\s+enter\s+select\s+·.*\bto\s+bypass\s+all\s+permissions\b/;
+/** The cursor glyph Command Code draws on the highlighted option. */
+const COMMAND_CODE_CURSOR_GLYPH = '❯';
+/**
+ * Does this frame carry Command Code's permission dialog?
+ *
+ * @param frame - The normalised capture, either spelling (see the module docblock)
+ * @returns `permission` / `numbered` / `answer_only` with the drawn options, or null
+ */
+function detectCommandCodePermissionDialog(frame) {
+    const rows = frame.contentLines;
+    const footer = rows[rows.length - 1];
+    if (footer === undefined || !exports.COMMAND_CODE_PERMISSION_FOOTER_PATTERN.test(footer))
+        return null;
+    // One footer row and nothing else between it and the bottom option.
+    const block = (0, dialog_block_1.findNumberedOptionBlock)(rows, rows.length, 1);
+    if (block === null || block.footer !== footer.trim())
+        return null;
+    if (block.selectedGlyph !== COMMAND_CODE_CURSOR_GLYPH)
+        return null;
+    return {
+        kind: 'permission',
+        options: block.options,
+        answerMode: 'numbered',
+        submitMode: 'answer_only',
+    };
+}

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

@@ -132,6 +132,14 @@ exports.ANTIGRAVITY_VERIFIED_AGAINST = {
  * nobody took. When a live 1.53.x session is probed — the question screen, the
  * keys it accepts and what one of them advances — bump this to that exact
  * version with its own `capturedAt`.
+ *
+ * ## Not advanced by Issue #2574 either
+ *
+ * #2574 did send keys at a live 1.53.1 pane, but at the PERMISSION dialog, not
+ * the question screen: a bare digit commits it, which is the `submitMode` its
+ * `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.
  */
 exports.COMMAND_CODE_VERIFIED_AGAINST = {
     version: '1.40.1',

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

@@ -87,6 +87,8 @@ exports.AUTO_YES_DIALOG_GATE_MODES = ['enforce', 'legacy'];
  *   to write a dialog rule against. Gating it on a rule inferred from another
  *   tool's frames is the mistake #1979 had to correct; leaving it `legacy` keeps
  *   agy's Auto-Yes working exactly as it does today.
+ * - `command-code` is the one `legacy` tool that DOES declare rules (Issue
+ *   #2574), and they are not enough to gate on. See its row.
  */
 exports.AUTO_YES_DIALOG_GATE_DEFAULT_MODE = {
     claude: 'enforce',
@@ -99,8 +101,24 @@ exports.AUTO_YES_DIALOG_GATE_DEFAULT_MODE = {
     // Issue #2250 / Epic #2249 決定 3: Command Code's Auto-Yes stays on the legacy
     // numbered-response path. Its `PreToolUse` hook fires AFTER the permission
     // dialog is answered (measured: dialog 00:11:37, answer 00:11:46, hook
-    // 00:11:46), so a `permissionDecision` cannot dismiss the dialog and there is
-    // no measured dialog rule to gate on.
+    // 00:11:46), so a `permissionDecision` cannot dismiss the dialog.
+    //
+    // Issue #2574 gave the tool a `detectDialog` (`hasDialogRules: true`) and kept
+    // this row `legacy` on purpose. The rule recognises the PERMISSION dialog only;
+    // it exists to tell `sendPromptAnswer` that a digit commits without an Enter.
+    // Enforcing on it would break the other dialog this tool draws:
+    //
+    //  - `AskUserQuestion` (#2521 / #2522) is not a permission dialog, so
+    //    `judgeDialogPresence` would answer `present: false` for it and
+    //    `/prompt-response` would refuse a readable question with
+    //    `unsupported_dialog_layout`;
+    //  - teaching the rule that screen would not fix Auto-Yes either: the question
+    //    reader is anchored on the rule row `stripBoxDrawing` blanks
+    //    (`tools/command-code/dialog.ts`, 確定仕様 C), and this gate is handed the
+    //    box-stripped `cleanOutput`, so every question would be suppressed.
+    //
+    // Promote only once both dialogs are recognised on both spellings, with a
+    // `/prompt-response` test pinning that the question is still answered.
     'command-code': 'legacy',
 };
 /**

package/dist/server/src/lib/prompt-answer-sender.js

@@ -7,11 +7,12 @@
  * the promptType/defaultOptionNumber fallback introduced in Bug1).
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.PromptAnswerRejectedError = exports.ANSWER_MODE_KEYS_REASON = void 0;
+exports.FreeTextAtChoiceOnlyPromptError = exports.FreeTextAnswerRejectedError = exports.FREE_TEXT_AT_MENU_ROW_REASON = exports.PromptAnswerRejectedError = exports.ANSWER_MODE_KEYS_REASON = void 0;
 exports.sendPromptAnswer = sendPromptAnswer;
 const tmux_1 = require("./tmux/tmux");
 const frame_1 = require("../lib/detection/tools/frame");
 const registry_1 = require("../lib/detection/tools/registry");
+const prompt_detect_multiple_choice_1 = require("../lib/detection/prompt-detect-multiple-choice");
 const models_1 = require("../types/models");
 const tmux_capture_cache_1 = require("./tmux/tmux-capture-cache");
 const cli_tool_timing_config_1 = require("../config/cli-tool-timing-config");
@@ -67,6 +68,130 @@ class PromptAnswerRejectedError extends Error {
     }
 }
 exports.PromptAnswerRejectedError = PromptAnswerRejectedError;
+/**
+ * The reason code a caller gets back when free text meets a prompt whose
+ * text-bearing options are all menu rows (Issue #2573).
+ *
+ * The code `/prompt-response` already answers "this answer cannot be mapped onto
+ * a choice, and nothing was sent" with (#1681, #2522), so `respond` reports it
+ * without a new branch.
+ */
+exports.FREE_TEXT_AT_MENU_ROW_REASON = 'unresolvable_answer';
+/**
+ * The sentence for each refusal, built from a tool id and option numbers only.
+ *
+ * Fixed text, a tool id and option numbers, never the answer (SEC-003, as in
+ * `prompt-answer-semantic`): the answer is whatever the operator typed, and
+ * `/prompt-response` returns this message to the client verbatim.
+ *
+ * The two sentences sit side by side on purpose. They differ in the one thing
+ * the operator has to act on — what to do next — and that is only comparable
+ * when both are readable at once.
+ */
+function freeTextRefusalMessage(cliToolId, optionNumbers, detail) {
+    const numbers = optionNumbers.join(', ');
+    if (detail === undefined) {
+        return `Refused to type free text at ${cliToolId}'s prompt: option ${numbers} `
+            + 'reads as taking your own words, but on this screen it is a menu row, not a text field. '
+            + 'The text would be ignored and the Enter after it would confirm whatever is highlighted. '
+            + 'Nothing was sent. Answer with the option number, then send the instructions as a message.';
+    }
+    return `Refused to type free text at ${cliToolId}'s prompt: option ${numbers} is the text field `
+        + `on this screen, but the cursor is on option ${detail.cursorOptionNumber}. The text would be `
+        + `ignored and the Enter after it would confirm option ${detail.cursorOptionNumber}. Nothing `
+        + 'was sent. Move the cursor onto the text field in the terminal and send the text again — '
+        + 'sending its option number does not move the cursor, it selects nothing.';
+}
+/**
+ * Free text refused BEFORE any key reached the pane (Issue #2573, #2584).
+ *
+ * A sibling of {@link PromptAnswerRejectedError}, not a use of it, because the
+ * two cite different evidence. That one cites the dialog the tool's own rules
+ * vouched for (`dialogKind` / `answerMode`), and no such verdict can decide this
+ * case: Command Code has had rules since Issue #2574, and the permission dialog
+ * this guard is first about is vouched `numbered` — the verdict that lets a
+ * DIGIT through — while the `AskUserQuestion` screen whose free text must keep
+ * working is deliberately not recognised by those rules at all
+ * (`tools/command-code/permission.ts`). `answerMode` says how a CHOICE is
+ * pressed; it says nothing about which row is a text field, nor about which row
+ * the cursor is on. So what this one cites is the rows.
+ *
+ * One class rather than two because `/prompt-response` is out of reach of both
+ * Issues' scope and matches this type by `instanceof` to report the refusal at
+ * all; {@link FreeTextRefusalKind} is what tells the two cases apart.
+ */
+class FreeTextAnswerRejectedError extends Error {
+    /** Machine-readable code, always {@link FREE_TEXT_AT_MENU_ROW_REASON}. */
+    reason;
+    /**
+     * The text-bearing options this refusal is about: the menu rows for
+     * `menu_row`, the measured text field(s) for `cursor_elsewhere`.
+     */
+    optionNumbers;
+    /** Which measurement refused (Issue #2584). */
+    kind;
+    /** The option the Enter would have confirmed, or null for `menu_row`. */
+    cursorOptionNumber;
+    constructor(cliToolId, optionNumbers, detail) {
+        super(freeTextRefusalMessage(cliToolId, optionNumbers, detail));
+        this.name = 'FreeTextAnswerRejectedError';
+        this.reason = exports.FREE_TEXT_AT_MENU_ROW_REASON;
+        this.optionNumbers = optionNumbers;
+        this.kind = detail?.kind ?? 'menu_row';
+        this.cursorOptionNumber = detail?.cursorOptionNumber ?? null;
+    }
+}
+exports.FreeTextAnswerRejectedError = FreeTextAnswerRejectedError;
+/**
+ * Free text refused because NO row on the screen takes typed text (Issue #2583).
+ *
+ * ## The hole #2573 left
+ *
+ * {@link FreeTextAnswerRejectedError} looks for rows that READ as taking the
+ * operator's own words (`requiresTextInput`, i.e. `TEXT_INPUT_PATTERNS`) and
+ * only judges the answer when it finds at least one. A permission dialog with
+ * no such row was therefore never judged at all, and the text arm typed the
+ * answer and pressed Enter. Measured on 2026-09-16 against develop `9f4b4e29`:
+ *
+ * | tool | dialog | rows | result |
+ * |------|--------|------|--------|
+ * | Claude Code 2.1.273 | Bash command | `1. Yes` / `2. Yes, and always allow access to …` / `3. Yes, and switch to auto mode` / `4. No` | `success: true`, the `mkdir` RAN |
+ * | Antigravity 1.2.3 | Run this command? | `1. Yes, run command` / `2. Yes, and always allow …` / `3. Yes, … (Persist to settings.json)` / `4. No, cancel` | `success: true`, the `mkdir` RAN |
+ *
+ * Same screens, but with a path containing the word `custom`, `/custom/i`
+ * flagged the quoting row and #2573's guard refused. So what was left decided
+ * whether a refusal meaning "do not do this" approved instead: the SPELLING of
+ * the command being approved.
+ *
+ * ## What the caller is told, and why the count rather than the rows
+ *
+ * There is no row to name here — that is the whole condition — so the message
+ * cites how many options the screen has and points at the option number. It
+ * never quotes the answer (SEC-003, as in `prompt-answer-semantic`): the answer
+ * is whatever the operator typed and `/prompt-response` hands this message back
+ * to the client verbatim.
+ *
+ * Shares {@link FREE_TEXT_AT_MENU_ROW_REASON} with its sibling deliberately:
+ * the reason code is what `respond` and `/prompt-response` branch on, and both
+ * cases are the same promise to the caller — the answer could not be mapped onto
+ * a choice and NOTHING was sent.
+ */
+class FreeTextAtChoiceOnlyPromptError extends Error {
+    /** Machine-readable code, always {@link FREE_TEXT_AT_MENU_ROW_REASON}. */
+    reason;
+    /** How many options the screen offers, none of which is a text field. */
+    optionCount;
+    constructor(cliToolId, optionCount) {
+        super(`Refused to type free text at ${cliToolId}'s prompt: none of its ${optionCount} options is a `
+            + 'text field on this screen, so the text would be ignored and the Enter after it would '
+            + 'confirm whatever is highlighted. Nothing was sent. Answer with the option number instead, '
+            + 'then send your instructions as a separate message.');
+        this.name = 'FreeTextAtChoiceOnlyPromptError';
+        this.reason = exports.FREE_TEXT_AT_MENU_ROW_REASON;
+        this.optionCount = optionCount;
+    }
+}
+exports.FreeTextAtChoiceOnlyPromptError = FreeTextAtChoiceOnlyPromptError;
 /**
  * The pane to judge the tool's own dialog rules against.
  *
@@ -127,52 +252,68 @@ async function readGuardFrame(params) {
  * - It never fires for a tool with no measured dialog rules
  *   (`hasDialogRules === false`: gemini, antigravity, vibe-local). Gating on
  *   rules that do not exist would silence those tools, which is the rollout
- *   mistake `auto-yes-dialog-gate` documents.
+ *   mistake `auto-yes-dialog-gate` documents. command-code has had rules since
+ *   Issue #2574 (before it, it belonged in this list and was missing from it);
+ *   they only ever answer `numbered`, so on that tool this guard never refuses
+ *   and its reading is used for the Enter instead (see {@link resolveSubmitMode}).
  * - It does not MAP the answer onto the dialog's buttons. Turning "3" into the
  *   two ←/→ presses that reach `Reject` is Issue P1-7's structured-decision
  *   work; this Issue only stops the wrong keystroke.
  *
+ * @returns The `numbered` dialog the tool vouched for on this frame, or null when
+ *   the guard did not read one (non-numeric answer, no rules, unreadable pane,
+ *   or no dialog on screen). Returned so the Enter decision is made off the
+ *   same reading rather than a second capture (Issue #2574).
  * @throws {PromptAnswerRejectedError} when the tool vouched for a dialog on this
  *   frame whose `answerMode` is not {@link TEXT_ANSWERABLE_ANSWER_MODE}.
  */
 async function assertAnswerModeAcceptsNumber(params) {
     if (!/^\d+$/.test(params.answer))
-        return;
+        return null;
     const detector = (0, registry_1.getToolStatusDetector)(params.cliToolId);
     if (!detector.hasDialogRules)
-        return;
+        return null;
     const frame = await readGuardFrame(params);
     if (frame === null)
-        return;
+        return null;
     const dialog = detector.detectDialog((0, frame_1.normalizeFrame)(frame));
     if (dialog === null)
-        return;
+        return null;
     if (dialog.answerMode === TEXT_ANSWERABLE_ANSWER_MODE)
-        return;
+        return dialog;
     throw new PromptAnswerRejectedError(params.cliToolId, params.answer, dialog);
 }
 /**
- * Resolve the effective SubmitMode from promptData, fallback, and default.
- * Resolution order: promptData.submitMode -> fallbackSubmitMode -> 'answer_then_enter'.
+ * Resolve the effective SubmitMode from the dialog on screen, promptData, fallback, and default.
+ * Resolution order: dialog.submitMode -> promptData.submitMode -> fallbackSubmitMode -> 'answer_then_enter'.
  * Invalid values are normalized to 'answer_then_enter' via allowlist validation.
  *
+ * Issue #2574: the dialog comes first because it is the tool's own measurement,
+ * read off the frame the answer is about to land on. `promptData` may have been
+ * built by the generic parser, which cannot see that a digit is a hotkey —
+ * Command Code's permission dialog was published with no `submitMode`, and the
+ * Enter sent after its `1` submitted whatever draft was waiting in the composer.
+ *
  * @returns The resolved SubmitMode, guaranteed to be a valid value.
  */
-function resolveSubmitMode(params) {
+function resolveSubmitMode(params, dialog) {
     const fromPromptData = params.promptData?.type === 'multiple_choice'
         ? params.promptData.submitMode
         : undefined;
-    const raw = fromPromptData ?? params.fallbackSubmitMode ?? 'answer_then_enter';
+    const raw = dialog?.submitMode ?? fromPromptData ?? params.fallbackSubmitMode ?? 'answer_then_enter';
     return (0, models_1.isValidSubmitMode)(raw) ? raw : 'answer_then_enter';
 }
 /**
  * Determine whether the Enter key should be suppressed after sending the answer text.
  * answer_only mode applies only when the prompt is multiple_choice and the answer is numeric.
+ * A numbered dialog the tool vouched for is a multiple-choice prompt in its own right,
+ * which covers a caller that could not supply promptData (Issue #2574).
  */
-function shouldSuppressEnter(params, submitMode) {
+function shouldSuppressEnter(params, submitMode, dialog) {
     if (submitMode !== 'answer_only')
         return false;
-    const isMultipleChoice = params.promptData?.type === 'multiple_choice'
+    const isMultipleChoice = dialog !== null
+        || params.promptData?.type === 'multiple_choice'
         || params.fallbackPromptType === 'multiple_choice';
     return isMultipleChoice && /^\d+$/.test(params.answer);
 }
@@ -186,6 +327,177 @@ function buildNavigationKeys(offset) {
     const direction = offset > 0 ? 'Down' : 'Up';
     return Array.from({ length: Math.abs(offset) }, () => direction);
 }
+/**
+ * Refuse free text aimed at a menu row (Issue #2573).
+ *
+ * ## The hole
+ *
+ * `PromptPanel` / `MobilePromptSheet` sent the operator's TEXT instead of the
+ * option number whenever the selected option had `requiresTextInput`, and
+ * `respond <id> "<text>"` sends text by construction. Nothing below maps text
+ * onto a choice — the cursor arm takes digits only — so the text arm typed it at
+ * the dialog and pressed Enter. On Command Code 1.53.1's permission dialog
+ * (`3. No, tell Command Code what to do differently`) the characters are ignored
+ * and the Enter confirms the highlighted `1. Yes`: measured, a reason meaning
+ * "do not do this" ran the `mkdir` it was sent to stop, and `/prompt-response`
+ * answered `success: true`.
+ *
+ * ## Why it is keyed on the rows and not on "is the answer a number"
+ *
+ * Free text is the RIGHT answer on the screen next door. Command Code's
+ * `AskUserQuestion` ends in `Type something...`, a real `TextInput` (#2522), and
+ * both rows carry `requiresTextInput`. So the question is whether the prompt's
+ * text-bearing options include one measured to be a field
+ * ({@link isTypedTextFieldOption}); only when every one of them is a menu row is
+ * the text refused.
+ *
+ * ## Issue #2583: a screen with no text-bearing row is judged too
+ *
+ * The bullet that used to sit here said this guard does not judge a prompt with
+ * NO `requiresTextInput` option, citing #1726's pin — "sessions the rows cannot
+ * speak for keep behaving as they did". It named the hole it was leaving open in
+ * as many words (`the same Enter still sits under free text sent at, e.g.,
+ * claude's 1. Yes / 2. … / 3. No`), and #2583 then measured it: on claude 2.1.273
+ * and agy 1.2.3 a refusal typed at a Bash-approval dialog answered
+ * `success: true` and RAN the command. Whether it was refused came down to
+ * whether the quoted path happened to contain the word `custom`, which is
+ * `/custom/i` in `TEXT_INPUT_PATTERNS` — the spelling of someone else's argument.
+ *
+ * So the rule is now the one the guard's name always claimed: free text needs a
+ * text field, and a `multiple_choice` prompt whose rows are all choices has none.
+ *
+ * **What this costs, and why it is still the right trade.** #1726's pin is about
+ * AUTHORITY: that Issue reads the agent's own `AskUserQuestion` payload and must
+ * not let its absence narrow what a hook-less session accepts, because there the
+ * screen is the only authority. The rows judged here ARE the screen — the fresh
+ * capture `/prompt-response` re-verified, parsed by the same reader that draws
+ * the answer panels — so nothing is being second-guessed from a payload that is
+ * missing. What #1726 keeps is its actual subject: an out-of-RANGE number is
+ * still sent when no payload vouches for the list (this guard reads only
+ * non-numeric answers), and a call with no `promptData` at all still goes
+ * through untouched. The one case that regresses is an operator who has walked
+ * the cursor onto a row that opens a field the rows do not advertise — claude's
+ * `4. Type something.`, which no pattern flags — and sends text for it; they now
+ * get a refusal with the dialog still up instead of a silent approval. That
+ * direction is the safe one, and cursor position is #2584's subject, not this
+ * one's.
+ *
+ * ## What it deliberately does NOT do
+ *
+ * - It does not judge a call with no `promptData`, nor a `multiple_choice` with
+ *   an empty option list. Both mean the rows are unknown, which is exactly where
+ *   #1726's pin still holds — and where `/prompt-response` has already refused
+ *   for its own reasons if the pane could be read at all.
+ * - It does not deliver the reason. Sending the number and then the text as a
+ *   message is the follow-up (#2573 対応内容 2). Issue #2574 has since removed the
+ *   Enter that would have landed the reason in the wrong place on command-code,
+ *   so what is still missing is a measurement, per tool, of where the input goes
+ *   once the digit has confirmed.
+ *
+ * @throws {FreeTextAtChoiceOnlyPromptError} when the answer is not a number and
+ *   no option of the multiple-choice prompt even reads as taking text (#2583).
+ * @throws {FreeTextAnswerRejectedError} when the answer is not a number and every
+ *   text-bearing option of the multiple-choice prompt is a menu row (#2573).
+ */
+function assertFreeTextHasATextField(params) {
+    if (/^\d+$/.test(params.answer))
+        return;
+    const { promptData } = params;
+    if (promptData?.type !== 'multiple_choice')
+        return;
+    // No rows to read is not the same as rows that take no text: a prompt this
+    // degraded says nothing about where characters land, so it keeps the
+    // pre-#2583 path (see the pin discussion above).
+    if (promptData.options.length === 0)
+        return;
+    const textBearing = promptData.options.filter((option) => option.requiresTextInput === true);
+    // Issue #2583. Deliberately BEFORE the `isTypedTextFieldOption` reading below
+    // and never inside it: that reading decides between a field and a menu row on
+    // a screen that has at least one candidate, and this branch is the screen that
+    // has none.
+    if (textBearing.length === 0) {
+        throw new FreeTextAtChoiceOnlyPromptError(params.cliToolId, promptData.options.length);
+    }
+    if (textBearing.some(prompt_detect_multiple_choice_1.isTypedTextFieldOption))
+        return;
+    throw new FreeTextAnswerRejectedError(params.cliToolId, textBearing.map((option) => option.number));
+}
+/**
+ * Refuse free text while the cursor is on another row (Issue #2584).
+ *
+ * ## The hole #2573 left open
+ *
+ * {@link assertFreeTextHasATextField} asks what KIND the text-bearing rows are,
+ * and lets the text through the moment one of them is a measured field. On
+ * Command Code's `AskUserQuestion` that is one question short, because the field
+ * is a row of a list and typed characters only reach it while the cursor is
+ * resting there. Measured on 1.53.1 (#2584), with `Type something...` on row 3
+ * and the `❯` on row 1:
+ *
+ * ```
+ * ❯ 1. apple
+ *   2. banana
+ *   3. Type something...
+ * ```
+ *
+ * `answer: "UAT-FREETEXT-KIWI"` was ignored, the Enter after it confirmed
+ * `apple`, and `/prompt-response` answered `success: true` — the same failure
+ * shape as #2573, reached through the screen #2573 deliberately exempts. The
+ * SAME request on the SAME screen with the `❯` on row 3 records the text, so
+ * nothing but the cursor decides which of the two it means.
+ *
+ * ## Why it refuses instead of moving the cursor there first
+ *
+ * The obvious alternative is to reuse the cursor arm: compute `field - cursor`
+ * and send that many Down presses before typing. The arithmetic is available —
+ * both numbers are read off the frame — but the KEYS are not measured for this
+ * screen. The cursor arm is claude's and agy's by construction
+ * (`isCursorNavMultiChoice`, and `tools/command-code/dialog.ts` says so where it
+ * publishes this prompt), and what IS measured for Command Code is the opposite
+ * input method: the digit is a hotkey that selects on its own, which is why the
+ * screen is published `answer_only` (#2574). #2522 measured the remaining half —
+ * the digit aimed at the field row selects nothing — so this repository has no
+ * measured keystroke that moves this cursor at all.
+ *
+ * Sending Down at it anyway would, if the list does not take arrow keys,
+ * reproduce exactly today's bug with extra keystrokes in front of it and still
+ * answer `success: true`. That is the mistake `assertAnswerModeAcceptsNumber`
+ * was written against: gate on the measurement, and stop the wrong keystroke
+ * rather than invent a mapping. Mapping the answer onto the field — teaching the
+ * sender to arm this cursor once the movement key has been measured live — is
+ * the follow-up, and it can be added under this guard without changing what any
+ * caller sees today.
+ *
+ * ## What it deliberately does NOT do
+ *
+ * - It does not fire on a prompt with no measured field: that is #2573's case
+ *   above (every text-bearing row is a menu row) or the pre-#2573 pass-through
+ *   (#1726), and neither changes here.
+ * - It does not fire when NO option carries the cursor. agy's picker publishes
+ *   its highlight without `isDefault` at all (`#999`), and a screen whose cursor
+ *   cannot be read is one this guard has nothing to say about — the same
+ *   fail-open {@link readGuardFrame} takes for an unreadable pane.
+ *
+ * @throws {FreeTextAnswerRejectedError} with `kind: 'cursor_elsewhere'` when the
+ *   answer is not a number, the prompt has a measured text field, and the cursor
+ *   is resting on some other option.
+ */
+function assertFreeTextCursorIsOnTheField(params) {
+    if (/^\d+$/.test(params.answer))
+        return;
+    const { promptData } = params;
+    if (promptData?.type !== 'multiple_choice')
+        return;
+    const fields = promptData.options.filter(prompt_detect_multiple_choice_1.isTypedTextFieldOption);
+    if (fields.length === 0)
+        return;
+    const cursor = promptData.options.find((option) => option.isDefault === true);
+    if (cursor === undefined)
+        return;
+    if ((0, prompt_detect_multiple_choice_1.isTypedTextFieldOption)(cursor))
+        return;
+    throw new FreeTextAnswerRejectedError(params.cliToolId, fields.map((option) => option.number), { kind: 'cursor_elsewhere', cursorOptionNumber: cursor.number });
+}
 /**
  * Send an answer to a tmux session, using cursor-key navigation for
  * Claude Code / Antigravity multiple-choice prompts and text input for
@@ -202,7 +514,18 @@ async function sendPromptAnswer(params) {
     // inside the text arm because the number->offset arithmetic the cursor arm
     // does is just as meaningless on an unnumbered button strip as typing the
     // digit is.
-    await assertAnswerModeAcceptsNumber(params);
+    const dialog = await assertAnswerModeAcceptsNumber(params);
+    // Issue #2573 / #2583: the same promise for text. The text arm below types
+    // whatever it is given and presses Enter, so text aimed at a screen that has
+    // no text field on it — a menu row that reads as one, or a permission dialog
+    // whose rows are all choices — has to stop here, before the branch, or the
+    // Enter confirms the highlighted default.
+    assertFreeTextHasATextField(params);
+    // Issue #2584: and the half #2573 left open. A prompt that HAS a real text
+    // field still swallows the characters while the cursor is on another row, and
+    // the Enter after them confirms that row — so the cursor has to be checked
+    // here too, before the branch.
+    assertFreeTextCursorIsOnTheField(params);
     // Determine if this is an arrow-key-navigated multiple-choice prompt.
     // Claude Code and Antigravity (agy) both render selection menus that only
     // respond to cursor navigation + Enter, not to typed option numbers
@@ -276,8 +599,8 @@ async function sendPromptAnswer(params) {
         // Standard CLI prompt: send text + Enter (y/n, Approve?, etc.)
         await (0, tmux_1.sendKeys)(sessionName, answer, false);
         // Issue #616: Resolve submitMode and determine whether to suppress Enter
-        const resolvedSubmitMode = resolveSubmitMode(params);
-        if (!shouldSuppressEnter(params, resolvedSubmitMode)) {
+        const resolvedSubmitMode = resolveSubmitMode(params, dialog);
+        if (!shouldSuppressEnter(params, resolvedSubmitMode, dialog)) {
             // Wait a moment for the input to be processed
             await new Promise(resolve => setTimeout(resolve, cli_tool_timing_config_1.TUI_TEXT_INPUT_WAIT_MS));
             // Send Enter