commandmate 0.33.3 → 0.34.0

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

@@ -54,9 +54,11 @@
  * @module lib/polling/auto-yes-dialog-gate
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.AUTO_YES_DIALOG_GATE_ENV_VAR = exports.AUTO_YES_DIALOG_GATE_DEFAULT_MODE = exports.AUTO_YES_DIALOG_GATE_MODES = void 0;
+exports.UNSUPPORTED_DIALOG_LAYOUT_REASON = exports.PROMPT_NO_LONGER_ACTIVE_REASON = exports.AUTO_YES_DIALOG_GATE_ENV_VAR = exports.AUTO_YES_DIALOG_GATE_DEFAULT_MODE = exports.AUTO_YES_DIALOG_GATE_MODES = void 0;
 exports.resolveAutoYesDialogGateMode = resolveAutoYesDialogGateMode;
 exports.evaluateAutoYesDialogGate = evaluateAutoYesDialogGate;
+exports.evaluateDialogPresence = evaluateDialogPresence;
+exports.judgePromptResponse = judgePromptResponse;
 const frame_1 = require("../../lib/detection/tools/frame");
 const registry_1 = require("../../lib/detection/tools/registry");
 /** Every accepted value of {@link AutoYesDialogGateMode}, for parsing and tests. */
@@ -168,23 +170,124 @@ const GATED_PROMPT_TYPE = 'multiple_choice';
  * @param env - Environment to read the kill switch from; injectable for tests
  */
 function evaluateAutoYesDialogGate(cliToolId, promptType, cleanOutput, env = process.env) {
-    const detector = (0, registry_1.getToolStatusDetector)(cliToolId);
-    const mode = resolveAutoYesDialogGateMode(cliToolId, env);
     // A tool nobody has measured is not gated whatever the table says. Belt and
     // braces on purpose: the failure mode of getting this wrong is Auto-Yes going
     // permanently silent for that tool, which looks exactly like a hung worker.
-    if (promptType !== GATED_PROMPT_TYPE || !detector.hasDialogRules || mode === 'legacy') {
-        return { allowed: true, dialog: null, mode, gated: false };
-    }
-    const dialog = detector.detectDialog((0, frame_1.normalizeFrame)(cleanOutput));
+    // `judgeDialogPresence` holds that rule; Issue #2457 split it out so the
+    // history-save and `/prompt-response` paths judge a frame the same way this
+    // one does instead of re-deriving the rollout table.
+    const presence = judgeDialogPresence(cliToolId, promptType, cleanOutput, resolveAutoYesDialogGateMode(cliToolId, env));
     return {
         // `keys` is a dialog and still not answerable: opencode's button strip takes
         // ←/→ + Enter, so the digit is swallowed and the Enter confirms whatever is
         // highlighted — asking to Reject would Approve (#1893). Sending nothing is
         // the only safe answer, and `wait` still stops for the frame.
-        allowed: dialog !== null && dialog.answerMode === 'numbered',
-        dialog,
-        mode,
-        gated: true,
+        //
+        // Issue #2457: this extra test is what makes `allowed` unusable as an
+        // "is there a dialog here?" answer, and why the save path reads
+        // {@link evaluateDialogPresence} instead.
+        allowed: presence.gated
+            ? presence.dialog !== null && presence.dialog.answerMode === 'numbered'
+            : true,
+        dialog: presence.dialog,
+        mode: presence.mode,
+        gated: presence.gated,
     };
 }
