@adhdev/daemon-core 0.9.82-rc.351 → 0.9.82-rc.352

package/src/mesh/mesh-events-pending.ts

@@ -5,6 +5,7 @@ import { LOG } from '../logging/logger.js';
 import { getLedgerDir, readLedgerEntries, appendLedgerEntry } from './mesh-ledger.js';
 import { MeshRuntimeStore } from './mesh-runtime-store.js';
 import { buildMeshSystemMessage, readNonEmptyString, readRecord, resolveEventSessionId, readMeshCompletionSummary } from './mesh-events-utils.js';
+import { expandDaemonIdForms } from '@adhdev/mesh-shared';
 
 // ---------------------------------------------------------------------------
 // MCP coordinator pending-event queue — FILE-BASED PERSISTENCE
@@ -48,24 +49,22 @@ export interface PendingMeshCoordinatorEvent {
 const REFINE_TERMINAL_EVENTS = new Set(['refine:completed', 'refine:failed']);
 
 /** Normalise a coordinator-daemon-id argument (single id, list, or undefined) into a
- *  de-duplicated list of non-empty strings. The first entry is treated as primary for
- *  per-daemon JSONL file naming; all entries are accepted by drain/peek targeting. */
+ *  de-duplicated list of non-empty strings, EXPANDED to every equivalent daemon-id
+ *  form (bare `mach_X` ≡ `daemon_mach_X` ≡ `standalone_mach_X`).
+ *
+ *  A coordinator resolves its own id through one path (status instanceId, the config-
+ *  form node daemonId, or the bare machineId) but a worker stamps a completion's
+ *  `coordinator_daemon_id` through another, so the two are routinely in DIFFERENT
+ *  forms of the SAME machine. The scope filter is an exact-string match, so without
+ *  expansion a `daemon_mach_X`-scoped completion is silently skipped by a coordinator
+ *  that only knows itself as bare `mach_X` (the base-node completion-surface bug).
+ *  Expanding here fixes every drain/peek/surface caller uniformly. The first ORIGINAL
+ *  id stays at [0] so per-daemon JSONL file naming keeps its primary; expansion stays
+ *  within one machine core so a different coordinator's events are never claimed. */
 function normalizeCoordinatorDaemonIds(
     coordinatorDaemonId?: string | null | ReadonlyArray<string>,
 ): string[] {
-    const raw = Array.isArray(coordinatorDaemonId)
-        ? coordinatorDaemonId
-        : coordinatorDaemonId != null ? [coordinatorDaemonId] : [];
-    const seen = new Set<string>();
-    const out: string[] = [];
-    for (const id of raw) {
-        if (typeof id !== 'string') continue;
-        const trimmed = id.trim();
-        if (!trimmed || seen.has(trimmed)) continue;
-        seen.add(trimmed);
-        out.push(trimmed);
-    }
-    return out;
+    return expandDaemonIdForms(coordinatorDaemonId);
 }
 
 export function readRefineJobId(event: { metadataEvent?: Record<string, unknown> } | Record<string, unknown>): string {

package/src/mesh/mesh-ledger.ts

@@ -43,6 +43,7 @@ export type MeshLedgerKind =
     | 'delivery_unroutable'
     | 'direct_dispatch_pruned'
     | 'event_held'
+    | 'task_reclaimed'
     ;
 
 export interface MeshLedgerEntry {

package/src/mesh/mesh-reconcile-loop.ts

@@ -56,7 +56,8 @@ import {
     expireStaleUnresolvedDelegateForwards,
 } from './mesh-unresolved-forward-outbox.js';
 import { readNonEmptyString, readMeshCompletionSummary } from './mesh-events-utils.js';
-import { getActiveDirectDispatches, getQueue } from './mesh-work-queue.js';
+import { expandDaemonIdForms } from '@adhdev/mesh-shared';
+import { getActiveDirectDispatches, getQueue, reclaimStrandedAssignedTask } from './mesh-work-queue.js';
 import { readLedgerEntries } from './mesh-ledger.js';
 import { pruneStaleDirectDispatches } from './mesh-active-work.js';
 import { reconcileDirectDispatchCompletionFromTranscript } from './mesh-events-stale.js';
@@ -119,16 +120,19 @@ interface LiveCoordinator {
 //   - the daemon's canonical status id (`standalone_<machineId>` / `daemon_<machineId>`),
 //     stamped by the MCP layer via ctx.localDaemonId (= getStatus().status.instanceId), or
 //   - the bare machineId, stamped by the local queue-assignment path (loadConfig().machineId).
+//   - the config-form node daemonId (`daemon_<machineId>`), which the MCP layer's
+//     resolveCoordinatorDaemonId prefers and stamps onto direct-dispatch workers.
 // Draining with only one of these silently misses events stamped with the other —
-// the exact reason a generating coordinator never self-received local completions.
-// We accept BOTH so the drain matches regardless of which path stamped the event.
+// the exact reason a generating coordinator never self-received local completions,
+// and the base-node completion-surface bug (base completions land full-form
+// `daemon_<machineId>` while a coordinator that only knows itself as bare
+// `<machineId>` never matches them). We expand to EVERY equivalent form so the
+// scope match (host gate, self-node detection, and the drain IN-filter downstream)
+// succeeds regardless of which path stamped the event.
 function resolveCoordinatorDaemonIds(components: DaemonComponents): string[] {
-    const ids = new Set<string>();
     const statusInstanceId = readNonEmptyString((components as { statusInstanceId?: string }).statusInstanceId);
-    if (statusInstanceId) ids.add(statusInstanceId);
     const machineId = readNonEmptyString(loadConfig().machineId);
-    if (machineId) ids.add(machineId);
-    return [...ids];
+    return expandDaemonIdForms([statusInstanceId, machineId]);
 }
 
 // Whether THIS daemon is the coordinator/host for a mesh — i.e. the daemon that
@@ -316,6 +320,47 @@ function recordHeldTerminalEventsToLedger(
 //   PHASE 2 — Live CLI inject. For each mesh that has a live CLI coordinator on
 //     THIS daemon, drain the local queue and inject pending events into the PTY.
 //     Unchanged from before.
+// Bug B: how long a row may sit 'assigned' with an unconfirmed dispatch before the
+// watchdog reclaims it. Must be comfortably larger than the per-dispatch confirm
+// timeout (DISPATCH_CONFIRM_TIMEOUT_MS in mesh-events-coordinator) so a slow-but-live
+// dispatch still inside its normal confirm window is never reclaimed early — this is
+// the durable backstop for the case the in-process confirm timer can't cover (a timer
+// lost to a daemon restart between claim and confirm).
+const ASSIGNED_STRANDED_DEADLINE_MS = 5 * 60_000;
+
+// PHASE 2.5 — assigned-stranded dispatch watchdog (Bug B). claimNextTask atomically
+// flips a row to 'assigned' BEFORE the fire-and-forget dispatch runs. If that dispatch
+// neither rejects (→ no .catch requeue) nor is confirmed delivered — a relay that hangs
+// without acking, or a confirm timer lost across a restart — the row stays 'assigned'
+// forever: it contributes 0 pending, so PHASE 3 (gated on pendingQueueTaskCount>0) never
+// re-examines it, and nothing but a manual requeue clears it. This is that missing net.
+//
+// Regression guard: a row whose delivery IS confirmed (delivered/acked/completed) is a
+// genuinely in-flight (or completion-lost) task — left to PHASE 4's completion reconcile,
+// never reclaimed here. And the deadline is generous so a slow-but-live dispatch still in
+// its normal confirm window is never reclaimed early. Reclaimed rows return to 'pending'
+// with ownership cleared, so the PHASE 3 trigger below re-dispatches them this same tick.
+function recoverStrandedAssignedDispatches(meshId: string, store: MeshRuntimeStore): void {
+    const assigned = getQueue(meshId, { status: ['assigned'] });
+    if (!assigned.length) return;
+    const nowMs = Date.now();
+    for (const row of assigned) {
+        const dispatchedAtMs = Date.parse(row.dispatchTimestamp ?? '');
+        if (!Number.isFinite(dispatchedAtMs)) continue;              // no dispatch ts → can't age it
+        if (nowMs - dispatchedAtMs < ASSIGNED_STRANDED_DEADLINE_MS) continue;  // still in confirm window
+        if (store.taskHasConfirmedDelivery(meshId, row.id)) continue;          // dispatched → PHASE 4's job
+        const reclaimed = reclaimStrandedAssignedTask(meshId, row.id, {
+            reason: 'assigned_stranded_dispatch_unconfirmed',
+            ageMs: nowMs - dispatchedAtMs,
+        });
+        if (reclaimed) {
+            LOG.warn('MeshReconcile', `Reclaimed stranded assigned task ${row.id} on mesh ${meshId} `
+                + `(node=${row.assignedNodeId ?? '?'} session=${row.assignedSessionId ?? '?'}, dispatched `
+                + `${Math.round((nowMs - dispatchedAtMs) / 1000)}s ago, never confirmed delivered → ${reclaimed.status})`);
+        }
+    }
+}
+
 export async function runMeshReconcileTick(components: DaemonComponents): Promise<void> {
     const localDaemonId = readNonEmptyString(loadConfig().machineId) || undefined;
     // The id-set used to scope the local queue drain (status id + machineId). See
@@ -360,6 +405,21 @@ export async function runMeshReconcileTick(components: DaemonComponents): Promis
         }
     }
 
+    // ── PHASE 2.5: assigned-stranded dispatch watchdog (Bug B) ─────────────────
+    // Runs before PHASE 3 so any row it returns to 'pending' is re-dispatched by the
+    // PHASE 3 trigger in this same tick. See recoverStrandedAssignedDispatches.
+    if (store) {
+        for (const mesh of listMeshes()) {
+            const selfIds = resolveCoordinatorSelfIds(mesh, drainDaemonIds);
+            if (!daemonHostsMesh(mesh, selfIds)) continue;
+            try {
+                recoverStrandedAssignedDispatches(mesh.id, store);
+            } catch (e: any) {
+                LOG.warn('MeshReconcile', `Assigned-stranded watchdog failed for mesh ${mesh.id}: ${e?.message || e}`);
+            }
+        }
+    }
+
     // ── PHASE 3: recover pending queue claims for newly-idle sessions ──────────
     // The event-driven claim paths (agent:ready / agent:generating_completed in
     // mesh-events-coordinator) re-claim the queue the moment a session goes idle,

package/src/mesh/mesh-runtime-store.ts

@@ -1075,6 +1075,23 @@ export class MeshRuntimeStore {
         }));
     }
 
+    /**
+     * Bug B watchdog support: true when at least one delivery record for the task has
+     * reached a confirmed-handed-off status (delivered / acked / completed). The
+     * assigned-stranded watchdog uses this to distinguish a dispatch that was never
+     * confirmed (reclaimable) from one that WAS handed to the worker (a genuinely
+     * in-flight or completion-lost task, which is PHASE 4's responsibility, not this
+     * watchdog's). Indexed by (mesh_id, task_id).
+     */
+    taskHasConfirmedDelivery(meshId: string, taskId: string): boolean {
+        const row = this.db.prepare(`
+            SELECT 1 FROM mesh_session_delivery
+            WHERE mesh_id = ? AND task_id = ? AND status IN ('delivered','acked','completed')
+            LIMIT 1
+        `).get(meshId, taskId) as { 1: number } | undefined;
+        return !!row;
+    }
+
     expireStaleSessionDeliveries(meshId: string): void {
         const now = new Date().toISOString();
         this.db.prepare(`

package/src/mesh/mesh-work-queue.ts

@@ -5,6 +5,8 @@ import { MESH_CONVERGE_REFINE_TAG, resolveAutoConvergeCodeChange } from '../repo
 import { MeshRuntimeStore } from './mesh-runtime-store.js';
 import { getMesh } from '../config/mesh-config.js';
 import { LOG } from '../logging/logger.js';
+import { appendLedgerEntry } from './mesh-ledger.js';
+import type { MeshLedgerKind } from './mesh-ledger.js';
 
 export type MeshTaskStatus = 'pending' | 'assigned' | 'completed' | 'failed' | 'cancelled';
 export type MeshActiveTaskStatus = Extract<MeshTaskStatus, 'pending' | 'assigned'>;
@@ -339,6 +341,14 @@ export interface MeshWorkQueueEntry {
     requeueCount?: number;
     /** Max automatic requeue attempts. When requeueCount reaches this, task is auto-failed. */
     maxRetries?: number;
+    /**
+     * Bug B: number of times the reconcile assigned-stranded watchdog has reclaimed this
+     * row from 'assigned' back to 'pending' because its dispatch was never confirmed
+     * delivered. Separate from requeueCount (operator/execution retries) and bounded by
+     * MAX_STRANDED_RECLAIMS so a permanently-undeliverable target auto-fails rather than
+     * cycling reclaim→re-dispatch→strand forever.
+     */
+    strandedReclaimCount?: number;
     /** Last automatic queue session spin-up attempt, for mesh_view_queue/debug visibility. */
     autoLaunch?: {
         status: 'skipped' | 'started' | 'failed' | 'completed';
@@ -887,6 +897,85 @@ export function requeueTask(
     });
 }
 
+/**
+ * Max times the assigned-stranded watchdog will reclaim a single task before giving
+ * up and failing it. Bounds the reclaim→re-dispatch→strand cycle so a permanently
+ * undeliverable target (e.g. a node whose transport is wedged) eventually fails and
+ * unblocks its dependents instead of looping every reconcile tick.
+ */
+const MAX_STRANDED_RECLAIMS = 3;
+
+/**
+ * Bug B: reclaim a task stuck in 'assigned' because its dispatch was never confirmed.
+ *
+ * claimNextTask atomically marks a row 'assigned' BEFORE the fire-and-forget dispatch
+ * runs. If that dispatch neither rejects (→ no .catch requeue) nor is confirmed
+ * delivered — a relay that hangs without acking, or a confirm timer lost across a
+ * daemon restart — the row stays 'assigned' forever, contributing 0 pending so PHASE 3
+ * reconcile never re-examines it. This returns such a row to 'pending' and clears its
+ * dead assignment ownership (node / session / provider / dispatchTimestamp) — the same
+ * ownership-clear requeueTask applies — so PHASE 3 can re-dispatch it onto a fresh idle
+ * session.
+ *
+ * Guarded to 'assigned' rows only (a completion/cancel that already moved the row off
+ * 'assigned' must never be resurrected) and bounded by MAX_STRANDED_RECLAIMS (beyond
+ * which the task is failed so dependents unblock).
+ */
+export function reclaimStrandedAssignedTask(
+    meshId: string,
+    taskId: string,
+    opts?: { reason?: string; ageMs?: number } & MeshQueueMutationOptions,
+): MeshWorkQueueEntry | null {
+    requireMeshHostQueueOwner(opts);
+    return withQueueLock(meshId, () => {
+        const entry = MeshRuntimeStore.getInstance().findQueueEntryById(meshId, taskId);
+        if (!entry) return null;
+        // Only a still-assigned row is stranded. If a completion/cancel already moved it
+        // off 'assigned', there is nothing to reclaim — never resurrect a terminal row.
+        if (entry.status !== 'assigned') return null;
+        const now = new Date().toISOString();
+        const reason = opts?.reason || 'assigned_stranded_dispatch_unconfirmed';
+        const reclaims = (entry.strandedReclaimCount || 0) + 1;
+        const prevNode = entry.assignedNodeId;
+        const prevSession = entry.assignedSessionId;
+        // Always clear the dead assignment ownership so a re-claim starts clean and the
+        // assigned-counters (which filter status==='assigned') stop counting this row.
+        delete entry.assignedNodeId;
+        delete entry.assignedSessionId;
+        delete entry.assignedProviderType;
+        delete entry.dispatchTimestamp;
+        entry.strandedReclaimCount = reclaims;
+        entry.updatedAt = now;
+        if (reclaims > MAX_STRANDED_RECLAIMS) {
+            // Repeatedly undeliverable — stop cycling and fail it so dependents unblock.
+            entry.status = 'failed';
+            entry.cancelReason = `stranded_dispatch_unrecovered: reclaimed ${reclaims - 1} time(s) without a confirmed dispatch`;
+            MeshRuntimeStore.getInstance().updateQueueEntry(entry);
+            propagateDependencyFailure(meshId, taskId);
+        } else {
+            entry.status = 'pending';
+            entry.requeuedAt = now;
+            entry.requeueReason = reason;
+            MeshRuntimeStore.getInstance().updateQueueEntry(entry);
+        }
+        try {
+            appendLedgerEntry(meshId, {
+                kind: 'task_reclaimed' as MeshLedgerKind,
+                nodeId: prevNode,
+                sessionId: prevSession,
+                payload: {
+                    taskId,
+                    reason,
+                    ...(typeof opts?.ageMs === 'number' ? { ageMs: opts.ageMs } : {}),
+                    reclaimCount: reclaims,
+                    outcome: entry.status,
+                },
+            });
+        } catch { /* ledger write is best-effort */ }
+        return entry;
+    });
+}
+
 /**
  * Update the status of the task currently assigned to a specific session.
  */

package/src/providers/approval-utils.d.ts

@@ -8,4 +8,5 @@ export declare function pickAutoApprovalButton(buttons: string[] | null | undefi
     index: number;
     label: string;
 };
+export declare function hasNegativeApprovalOption(buttons: string[] | null | undefined): boolean;
 export declare function formatAutoApprovalMessage(modalMessage?: string, buttonLabel?: string): string;

package/src/providers/approval-utils.ts

@@ -31,6 +31,16 @@ function isNegativeApprovalLabel(value: string): boolean {
         || /\bdo not\b/.test(label);
 }
 
+/**
+ * True when any of the given button labels reads as a decline/negative option
+ * (No / Deny / Cancel / Skip / …). Used as the second half of an approval-modal
+ * structural anchor: a real approval modal offers BOTH an affirmative and a
+ * decline, which distinguishes it from a generic numbered menu or prose list.
+ */
+export function hasNegativeApprovalOption(buttons: string[] | null | undefined): boolean {
+    return (buttons || []).some((button) => isNegativeApprovalLabel(String(button || '')));
+}
+
 export function getApprovalPositiveHints(provider?: Pick<ProviderModule, 'approvalPositiveHints'> | null): string[] {
     const customHints = Array.isArray(provider?.approvalPositiveHints)
         ? provider.approvalPositiveHints

package/src/providers/cli-provider-instance.ts

@@ -376,6 +376,21 @@ export class CliProviderInstance implements ProviderInstance {
      */
     private static readonly AUTO_APPROVE_SETTLE_MS = 600;
 
+    /**
+     * Busy-side hysteresis for the settle gate. A momentary `generating` flip
+     * while the SAME approval modal's button block is still on screen (its
+     * question line scrolled out of the captured frame, only the buttons + a
+     * residual `esc to interrupt` spinner remain) briefly reports
+     * status!=waiting_approval. Without hysteresis that flip wipes the settle
+     * clock, and the modal→generating→modal flap restarts the 600ms window
+     * every time so auto-approve never fires. We keep the in-progress settle
+     * gate warm across an inactive blip up to this bound; only once the modal
+     * has genuinely stayed gone this long (a real resolution → idle) is the
+     * gate cleared. Bounded so a genuinely new, later approval still re-settles
+     * from scratch rather than firing on a stale timestamp.
+     */
+    private static readonly AUTO_APPROVE_GATE_HYSTERESIS_MS = 1500;
+
     private adapter: ProviderCliAdapter;
     private context: InstanceContext | null = null;
     private events: ProviderEvent[] = [];
@@ -397,6 +412,10 @@ export class CliProviderInstance implements ProviderInstance {
     private pendingAutoApprovalSignature = '';
     private pendingAutoApprovalSince = 0;
     private autoApproveSettleTimer: NodeJS.Timeout | null = null;
+    // Wall-clock when auto-approve first observed status!=waiting_approval while
+    // a settle gate was in progress. Drives AUTO_APPROVE_GATE_HYSTERESIS_MS so a
+    // brief generating flip does not immediately wipe the settle clock.
+    private autoApproveInactiveSince = 0;
     private controlValues: Record<string, string | number | boolean> = {};
     private summaryMetadata: unknown = undefined;
     private appliedEffectKeys = new Set<string>();
@@ -1471,13 +1490,37 @@ export class CliProviderInstance implements ProviderInstance {
         // still inside the short busy window.
         if (!autoApproveActive) {
             this.lastAutoApprovalSignature = '';
+            // Hysteresis: if a settle gate is mid-progress, a momentary
+            // status!=waiting_approval blip (a generating flip while the same
+            // modal's button block is still on screen) must NOT wipe the settle
+            // clock — otherwise the modal→generating→modal flap restarts the
+            // 600ms window every time and auto-approve never fires. Keep the
+            // gate warm for AUTO_APPROVE_GATE_HYSTERESIS_MS; re-arm a timer so
+            // that if the modal does NOT come back the gate is cleared on the
+            // re-check (a genuine resolution → idle frees the gate normally).
+            if (this.pendingAutoApprovalSince) {
+                if (!this.autoApproveInactiveSince) this.autoApproveInactiveSince = now;
+                const goneForMs = now - this.autoApproveInactiveSince;
+                if (goneForMs < CliProviderInstance.AUTO_APPROVE_GATE_HYSTERESIS_MS) {
+                    if (this.autoApproveSettleTimer) clearTimeout(this.autoApproveSettleTimer);
+                    this.autoApproveSettleTimer = setTimeout(() => {
+                        this.autoApproveSettleTimer = null;
+                        this.recheckAutoApproveSettled();
+                    }, CliProviderInstance.AUTO_APPROVE_GATE_HYSTERESIS_MS - goneForMs + 20);
+                    return autoApproveActive;
+                }
+            }
             // Clear the settle gate so the next approval starts its own quiet
             // window from scratch (a stale timestamp would let it fire instantly).
             this.pendingAutoApprovalSignature = '';
             this.pendingAutoApprovalSince = 0;
+            this.autoApproveInactiveSince = 0;
             if (this.autoApproveSettleTimer) { clearTimeout(this.autoApproveSettleTimer); this.autoApproveSettleTimer = null; }
             return autoApproveActive;
         }
+        // Active approval observed — reset the inactivity tracker so a later
+        // blip starts its hysteresis window fresh.
+        this.autoApproveInactiveSince = 0;
         const modal = adapterStatus.activeModal;
         // (fix) Do not auto-approve when no concrete modal/buttons are present.
         // Claude TUI flaps between paints; without this guard adapterStatus
@@ -1497,34 +1540,44 @@ export class CliProviderInstance implements ProviderInstance {
             // surface the modal so the user can decide.
             return autoApproveActive;
         }
-        // Include the FSM's approval entry seq: two distinct back-to-back
-        // approvals can carry identical message/buttons (common with
-        // claude-cli). Without the seq their signatures collide and the 5s
-        // busy-window re-entry guard below swallows the second auto-approve,
+        // Modal *identity* signature — the question/button set only, NO volatile
+        // counters. This is what the settle gate tracks: the FSM bumps
+        // approvalEntrySeq on every fresh waiting_approval entry, and a
+        // modal→generating→modal flap (the question line scrolled out of the
+        // captured frame while the button block stays) re-enters and bumps it
+        // again. Folding that seq into the settle signature made the 600ms
+        // settle clock restart on every flap, so the modal never stayed stable
+        // long enough to fire — the gate was never satisfied. Identity excludes
+        // the seq so button/seq flap of the SAME modal keeps one settle clock.
+        const modalSignature = [
+            typeof modal?.message === 'string' ? modal.message.trim() : '',
+            buttons.join('|'),
+            buttonIndex,
+        ].join('::');
+        // Busy-window re-entry guard still needs the seq: two DISTINCT
+        // back-to-back approvals can carry identical message/buttons (common
+        // with claude-cli). Without the seq their busy signatures collide and
+        // the 5s busy-window guard below would swallow the second auto-approve,
         // leaving it stuck. The seq is bumped by the FSM on every fresh
-        // waiting_approval entry, so a new approval always yields a new
+        // waiting_approval entry, so a new approval always yields a new busy
         // signature and fires through.
         const approvalEntrySeq = typeof adapterStatus?.approvalEntrySeq === 'number'
             ? adapterStatus.approvalEntrySeq
             : 0;
-        const signature = [
-            approvalEntrySeq,
-            typeof modal?.message === 'string' ? modal.message.trim() : '',
-            buttons.join('|'),
-            buttonIndex,
-        ].join('::');
-        // Already fired for this exact modal and still inside the busy window —
-        // nothing to do (re-entry guard for repeated snapshots of one modal).
-        if (this.autoApproveBusy && signature === this.lastAutoApprovalSignature) {
+        const busySignature = `${approvalEntrySeq}::${modalSignature}`;
+        // Already fired for this exact modal entry and still inside the busy
+        // window — nothing to do (re-entry guard for repeated snapshots of one
+        // modal).
+        if (this.autoApproveBusy && busySignature === this.lastAutoApprovalSignature) {
             return autoApproveActive;
         }
 
-        // Settle gate: only fire once this exact signature has been stable for
+        // Settle gate: only fire once this modal identity has been stable for
         // AUTO_APPROVE_SETTLE_MS. A still-streaming prompt mutates its
-        // message/buttons each frame → new signature → clock restarts, so we
+        // message/buttons each frame → new identity → clock restarts, so we
         // never approve a half-rendered prompt (the "resolves too fast" bug).
-        if (signature !== this.pendingAutoApprovalSignature) {
-            this.pendingAutoApprovalSignature = signature;
+        if (modalSignature !== this.pendingAutoApprovalSignature) {
+            this.pendingAutoApprovalSignature = modalSignature;
             this.pendingAutoApprovalSince = now;
         }
         const settledForMs = now - this.pendingAutoApprovalSince;
@@ -1543,9 +1596,10 @@ export class CliProviderInstance implements ProviderInstance {
         // Settled — fire the approve key.
         if (this.autoApproveSettleTimer) { clearTimeout(this.autoApproveSettleTimer); this.autoApproveSettleTimer = null; }
         this.autoApproveBusy = true;
-        this.lastAutoApprovalSignature = signature;
+        this.lastAutoApprovalSignature = busySignature;
         this.pendingAutoApprovalSignature = '';
         this.pendingAutoApprovalSince = 0;
+        this.autoApproveInactiveSince = 0;
         if (this.autoApproveBusyTimer) clearTimeout(this.autoApproveBusyTimer);
         this.autoApproveBusyTimer = setTimeout(() => {
             this.autoApproveBusy = false;

package/src/providers/sdk/v1/builders/cli/detect-status.ts

@@ -28,6 +28,10 @@ import {
   applyVisibleRegion,
   type VisibleRegionSpec,
 } from './visible-region.js';
+import {
+  pickApprovalButton,
+  hasNegativeApprovalOption,
+} from '../../../../approval-utils.js';
 
 // ─── Primitive spec shapes (mirror the JSON schemas) ───────────────────
 
@@ -69,6 +73,7 @@ interface ModalSpec {
   questionVariants?: Array<{ regex: string; flags?: string; label?: string }>;
   buttonPattern: string;
   buttonFlags?: string;
+  buttonLabelGroup?: number;
 }
 
 export type DispatchGroup =
@@ -163,6 +168,48 @@ function settledPromptMatches(spec: SettledPromptSpec, input: CliStatusInput): b
   return footers.every((f) => f.test(text));
 }
 
+/**
+ * Extract approval-button labels from every line matching the modal spec's
+ * `buttonPattern`. Mirrors buildParseApprovalFromTui's per-line extraction but
+ * scans the whole screen with no question-line anchor, so the cue survives the
+ * question line scrolling out of the captured frame during long runs of
+ * consecutive approvals.
+ */
+function extractButtonLabels(spec: ModalSpec, text: string): string[] {
+  if (!text) return [];
+  const flags = spec.buttonFlags && spec.buttonFlags.includes('m')
+    ? spec.buttonFlags
+    : `${spec.buttonFlags ?? ''}m`;
+  const buttonRe = compile(spec.buttonPattern, flags);
+  const labelGroup = Number.isInteger(spec.buttonLabelGroup) && (spec.buttonLabelGroup ?? 0) > 0
+    ? spec.buttonLabelGroup!
+    : 1;
+  const out: string[] = [];
+  for (const line of text.split('\n')) {
+    buttonRe.lastIndex = 0;
+    const m = buttonRe.exec(line);
+    if (!m) continue;
+    const captured = m[labelGroup] ?? (labelGroup === 1 && m.length > 2 ? m[m.length - 1] : undefined);
+    if (captured && captured.trim()) out.push(captured.trim());
+  }
+  return out;
+}
+
+/**
+ * (fixB ①) The approval's selectable button block is itself a modal cue.
+ * Anchored on approval *verbs* so it generalizes across CLIs without trusting
+ * any single spec's `buttonPattern` specificity: a real approval modal offers
+ * BOTH an affirmative option (Yes/Allow/Continue/…) and a decline (No/Deny/
+ * Cancel/Skip/…). A generic numbered menu, a single prose "1. Yes …" line, or
+ * an assistant enumeration lacks that pair and does not fire the cue.
+ */
+function buttonBlockApprovalCue(spec: ModalSpec, text: string): boolean {
+  const labels = extractButtonLabels(spec, text);
+  if (labels.length < 2) return false;
+  if (pickApprovalButton(labels).index < 0) return false;
+  return hasNegativeApprovalOption(labels);
+}
+
 function modalMatches(spec: ModalSpec, input: CliStatusInput): boolean {
   // Status-level modal detection is cue-only — does the question appear at all?
   // Button extraction lives in buildParseApprovalFromTui.
@@ -173,6 +220,10 @@ function modalMatches(spec: ModalSpec, input: CliStatusInput): boolean {
     const re = compile(variant.regex, variant.flags ?? 'i');
     if (re.test(text)) return true;
   }
+  // The question line can scroll out of the captured frame while the button
+  // block (and a residual spinner) remain. Hold the modal cue on the button
+  // block alone so waiting_approval does not flap to generating mid-approval.
+  if (buttonBlockApprovalCue(spec, text)) return true;
   return false;
 }