+/** The one reading of a frame both gates share. `mode` is resolved by the caller. */
+function judgeDialogPresence(cliToolId, promptType, frame, mode) {
+    const detector = (0, registry_1.getToolStatusDetector)(cliToolId);
+    if (promptType !== GATED_PROMPT_TYPE || !detector.hasDialogRules || mode === 'legacy') {
+        return { present: true, dialog: null, mode, gated: false };
+    }
+    const dialog = detector.detectDialog((0, frame_1.normalizeFrame)(frame));
+    return { present: dialog !== null, dialog, mode, gated: true };
+}
+/**
+ * Does this frame POSITIVELY carry a dialog for the numbered-list candidate the
+ * generic parser found on it? (Issue #2457)
+ *
+ * The same rollout table, the same `hasDialogRules` cross-check and the same
+ * `detectDialog` seam Auto-Yes reads — and deliberately NOT the same env var.
+ * `CM_AUTOYES_DIALOG_GATE` is the kill switch for *answering* prompts without a
+ * human: an operator who sets it because their unattended pipeline stopped
+ * replying is saying nothing at all about which rows belong in History, and
+ * letting that flag also decide what gets stored would make the chat surface's
+ * contents depend on an Auto-Yes setting. So this reads
+ * {@link AUTO_YES_DIALOG_GATE_DEFAULT_MODE} directly.
+ *
+ * Auto-Yes being enabled or disabled is likewise not a condition here: the false
+ * `1. / 2. / 3.` row #2457 reported was saved by the response poller, which runs
+ * for every session whether or not anything is auto-answering it.
+ *
+ * @param cliToolId - CLI tool the frame came from
+ * @param promptType - How the generic parser classified the frame; anything but
+ *   `multiple_choice` is left alone (see the module docstring on `yes_no`)
+ * @param frame - The WHOLE capture the candidate was read off, **as captured**.
+ *   Never the extracted response, the question alone or a tail window: the rules
+ *   `detectDialog` applies are about where the block sits in the pane, so a
+ *   fragment answers a different question from the one being asked.
+ *
+ *   And never a `stripBoxDrawing`-ed string, which is the one place this differs
+ *   from {@link evaluateAutoYesDialogGate}. That function is handed the spelling
+ *   Auto-Yes already had in hand (`captureAndCleanOutput`); this one is handed
+ *   the capture, because that is the spelling on which ALL FOUR gated tools have
+ *   working rules. opencode is the proof and it is already documented in
+ *   `tests/unit/detection/tools/dialogs.test.ts`: its permission strip is
+ *   anchored on the input box's own gutter (#1893's anchor, which must not be
+ *   weakened), so with the box drawing removed its live dialog reads as `null`.
+ *   For Auto-Yes `null` and `keys` both mean "send nothing" and the difference
+ *   is invisible; here `null` would mean "there is no prompt on this screen",
+ *   which about an open approval is simply false. `normalizeFrame` runs
+ *   `stripAnsi` itself and each tool's rule applies `stripBoxDrawing` where it
+ *   needs it, so nothing is lost by handing over the capture — and
+ *   `stripBoxDrawing` never runs twice over the same row.
+ */
+function evaluateDialogPresence(cliToolId, promptType, frame) {
+    return judgeDialogPresence(cliToolId, promptType, frame, exports.AUTO_YES_DIALOG_GATE_DEFAULT_MODE[cliToolId] ?? 'legacy');
+}
+/** `/prompt-response`'s refusal when the prompt it was asked to answer is gone. */
+exports.PROMPT_NO_LONGER_ACTIVE_REASON = 'prompt_no_longer_active';
+/**
+ * `/prompt-response`'s refusal when an AskUserQuestion picker IS on screen but
+ * the tool's own dialog rule could not vouch for it (Issue #2486).
+ */
+exports.UNSUPPORTED_DIALOG_LAYOUT_REASON = 'unsupported_dialog_layout';
+/**
+ * Fixed text, never quoting the answer (SEC-003, as in `prompt-answer-semantic`),
+ * so it is safe to return to a client verbatim.
+ */
+const UNSUPPORTED_DIALOG_LAYOUT_MESSAGE = 'An AskUserQuestion picker is on screen, but its layout could not be verified as one of the ' +
+    "agent's dialogs, so no key was sent. Answer it in the terminal, or retry once the screen has settled.";
+/**
+ * May `/prompt-response` answer this frame? Null when it may; otherwise why not
+ * (Issue #2486).
+ *
+ * The route has refused whenever the generic parser found no prompt OR the gate
+ * could not vouch for the one it found (#161, #2457), and it called both
+ * `prompt_no_longer_active`. For the second half that was sometimes false: in
+ * #2486 an AskUserQuestion picker with a preview pane was open on screen, `wait`
+ * had just exited 10 for it, and `respond` said the prompt was gone. The two
+ * cases need different next steps — retry versus answer at the pane — so they
+ * get different reasons.
+ *
+ * The evidence for "a picker IS on screen" is the picker's own footer
+ * (`Enter to select · … navigate`, which sets `isAskUserQuestion`), not the
+ * parser's candidate alone: #2457's reply frames are candidates too, and for
+ * them `prompt_no_longer_active` stays the answer.
+ *
+ * @param promptCheck - What the generic parser (or agy's reader) found on the frame
+ * @param presence - {@link evaluateDialogPresence} for the same frame
+ */
+function judgePromptResponse(promptCheck, presence) {
+    if (promptCheck.isPrompt && presence.present)
+        return null;
+    const promptData = promptCheck.promptData;
+    if (promptCheck.isPrompt &&
+        presence.gated &&
+        promptData?.type === 'multiple_choice' &&
+        promptData.isAskUserQuestion === true) {
+        return { reason: exports.UNSUPPORTED_DIALOG_LAYOUT_REASON, message: UNSUPPORTED_DIALOG_LAYOUT_MESSAGE };
+    }
+    return { reason: exports.PROMPT_NO_LONGER_ACTIVE_REASON };
+}

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

@@ -5,6 +5,7 @@ exports.PENDING_SCRAPE_HOLD_MS = void 0;
 exports.incompleteResult = incompleteResult;
 exports.buildPromptExtractionResult = buildPromptExtractionResult;
 exports.detectPromptOnCleanFrame = detectPromptOnCleanFrame;
+exports.isNumberedDialogVouched = isNumberedDialogVouched;
 exports.detectPromptWithOptions = detectPromptWithOptions;
 exports.extractResponse = extractResponse;
 exports.resetPendingScrapedResponses = resetPendingScrapedResponses;
@@ -31,6 +32,10 @@ const response_cleaner_1 = require("../response-cleaner");
 const copilot_constants_1 = require("../../config/copilot-constants");
 const tui_accumulator_1 = require("../tui-accumulator");
 const prompt_dedup_1 = require("./prompt-dedup");
+// Issue #2457: the same rollout table, `hasDialogRules` cross-check and
+// `detectDialog` seam Auto-Yes reads, reached through the presence helper rather
+// than through `evaluateAutoYesDialogGate` — see `isNumberedDialogVouched`.
+const auto_yes_dialog_gate_1 = require("./auto-yes-dialog-gate");
 const prompt_dedup_state_1 = require("./prompt-dedup-state");
 const response_dedup_1 = require("./response-dedup");
 const structured_history_gate_1 = require("./structured-history-gate");
@@ -230,6 +235,55 @@ function detectPromptOnCleanFrame(cleanOutput, cliToolId, precomputedLines) {
     const promptOptions = (0, cli_patterns_1.buildDetectPromptOptions)(cliToolId);
     return (0, prompt_detector_1.detectPrompt)(cleanOutput, precomputedLines ? { ...promptOptions, precomputedLines } : promptOptions);
 }
+/**
+ * Is the generic parser's numbered-list candidate a dialog the tool vouches for?
+ * (Issue #2457)
+ *
+ * ## The candidate this removes
+ *
+ * `detectPrompt` classifies a frame as `multiple_choice` from the ROWS alone,
+ * and for Claude `buildDetectPromptOptions` returns
+ * `requireDefaultIndicator: false` — so a reply that happens to answer in
+ * Markdown ("1. …  2. …  3. …") is a candidate with no `❯` anywhere near it.
+ * Every one of those was stored as a `prompt` message, and the chat surface drew
+ * a tool-approval chip over an ordinary answer.
+ *
+ * ## Why the whole frame, and only the frame
+ *
+ * `detectDialog` decides by POSITION and CHROME — where the option block sits
+ * relative to the transcript tail, what (if anything) is drawn under it. None of
+ * that survives being handed the extracted response, the question string or a
+ * tail window, so the caller passes the same capture the candidate came off, as
+ * captured: `evaluateDialogPresence` documents why the box drawing must still be
+ * on it.
+ *
+ * ## What a `false` means downstream
+ *
+ * Not "there is no output here" — only "this is not a prompt". The caller falls
+ * through to the ordinary completion/partial reading, so a real reply is still
+ * saved by the normal path and a half-written one still reports
+ * `isComplete: false`.
+ *
+ * @param cliToolId - CLI tool the frame came from
+ * @param promptDetection - What the generic parser (or a tool reader) answered
+ * @param frame - The whole capture this tick made, as captured
+ * @returns True when the candidate may be treated as a live prompt
+ */
+function isNumberedDialogVouched(cliToolId, promptDetection, frame) {
+    const presence = (0, auto_yes_dialog_gate_1.evaluateDialogPresence)(cliToolId, promptDetection.promptData?.type, frame);
+    if (presence.present)
+        return true;
+    // `debug`, not `info`: the poller re-reads a static idle pane every 2s, so a
+    // reply carrying a numbered list would print this on every tick for as long as
+    // it stays on screen. The suppression is not silent where it matters — nothing
+    // is stored, so History simply shows the reply the ordinary path saves.
+    logger.debug('prompt-candidate-not-vouched', {
+        cliToolId,
+        promptType: promptDetection.promptData?.type,
+        gateMode: presence.mode,
+    });
+    return false;
+}
 /**
  * Internal helper: detect prompt with CLI-tool-specific options.
  *
@@ -432,7 +486,13 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
         cliToolId === 'command-code') {
         const fullOutput = lines.join('\n');
         const promptDetection = detectPromptWithOptions(fullOutput, cliToolId);
-        if (promptDetection.isPrompt) {
+        // Issue #2457: a candidate the tool's own rules cannot vouch for is not a
+        // prompt, and returning here would declare the turn finished ON IT — the
+        // early-completion half of the defect. Falling through leaves the ordinary
+        // completion/partial reading to answer, which is what a reply containing a
+        // numbered list needs. The gate is handed `fullOutput`, the capture itself,
+        // not the string `detectPromptWithOptions` cleaned for the parser.
+        if (promptDetection.isPrompt && isNumberedDialogVouched(cliToolId, promptDetection, fullOutput)) {
             return buildPromptExtractionResult(lines, lastCapturedLine, totalLines, bufferReset, cliToolId, findRecentUserPromptIndex, promptDetection, captureWindowSaturated);
         }
     }
@@ -700,8 +760,11 @@ function extractResponse(output, lastCapturedLine, cliToolId, captureWindowLines
     // Check if this is an interactive prompt
     if (cliToolId !== 'opencode') {
         const fullOutput = lines.join('\n');
+        // Issue #2457: same gate as the early check above — this is the site a frame
+        // reaches when the completion rules said "unfinished", so a candidate
+        // accepted here would end the turn on it just the same.
         const promptDetection = detectPromptWithOptions(fullOutput, cliToolId);
-        if (promptDetection.isPrompt) {
+        if (promptDetection.isPrompt && isNumberedDialogVouched(cliToolId, promptDetection, fullOutput)) {
             return buildPromptExtractionResult(lines, lastCapturedLine, totalLines, bufferReset, cliToolId, findRecentUserPromptIndex, promptDetection, captureWindowSaturated);
         }
     }
@@ -1067,7 +1130,23 @@ async function checkForResponse(worktreeId, cliToolId, instanceId) {
         }
         // Response is complete! Check if it's a prompt.
         const promptDetection = result.promptDetection ?? detectPromptWithOptions(result.response, cliToolId);
-        if (promptDetection.isPrompt) {
+        // Issue #2457: the gate is applied HERE as well as in `extractResponse`, and
+        // to a carried `result.promptDetection` as well as to one derived on this
+        // line. Two independent reasons, either one sufficient:
+        //
+        //  1. the fallback above reads `result.response` — the EXTRACTED text, with
+        //     the pane's chrome already cut off — so a reply's `1. / 2. / 3.` rows
+        //     look even more like a dialog here than they did upstream, and a tool
+        //     the early check never runs for (opencode) reaches the save path only
+        //     through this line;
+        //  2. `promptDetection` carried from `extractResponse` is the one thing that
+        //     could walk a candidate past the gate unexamined, and this is the last
+        //     position before the row is written.
+        //
+        // The frame is the capture this tick made — never `result.response`, which
+        // has lost the position `detectDialog` judges by.
+        const promptIsLive = promptDetection.isPrompt && isNumberedDialogVouched(cliToolId, promptDetection, output);
+        if (promptIsLive) {
             // Issue #565: Content hash-based duplicate prompt prevention
             const promptContent = promptDetection.rawContent || promptDetection.cleanContent;
             const normalizedForDedup = (0, prompt_dedup_1.normalizePromptForDedup)(promptContent, cliToolId);

package/dist/server/src/lib/schedule-manager.js

@@ -58,6 +58,37 @@ function isCronJobActive(cronJob) {
     }
     return true;
 }
+/**
+ * Attach the execution callback to a cron job.
+ *
+ * The callback closes over the {@link ScheduleState}, never over the entry the
+ * timer was built from (Issue #2456). Two things follow, and both are load
+ * bearing when a timer is replaced while its schedule keeps running:
+ *
+ * - the tick executes `state.entry`, so a Message/CLI Tool/Permission edit
+ *   picked up by a later sync is the one the next run uses;
+ * - the tick reads `state.isExecuting`, the single guard every timer this
+ *   schedule ever owns shares. `protect: true` cannot stand in for it: the
+ *   callback returns `undefined` rather than the execution's Promise, so croner
+ *   never sees itself as blocking, and a fresh timer with its own state would
+ *   start a second run on top of a live one.
+ *
+ * @param state - The schedule state the callback executes
+ * @param cronJob - The cron job to attach the callback to
+ */
+function scheduleExecution(state, cronJob) {
+    cronJob.schedule(() => {
+        // Issue #1343: executeSchedule() rejects if its own error handling fails
+        // (e.g. the DB is still down when writing the 'failed' log). Without this
+        // catch the rejection is silently unhandled.
+        void (0, job_executor_1.executeSchedule)(state).catch((error) => {
+            logger.error('execution:unhandled', {
+                name: state.entry.name,
+                error: error instanceof Error ? error.message : String(error),
+            });
+        });
+    });
+}
 function createScheduleState(worktreeId, scheduleId, entry) {
     const cronJob = new croner_1.Cron(entry.cronExpression, {
         paused: false,
@@ -70,18 +101,102 @@ function createScheduleState(worktreeId, scheduleId, entry) {
         isExecuting: false,
         entry,
     };
-    cronJob.schedule(() => {
-        // Issue #1343: executeSchedule() rejects if its own error handling fails
-        // (e.g. the DB is still down when writing the 'failed' log). Without this
-        // catch the rejection is silently unhandled.
-        void (0, job_executor_1.executeSchedule)(state).catch((error) => {
-            logger.error('execution:unhandled', {
-                name: entry.name,
-                error: error instanceof Error ? error.message : String(error),
-            });
+    scheduleExecution(state, cronJob);
+    return state;
+}
+/**
+ * Move a live schedule onto a new cron expression (Issue #2456).
+ *
+ * The bug this exists for: the sync loop used to answer a changed CMATE.md row
+ * with `existingState.entry = entry`, which updates every field the executor
+ * reads at run time but not the pattern `croner` compiled into the timer at
+ * construction. A Cron edit was therefore accepted by the parser, written to the
+ * DB, shown by the API — and ignored by the thing that actually fires, for as
+ * long as the server stayed up.
+ *
+ * ## Order of operations
+ *
+ * The replacement is built **paused** first, so the only step that can reject a
+ * pattern happens while the old timer is still the one and only live timer, and
+ * a rejected pattern leaves the schedule exactly as it was. Only then is the old
+ * timer stopped and the replacement resumed — in that order, so the two are
+ * never runnable at the same instant. `state.cronJob` and `state.entry` are
+ * published last, together, so a caller that reads the state never sees a timer
+ * and an entry that disagree.
+ *
+ * A pause costs nothing here: `resume()` follows synchronously, so no tick can
+ * pass while the replacement is paused and there is nothing to "catch up" on.
+ * The new expression's first run is its first occurrence after now, which is
+ * what a schedule edit should mean.
+ *
+ * ## Failure
+ *
+ * Failure keeps the old timer and the old entry, and says so — no
+ * `schedule:updated`. What it must never do is leave two live timers, so the
+ * candidate (which has never run) is the one discarded. If the failure was
+ * `stop()` on the old timer, that timer is left in whatever state it reached:
+ * either it stopped, and the next sync's inactive-state recovery rebuilds it
+ * from the newest entry, or it survived on its old expression. Both are
+ * recoverable, and the caller invalidates this worktree's mtime cache so the
+ * next sync retries even though CMATE.md has not been touched again.
+ *
+ * @param state - The live schedule state (kept, so its execution guard survives)
+ * @param entry - The entry carrying the new cron expression
+ * @returns true when the schedule now runs on `entry.cronExpression`
+ */
+function replaceCronExpression(state, entry) {
+    const previousCron = state.entry.cronExpression;
+    const failed = (phase, error) => {
+        logger.error('schedule:update-failed', {
+            scheduleId: state.scheduleId,
+            worktreeId: state.worktreeId,
+            previousCron,
+            cron: entry.cronExpression,
+            phase,
+            error: error instanceof Error ? error.message : String(error),
         });
+        return false;
+    };
+    let candidate = null;
+    try {
+        candidate = new croner_1.Cron(entry.cronExpression, { paused: true, protect: true });
+        scheduleExecution(state, candidate);
+    }
+    catch (error) {
+        if (candidate) {
+            try {
+                candidate.stop();
+            }
+            catch {
+                // The candidate never ran; nothing else to reclaim
+            }
+        }
+        return failed('prepare', error);
+    }
+    try {
+        state.cronJob.stop();
+        candidate.resume();
+    }
+    catch (error) {
+        try {
+            candidate.stop();
+        }
+        catch {
+            // The candidate never ran; nothing else to reclaim
+        }
+        return failed('swap', error);
+    }
+    state.cronJob = candidate;
+    state.entry = entry;
+    // Deliberately without the message: the prompt body is not an operational
+    // fact and execution_logs already holds it.
+    logger.info('schedule:updated', {
+        scheduleId: state.scheduleId,
+        worktreeId: state.worktreeId,
+        previousCron,
+        cron: entry.cronExpression,
     });
-    return state;
+    return true;
 }
 /**
  * Get or initialize the global manager state.
@@ -124,6 +239,9 @@ function getLazyDbInstance() {
  * Issue #406: Async I/O for readCmateFile() to avoid event loop blocking.
  * Issue #409: Uses mtime caching to skip unchanged CMATE.md files
  * and batchUpsertSchedules() for efficient DB operations.
+ * Issue #2456: A changed Cron column swaps the timer (replaceCronExpression);
+ * everything else about an existing schedule is an entry update that leaves the
+ * timer alone.
  *
  * DJ-007: isSyncing guard prevents concurrent execution when async
  * operations exceed the 60-second polling interval.
@@ -188,10 +306,6 @@ async function syncSchedules() {
                 for (let i = 0; i < entries.length; i++) {
                     const entry = entries[i];
                     const scheduleId = scheduleIds[i];
-                    if (manager.schedules.size >= exports.MAX_CONCURRENT_SCHEDULES) {
-                        logger.warn('schedule:max-concurrent-reached', { limit: exports.MAX_CONCURRENT_SCHEDULES });
-                        return;
-                    }
                     activeScheduleIds.add(scheduleId);
                     // Skip disabled or incomplete entries
                     if (!entry.enabled || !entry.cronExpression) {
@@ -214,16 +328,61 @@ async function syncSchedules() {
                             catch {
                                 // Ignore cleanup errors for inactive cron jobs
                             }
-                            const recoveredState = createScheduleState(worktree.id, scheduleId, entry);
-                            manager.schedules.set(scheduleId, recoveredState);
-                            logger.warn('schedule:recreated-inactive', { name: entry.name, cron: entry.cronExpression });
+                            // Issue #2456: recover onto the newest entry, and keep the same
+                            // ScheduleState so a still-running execution's guard survives the
+                            // exchange rather than being reset by a fresh object.
+                            try {
+                                const recovered = new croner_1.Cron(entry.cronExpression, { paused: false, protect: true });
+                                scheduleExecution(existingState, recovered);
+                                existingState.cronJob = recovered;
+                                existingState.entry = entry;
+                                logger.warn('schedule:recreated-inactive', { name: entry.name, cron: entry.cronExpression });
+                            }
+                            catch (recoverError) {
+                                manager.cmateFileCache.delete(worktree.path);
+                                logger.error('schedule:update-failed', {
+                                    scheduleId,
+                                    worktreeId: worktree.id,
+                                    previousCron: existingState.entry.cronExpression,
+                                    cron: entry.cronExpression,
+                                    phase: 'recover',
+                                    error: recoverError instanceof Error ? recoverError.message : String(recoverError),
+                                });
+                            }
+                            continue;
+                        }
+                        // Issue #2456: a changed Cron column has to reach the timer, not
+                        // just the entry the executor reads. String comparison on purpose —
+                        // the parser has already trimmed the cell, and two spellings of the
+                        // same schedule are a rewrite the operator asked for.
+                        if (existingState.entry.cronExpression !== entry.cronExpression) {
+                            if (!replaceCronExpression(existingState, entry)) {
+                                // The old timer and the old entry are still in force. Drop this
+                                // worktree's mtime cache so the next sync retries even though
+                                // CMATE.md itself has not changed again — without this the file
+                                // would have to be touched to get another attempt.
+                                manager.cmateFileCache.delete(worktree.path);
+                            }
                             continue;
                         }
-                        // Update entry if changed
+                        // Metadata-only change (Message / CLI Tool / Permission / model):
+                        // the timer stays, and the next tick reads this entry through the
+                        // shared state.
                         existingState.entry = entry;
                         continue;
                     }
-                    // Create new cron job
+                    // Create new cron job. The cap belongs here and only here (Issue
+                    // #2456): it bounds how many timers exist, so refusing a new one must
+                    // not also refuse to update, disable or clean up the ones already
+                    // running — nor abandon the rest of the sync, which is what the
+                    // previous `return` did.
+                    if (manager.schedules.size >= exports.MAX_CONCURRENT_SCHEDULES) {
+                        logger.warn('schedule:max-concurrent-reached', {
+                            limit: exports.MAX_CONCURRENT_SCHEDULES,
+                            name: entry.name,
+                        });
+                        continue;
+                    }
                     try {
                         const state = createScheduleState(worktree.id, scheduleId, entry);
                         manager.schedules.set(scheduleId, state);

package/dist/server/src/lib/session/ask-user-question-prompt.js

@@ -100,9 +100,11 @@ function corresponds(a, b) {
  * Containment rather than the prefix rule the labels use, because the two are
  * extracted differently. An option label is a parsed line; the question is
  * whatever the detector's upward scan swept together, and on a real capture that
- * is several lines glued into one — the canary frame yields
+ * was several lines glued into one — before Issue #2486 the canary frame yielded
  * `"⏺ I'll load the TaskCreate tool schema first. ☐ First task Which task would
- * you like to start with?"` for a question that is only its last clause.
+ * you like to start with?"` for a question that is only its last clause. The
+ * picker's tab row now caps that scan, but the scan still reads at most a few
+ * rows, so a long question arrives cut and containment is still the right test.
  *
  * The floor stops a short question ("Continue?") from matching unrelated prose;
  * the uniqueness requirement in {@link matchAskUserQuestion} does the rest. On

package/dist/server/src/lib/session/claude-executor.js

@@ -106,7 +106,7 @@ function truncateOutput(output) {
  * - vibe-local: [-p <message> -y] or [--model <model> -p <message> -y]
  * - opencode: run --format json [-m <model>] [--agent <a>] [--variant <v>] [-c] [--title <t>] <message>
  * - antigravity: -p <message> --dangerously-skip-permissions
- * - command-code: -p <message> --output-format json [--yolo | --permission-mode <permission>]
+ * - command-code: -p <message> --output-format json [--yolo | --permission-mode <permission>] --no-auto-update
  * - others: -p <message> (fallback)
  *
  * @param message - Prompt message
@@ -201,13 +201,44 @@ function buildCliArgs(message, cliToolId, permission, options) {
             // `--yolo` does not override `.commandcode/settings.json`
             // `permissions.deny`; a denied tool call still ends the run with exit 4,
             // which {@link describeCommandCodeExit} names in the failure reason.
+            //
+            // ## Issue #2454: `yolo` is a Permission *column* value, and the default
+            //
+            // Every `--permission-mode` value leaves print mode read-only. The 1.53.0
+            // bundle injects a `print-permission-gate` mod whenever `--yolo` was not
+            // passed, and that mod answers `edit_file` / `write_file` /
+            // `shell_command` / `monitor_command` / `kill_shell` with `block: true`;
+            // the mode flag never reaches it. A blocked call does not fail the run —
+            // it ends exit 0 with `subtype: "success"` — so a schedule that asked for
+            // `default` looked successful and changed nothing.
+            //
+            // So the column now spells `--yolo` as the value `yolo`
+            // ({@link COMMAND_CODE_SCHEDULE_PERMISSIONS}, copilot's shape), and the
+            // parser fills an empty cell with it. The `else` below used to be the
+            // only way to reach `--yolo` and was unreachable from a schedule, because
+            // `DEFAULT_PERMISSIONS['command-code']` was `'default'`.
             const args = ['-p', message, '--output-format', 'json'];
-            if (schedule_config_1.COMMAND_CODE_PERMISSIONS.includes(permission)) {
+            if (permission === schedule_config_1.COMMAND_CODE_YOLO_PERMISSION) {
+                args.push('--yolo');
+            }
+            else if (schedule_config_1.COMMAND_CODE_PERMISSIONS.includes(permission)) {
                 args.push('--permission-mode', permission);
             }
             else {
+                // Not reachable through the parser (it falls back to `yolo`); this is
+                // the direct-call guard.
                 args.push('--yolo');
             }
+            // Issue #2454: without this, `resolveCliStartupPlan` runs an update check
+            // and a background self-update on every scheduled run. Spelled as a
+            // literal for the same reason `getCommandForTool` spells `commandcode` as
+            // one — importing `COMMAND_CODE_LAUNCH_FLAGS` from
+            // `@/lib/cli-tools/command-code` would pull the tmux transport into the
+            // scheduler's dependency graph. The unit test imports both and asserts
+            // the spelling matches, so the copy cannot drift. `--trust` /
+            // `--skip-onboarding` are *not* copied: print mode dispatches before the
+            // TUI's trust and onboarding gates, so they have nothing to answer.
+            args.push('--no-auto-update');
             return args;
         }
         case 'antigravity':