@adhdev/daemon-core 0.9.82-rc.565 → 0.9.82-rc.567

package/dist/mesh/mesh-active-work.d.ts

@@ -75,6 +75,10 @@ export interface BuildMeshActiveWorkOptions {
     /** Include terminal direct rows (idle/failed) for handoff/recent-work surfaces. Defaults false. */
     includeTerminalDirect?: boolean;
 }
+export declare function sessionStatusFromNodes(nodes: any[] | undefined, nodeId?: string, sessionId?: string): {
+    status?: MeshActiveWorkStatus;
+    staleReason?: string;
+};
 /**
  * One session awaiting an approval decision — the derived row `mesh_list_pending_approvals`
  * returns and the UI approvals inbox renders. A thin projection of the `awaiting_approval`

package/dist/providers/cli-provider-instance.d.ts

@@ -31,6 +31,15 @@ export declare class CliProviderInstance implements ProviderInstance {
      * keystroke until the modal *content* has settled.
      */
     private static readonly AUTO_APPROVE_SETTLE_MS;
+    /**
+     * APPROVAL-INBOX-BLINDSPOT (Fix A): how long after a LOCAL auto-approve fire the mesh
+     * event forwarder still treats the modal as "being resolved locally" and suppresses the
+     * coordinator notification. Chosen to comfortably cover the resolveModal → PTY absorb →
+     * status-leaves-approval round trip (incl. the win32 CR-resend loop) while staying short
+     * enough that a modal which auto-approve fired at but did NOT resolve re-surfaces to the
+     * coordinator on the next event. Aligned with the adapter's own approval cooldown scale.
+     */
+    private static readonly APPROVAL_LOCAL_RESOLUTION_COOLDOWN_MS;
     /**
      * Busy-side hysteresis for the settle gate. A momentary `generating` flip
      * while the SAME approval modal's button block is still on screen (its
@@ -200,6 +209,7 @@ export declare class CliProviderInstance implements ProviderInstance {
     private autoApproveSettleTimer;
     private autoApproveInactiveSince;
     private autoApproveLastModalSeenAt;
+    private lastAutoApproveFiredAt;
     private approvalStickyLastConcreteAt;
     private approvalStickyModal;
     private approvalStickyEntrySeq;
@@ -315,6 +325,21 @@ export declare class CliProviderInstance implements ProviderInstance {
      * absent from some of them.
      */
     resolveModalParkStatus(): 'waiting_choice' | 'waiting_approval' | null;
+    /**
+     * APPROVAL-INBOX-BLINDSPOT (Fix A): true when this session's approval modal was — or is
+     * being — resolved LOCALLY within the recent cooldown. Two independent positive signals:
+     *   (1) auto-approve fired its resolveModal within APPROVAL_LOCAL_RESOLUTION_COOLDOWN_MS
+     *       (lastAutoApproveFiredAt), or
+     *   (2) the underlying adapter reports isApprovalRecentlyResolved() — its own resolve
+     *       cooldown, which also covers a dashboard / mesh_approve resolution.
+     * The mesh event forwarder uses this to decide whether an agent:waiting_approval from an
+     * auto-approving worker can be safely SUPPRESSED (a local resolution is in flight) or must
+     * be FORWARDED (auto-approve is configured but has NOT actually resolved this modal, so the
+     * coordinator/inbox must be told). Keying suppression on real resolution — not just the
+     * autoApprove *intent* — is the blind-spot fix: a never-resolving worker approval is no
+     * longer silently dropped.
+     */
+    approvalRecentlyResolvedLocally(now?: number): boolean;
     /**
      * NOTIF-HELD-DRAIN: true when this `waiting_approval` is a routine, transient tool-consent
      * of an autonomously-progressing mesh session rather than a genuine human-await modal —

package/dist/providers/spec/cli-adapter.d.ts

@@ -143,6 +143,7 @@ export declare class SpecCliAdapter implements CliAdapter {
     writeRaw(data: string): void;
     resize(cols: number, rows: number): void;
     resolveModal(buttonIndex: number): void;
+    resolveModalMatched(buttonIndex: number): boolean;
     resolveAction(data: unknown): Promise<void>;
     setInteractivePromptResponse(response: InteractivePromptResponse): Promise<void>;
     isApprovalRecentlyResolved(): boolean;

package/dist/providers/spec/fsm-driver.d.ts

@@ -119,6 +119,13 @@ export interface ISpecDriver {
     subscribe(listener: (ev: DashboardEvent) => void): () => void;
     start(): void;
     dispatch(cmd: DashboardCommand): void;
+    /**
+     * BUTTON-INDEX-MISMAP (Fix C.3): click a modal button by its FSM display index and report
+     * whether a button was actually matched and its confirm keys dispatched. Unlike the
+     * fire-and-forget `dispatch('click_modal_button')`, callers that need to know the click
+     * landed (mesh_approve → SpecCliAdapter.resolveModalMatched) can observe a miss.
+     */
+    clickModalButton(index: number): boolean;
     updateMeta(meta: Record<string, unknown>, replace?: boolean): void;
     snapshot(): string;
     getCursorPosition(): {
@@ -423,6 +430,17 @@ export declare class FsmDriver implements ISpecDriver {
      */
     private scheduleWin32Submit;
     private handleClickControl;
+    /**
+     * BUTTON-INDEX-MISMAP (Fix C.3): public modal-click entry that returns whether a button
+     * matching the requested FSM display index was actually found and its confirm keys were
+     * dispatched. The old private handleClickModalButton silently `return`ed on a miss (no
+     * modal captured, or no button whose `.index` equals the requested display index), so a
+     * mis-mapped index looked identical to a successful press. Callers that need to know
+     * whether the click landed (mesh_approve → resolveModal) can now observe the miss instead
+     * of reporting success into the void. The generic `dispatch('click_modal_button')` path
+     * keeps ignoring the return (fire-and-forget UI clicks).
+     */
+    clickModalButton(index: number): boolean;
     private handleClickModalButton;
     /**
      * Submit a modal-confirm key sequence (the choice key + its trailing CR).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adhdev/daemon-core",
-  "version": "0.9.82-rc.565",
+  "version": "0.9.82-rc.567",
   "description": "ADHDev daemon core — CDP, IDE detection, providers, command execution",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -47,8 +47,8 @@
   "author": "vilmire",
   "license": "AGPL-3.0-or-later",
   "dependencies": {
-    "@adhdev/mesh-shared": "0.9.82-rc.565",
-    "@adhdev/session-host-core": "0.9.82-rc.565",
+    "@adhdev/mesh-shared": "0.9.82-rc.567",
+    "@adhdev/session-host-core": "0.9.82-rc.567",
     "@agentclientprotocol/sdk": "^0.16.1",
     "ajv": "^8.20.0",
     "ajv-formats": "^3.0.1",

package/src/cli-adapter-types.d.ts

@@ -54,6 +54,7 @@ export interface CliAdapter {
     clearHistory?(): void;
     resolveAction?(data: unknown): Promise<void>;
     resolveModal?(buttonIndex: number): void;
+    resolveModalMatched?(buttonIndex: number): boolean;
     isApprovalRecentlyResolved?(): boolean;
     setOnPtyData?(callback: (data: string) => void): void;
     writeRaw?(data: string): void;

package/src/cli-adapter-types.ts

@@ -15,6 +15,16 @@ export interface CliAdapterStatus {
     activeModal?: {
         message: string;
         buttons: string[];
+        /**
+         * BUTTON-INDEX-MISMAP (Fix C.1): each button's label paired with its real FSM
+         * DISPLAYED index (evaluator's Number(m[1])). `buttons` above is the label-only list
+         * every existing consumer reads (array position === pick order); `buttonMeta` preserves
+         * the index → label mapping so a partial / non-contiguous modal (display indices [1,3,4]
+         * at array positions [0,1,2]) does not lose its true indices once the modal leaves the
+         * adapter. Present only on spec/FSM adapters; absent for adapters that surface labels
+         * alone.
+         */
+        buttonMeta?: { index: number; label: string }[];
         /**
          * Semantic modal class, when the adapter knows it (spec/FSM path):
          * 'approval' = tool/command/trust consent (auto-approve may fire);
@@ -155,6 +165,13 @@ export interface CliAdapter {
     resolveAction?(data: unknown): Promise<void>;
     setInteractivePromptResponse?(response: InteractivePromptResponse): Promise<void>;
     resolveModal?(buttonIndex: number): void;
+    // BUTTON-INDEX-MISMAP (Fix C.3): resolve a modal button by ARRAY POSITION and report
+    // whether a real button was matched (the FSM found a button for the mapped display index
+    // and dispatched its confirm keys). A `false` verdict means the requested position mapped
+    // to no button — the caller (mesh_approve) must then NOT report success. Optional so
+    // legacy adapters that only expose the void resolveModal keep working (the caller falls
+    // back to resolveModal + the resolution-cooldown check).
+    resolveModalMatched?(buttonIndex: number): boolean;
     isApprovalRecentlyResolved?(): boolean;
  // Raw PTY I/O (for terminal view)
     setOnPtyData?(callback: (data: string) => void): void;

package/src/commands/chat-commands-write.ts

@@ -795,7 +795,21 @@ export async function handleResolveAction(h: CommandHelpers, args: any): Promise
             LOG.info('Command', `[resolveAction] CLI PTY → stale_prompt (already resolved within cooldown)`);
             return { success: true, stalePrompt: true, buttonIndex, button: buttons[buttonIndex] ?? button };
         }
-        if (typeof adapter.resolveModal === 'function') {
+        // BUTTON-INDEX-MISMAP (Fix C.3): prefer resolveModalMatched — it maps the array
+        // position to the real FSM display index AND reports whether a button was actually
+        // matched. The old path called the void resolveModal and unconditionally returned
+        // success:true, so a mis-mapped index (partial/non-contiguous modal) that pressed
+        // NOTHING still reported success and left the worker wedged at the modal. When the
+        // adapter tells us no button matched, report failure so mesh_approve / the coordinator
+        // sees the miss instead of a false success. Legacy adapters without resolveModalMatched
+        // keep the prior void-resolveModal behaviour.
+        if (typeof adapter.resolveModalMatched === 'function') {
+            const matched = adapter.resolveModalMatched(buttonIndex);
+            if (!matched) {
+                LOG.warn('Command', `[resolveAction] CLI PTY → no button matched for buttonIndex=${buttonIndex} "${buttons[buttonIndex] ?? '?'}" (modal not resolved)`);
+                return { success: false, error: 'Approval button index did not map to a visible modal button', buttonIndex, button: buttons[buttonIndex] ?? button };
+            }
+        } else if (typeof adapter.resolveModal === 'function') {
             adapter.resolveModal(buttonIndex);
         } else {
             const keys = '\x1B[B'.repeat(Math.max(0, buttonIndex)) + '\r';

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

@@ -102,7 +102,7 @@ function elapsedSince(value: string | undefined, now: number): number {
     return Number.isFinite(started) ? Math.max(0, now - started) : 0;
 }
 
-function sessionStatusFromNodes(nodes: any[] | undefined, nodeId?: string, sessionId?: string): { status?: MeshActiveWorkStatus; staleReason?: string } {
+export function sessionStatusFromNodes(nodes: any[] | undefined, nodeId?: string, sessionId?: string): { status?: MeshActiveWorkStatus; staleReason?: string } {
     if (!Array.isArray(nodes)) return {};
     if (!nodeId) return { staleReason: 'direct task has no node id' };
     const node = nodes.find(item => meshNodeIdMatches(item, nodeId));
@@ -365,12 +365,30 @@ export function buildMeshActiveWork(opts: BuildMeshActiveWorkOptions): { activeW
     for (const task of opts.queue || []) {
         if (task.status !== 'pending' && task.status !== 'assigned') continue;
         const { title, summary } = summarizeMessage(task.message || '');
+        const queueNodeId = task.assignedNodeId || task.targetNodeId;
+        const queueSessionId = task.assignedSessionId || task.targetSessionId;
+        // APPROVAL-INBOX-BLINDSPOT (Fix A.2): a queue task previously reported its raw DB
+        // status (pending|assigned) verbatim, while direct dispatches consulted the live
+        // session status via sessionStatusFromNodes. That asymmetry meant a queue-dispatched
+        // worker sitting on an approval modal was recorded as 'assigned', so
+        // collectPendingApprovals (which filters status==='awaiting_approval') never counted
+        // it and mesh_list_pending_approvals returned 0. Overlay the live session status for
+        // an ASSIGNED queue task so an approval (or an active generation) on its bound session
+        // is reflected — the exact promotion the direct-dispatch path already does. A 'pending'
+        // task has no bound session yet, so it keeps its queue status.
+        const queueLive = task.status === 'assigned'
+            ? sessionStatusFromNodes(opts.nodes, queueNodeId ?? undefined, queueSessionId ?? undefined)
+            : {};
+        const queueStatus: MeshActiveWorkStatus = queueLive.status === 'awaiting_approval'
+            || queueLive.status === 'generating'
+            ? queueLive.status
+            : task.status;
         records.push({
             taskId: task.id,
             source: 'queue',
-            status: task.status,
-            nodeId: task.assignedNodeId || task.targetNodeId,
-            sessionId: task.assignedSessionId || task.targetSessionId,
+            status: queueStatus,
+            nodeId: queueNodeId,
+            sessionId: queueSessionId,
             taskTitle: title,
             taskSummary: summary,
             message: task.message,

package/src/mesh/mesh-event-forwarding.ts

@@ -727,25 +727,39 @@ function evaluateMeshEventSuppression(
 }
 
 /**
- * True when the worker session that emitted this event has auto-approve enabled
- * (a MAGI/delegated worker is launched with autoApprove:true). Such a worker
- * resolves its own approval modals locally, so an agent:waiting_approval event
- * from it is transient noise for the coordinator: forwarding it injects a
- * "[System] … is waiting for approval, use mesh_approve" turn that the
- * coordinator cannot usefully act on (the modal is already auto-resolving) and,
- * mid-MAGI-collect, HIJACKS the coordinator's synthesis turn — the observed
- * failure where a replica's repeated auto-approvals drowned out the completion
- * events and the coordinator answered about approvals instead of the RCA. Only
- * suppress when we can positively confirm the source worker auto-approves; a
- * worker that genuinely needs a human/coordinator approval (autoApprove off)
- * still forwards so the coordinator is told.
+ * APPROVAL-INBOX-BLINDSPOT (Fix A): decide whether an agent:waiting_approval from an
+ * auto-approving worker can be SUPPRESSED (never forwarded to the coordinator).
+ *
+ * A MAGI/delegated worker launched with autoApprove:true resolves its own approval modals
+ * locally, so a forwarded agent:waiting_approval is transient noise: it injects a
+ * "[System] … is waiting for approval, use mesh_approve" turn the coordinator cannot usefully
+ * act on (the modal is already auto-resolving) and, mid-MAGI-collect, HIJACKS the
+ * coordinator's synthesis turn — the observed failure where a replica's repeated
+ * auto-approvals drowned out the completion events.
+ *
+ * BUT the OLD gate suppressed on the autoApprove *intent* alone (settings.autoApprove===true),
+ * which is the blind spot: if the worker's local resolveModal never actually fired/resolved
+ * (button-index mismatch, a modal auto-approve declined to answer, an unattended stall), the
+ * event was STILL dropped — so no task_approval_needed ledger row was created,
+ * mesh_list_pending_approvals stayed 0, the coordinator was never told, and the remote
+ * UNKNOWN-grace reclaim eventually tore the worker off its task. This tightens the gate:
+ * suppress ONLY when auto-approve is on AND we can positively confirm the modal was — or is
+ * being — resolved LOCALLY within the recent cooldown (approvalRecentlyResolvedLocally). If
+ * auto-approve is configured but has NOT actually resolved this modal, we FORWARD so the
+ * coordinator/inbox is told and can act.
  */
-function sourceWorkerAutoApproves(components: DaemonComponents, sessionId: string): boolean {
+function shouldSuppressAutoApprovingWorkerApproval(components: DaemonComponents, sessionId: string): boolean {
     if (!sessionId) return false;
     try {
-        const state = components.instanceManager?.getInstance?.(sessionId)?.getState?.();
+        const instance = components.instanceManager?.getInstance?.(sessionId);
+        const state = instance?.getState?.();
         const settings = (state?.settings as Record<string, unknown>) || {};
-        return settings.autoApprove === true;
+        if (settings.autoApprove !== true) return false;
+        // Positive local-resolution signal required to suppress. Absent it, forward so the
+        // coordinator is told and a task_approval_needed ledger row is created.
+        const resolvedLocally = (instance as { approvalRecentlyResolvedLocally?: () => boolean } | undefined)
+            ?.approvalRecentlyResolvedLocally;
+        return typeof resolvedLocally === 'function' ? resolvedLocally.call(instance) === true : false;
     } catch {
         return false;
     }
@@ -1016,14 +1030,18 @@ function injectMeshSystemMessage(components: DaemonComponents, args: {
 
     const eventTimestamp = readEventTimestamp(args.metadataEvent.timestamp);
 
-    // Auto-approving worker: never forward its approval prompts to the coordinator.
-    // The daemon resolves the modal locally, so the "[System] … waiting for
-    // approval" injection is pure noise that hijacks the coordinator's turn — the
-    // observed MAGI failure where a replica's repeated auto-approvals flooded the
-    // coordinator and derailed its final synthesis. A worker without auto-approve
-    // (genuinely blocked on a human/coordinator decision) still forwards.
-    if (args.event === 'agent:waiting_approval' && sourceWorkerAutoApproves(components, eventSessionId)) {
-        LOG.info('MeshEvents', `Suppressed agent:waiting_approval for auto-approving worker session ${eventSessionId || '(unknown)'} (mesh ${args.meshId}) — modal is resolved locally, coordinator not notified`);
+    // Auto-approving worker: suppress its approval prompt ONLY when the modal was — or is
+    // being — resolved LOCALLY within the recent cooldown. The daemon resolving the modal
+    // locally makes the "[System] … waiting for approval" injection pure noise that hijacks
+    // the coordinator's turn (the observed MAGI failure where a replica's repeated
+    // auto-approvals flooded the coordinator and derailed its final synthesis). But a worker
+    // whose auto-approve is merely CONFIGURED on and did NOT actually resolve this modal
+    // (button-index mismatch, an unattended stall, a modal auto-approve declined to answer)
+    // must still forward — otherwise no task_approval_needed ledger row is created, the
+    // coordinator/inbox is never told, and the remote UNKNOWN-grace reclaim eventually tears
+    // the worker off its task (APPROVAL-INBOX-BLINDSPOT, Fix A).
+    if (args.event === 'agent:waiting_approval' && shouldSuppressAutoApprovingWorkerApproval(components, eventSessionId)) {
+        LOG.info('MeshEvents', `Suppressed agent:waiting_approval for auto-approving worker session ${eventSessionId || '(unknown)'} (mesh ${args.meshId}) — modal resolved locally within cooldown, coordinator not notified`);
         traceMeshEventDrop('waiting_approval_auto_approving_worker', traceCtx);
         return { success: true, forwarded: 0, suppressed: true, autoApprovingWorkerApproval: true };
     }

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

@@ -81,6 +81,7 @@ import {
     autoPruneStaleDirectDispatches,
     pollAssignedTaskTerminalEvidence,
 } from './mesh-completion-synthesis.js';
+import { sessionStatusFromNodes } from './mesh-active-work.js';
 
 // Re-export the extracted public API so existing importers (mesh-events.ts barrel;
 // the reconcile-loop test suite) keep their `from './mesh-reconcile-loop.js'` paths.
@@ -726,6 +727,28 @@ export function __resetReclaimUnknownStreakForTests(): void {
     deliveredUnconsumedUnknownStreak.clear();
 }
 
+// APPROVAL-INBOX-BLINDSPOT (Fix A.3): true when the assigned row's bound session is, per the
+// LIVE mesh-node snapshots, sitting at an approval modal (waiting_approval). A REMOTE worker
+// blocked on an approval reads UNKNOWN from resolveSessionBusyVerdict (it is not in THIS
+// daemon's local instance map), so without this guard the delivered-no-turn / delivered-not-
+// consumed UNKNOWN streak advances toward a false reclaim that tears the worker off a task it
+// is legitimately paused on awaiting the coordinator's mesh_approve. The live status is read
+// from the same node session snapshots mesh_status / the active-work builder use, so it is
+// positive cross-daemon evidence (not a local-only observation). When present it HOLDS the row
+// without accruing the streak; the reclaim resumes normally once the approval clears.
+function assignedRowLiveStatusIsAwaitingApproval(
+    mesh: { nodes?: any[] },
+    nodeId?: string | null,
+    sessionId?: string | null,
+): boolean {
+    if (!nodeId || !sessionId) return false;
+    try {
+        return sessionStatusFromNodes(mesh.nodes, nodeId, sessionId).status === 'awaiting_approval';
+    } catch {
+        return false;
+    }
+}
+
 // 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
@@ -809,6 +832,20 @@ async function recoverStrandedAssignedDispatches(
             } else {
                 if (verdict === 'IDLE_CONFIRMED') {
                     deliveredUnconsumedUnknownStreak.delete(shortStreakKey);
+                } else if (assignedRowLiveStatusIsAwaitingApproval(mesh, row.assignedNodeId, row.assignedSessionId)) {
+                    // APPROVAL-INBOX-BLINDSPOT (Fix A.3): the UNKNOWN (remote) worker is live and
+                    // sitting at an approval modal — it is legitimately paused awaiting the
+                    // coordinator's mesh_approve, NOT a lost delivery. HOLD without advancing the
+                    // streak so a genuine approval-blocked worker is never re-driven out from
+                    // under its pending approval.
+                    traceMeshEventDrop('short_redrive_deferred_awaiting_approval', {
+                        taskId: row.id,
+                        sessionId: row.assignedSessionId,
+                        nodeId: row.assignedNodeId,
+                        meshId,
+                        event: 'agent:waiting_approval',
+                    }, 'live_awaiting_approval');
+                    continue;
                 } else {
                     const streak = (deliveredUnconsumedUnknownStreak.get(shortStreakKey) ?? 0) + 1;
                     deliveredUnconsumedUnknownStreak.set(shortStreakKey, streak);
@@ -899,6 +936,21 @@ async function recoverStrandedAssignedDispatches(
             if (verdict === 'IDLE_CONFIRMED') {
                 deliveredNoTurnUnknownStreak.delete(streakKey);
                 reclaimReason = 'delivered_no_turn_deadline';
+            } else if (assignedRowLiveStatusIsAwaitingApproval(mesh, row.assignedNodeId, row.assignedSessionId)) {
+                // APPROVAL-INBOX-BLINDSPOT (Fix A.3): the UNKNOWN (remote) worker is live and
+                // sitting at an approval modal — legitimately paused awaiting the coordinator's
+                // mesh_approve, NOT a delivered-but-lost completion. HOLD without advancing the
+                // streak so a genuine approval-blocked worker is never reclaimed at the
+                // delivered-no-turn deadline. The reclaim resumes normally once the approval
+                // clears (the live status leaves waiting_approval).
+                traceMeshEventDrop('reclaim_deferred_awaiting_approval', {
+                    taskId: row.id,
+                    sessionId: row.assignedSessionId,
+                    nodeId: row.assignedNodeId,
+                    meshId,
+                    event: 'agent:waiting_approval',
+                }, 'live_awaiting_approval');
+                continue;
             } else {
                 // UNKNOWN — defer and accumulate the consecutive-UNKNOWN streak.
                 const streak = (deliveredNoTurnUnknownStreak.get(streakKey) ?? 0) + 1;

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

@@ -109,6 +109,16 @@ export class CliProviderInstance implements ProviderInstance {
      */
     private static readonly AUTO_APPROVE_SETTLE_MS = 600;
 
+    /**
+     * APPROVAL-INBOX-BLINDSPOT (Fix A): how long after a LOCAL auto-approve fire the mesh
+     * event forwarder still treats the modal as "being resolved locally" and suppresses the
+     * coordinator notification. Chosen to comfortably cover the resolveModal → PTY absorb →
+     * status-leaves-approval round trip (incl. the win32 CR-resend loop) while staying short
+     * enough that a modal which auto-approve fired at but did NOT resolve re-surfaces to the
+     * coordinator on the next event. Aligned with the adapter's own approval cooldown scale.
+     */
+    private static readonly APPROVAL_LOCAL_RESOLUTION_COOLDOWN_MS = 8000;
+
     /**
      * Busy-side hysteresis for the settle gate. A momentary `generating` flip
      * while the SAME approval modal's button block is still on screen (its
@@ -387,6 +397,16 @@ export class CliProviderInstance implements ProviderInstance {
     // signature) while a genuinely closed modal — buttons empty continuously past
     // the continuity window — is still recognised and resets the gate.
     private autoApproveLastModalSeenAt = 0;
+    // APPROVAL-INBOX-BLINDSPOT (Fix A): wall-clock of the last time this session actually
+    // FIRED a local auto-approve resolveModal (the settle gate passed → resolveModal
+    // dispatched). The mesh event forwarder keys its agent:waiting_approval suppression on
+    // this + a cooldown so it only drops the coordinator notification when we can positively
+    // confirm the modal was (or is being) resolved LOCALLY. If auto-approve is merely
+    // *configured* on but has NOT recently fired for this modal, the raw waiting_approval is
+    // forwarded so a task_approval_needed ledger row is created and the coordinator/inbox is
+    // told — closing the blind spot where a never-resolving worker approval was silently
+    // dropped just because settings.autoApprove===true.
+    private lastAutoApproveFiredAt = 0;
     // AUTOAPPROVE-FLAP-INBOX-MISSING sticky-approval overlay (see APPROVAL_STICKY_FLAP_MS).
     // The wall-clock of the last frame where the RAW adapter reported waiting_approval with
     // a CONCRETE modal (buttons present), the cached modal to re-present across a busy blip,
@@ -1099,6 +1119,34 @@ export class CliProviderInstance implements ProviderInstance {
         return null;
     }
 
+    /**
+     * APPROVAL-INBOX-BLINDSPOT (Fix A): true when this session's approval modal was — or is
+     * being — resolved LOCALLY within the recent cooldown. Two independent positive signals:
+     *   (1) auto-approve fired its resolveModal within APPROVAL_LOCAL_RESOLUTION_COOLDOWN_MS
+     *       (lastAutoApproveFiredAt), or
+     *   (2) the underlying adapter reports isApprovalRecentlyResolved() — its own resolve
+     *       cooldown, which also covers a dashboard / mesh_approve resolution.
+     * The mesh event forwarder uses this to decide whether an agent:waiting_approval from an
+     * auto-approving worker can be safely SUPPRESSED (a local resolution is in flight) or must
+     * be FORWARDED (auto-approve is configured but has NOT actually resolved this modal, so the
+     * coordinator/inbox must be told). Keying suppression on real resolution — not just the
+     * autoApprove *intent* — is the blind-spot fix: a never-resolving worker approval is no
+     * longer silently dropped.
+     */
+    approvalRecentlyResolvedLocally(now = Date.now()): boolean {
+        if (this.lastAutoApproveFiredAt
+            && now - this.lastAutoApproveFiredAt < CliProviderInstance.APPROVAL_LOCAL_RESOLUTION_COOLDOWN_MS) {
+            return true;
+        }
+        try {
+            const adapter = this.adapter as { isApprovalRecentlyResolved?: () => boolean };
+            if (typeof adapter.isApprovalRecentlyResolved === 'function') {
+                return adapter.isApprovalRecentlyResolved() === true;
+            }
+        } catch { /* adapter gone / transient */ }
+        return false;
+    }
+
     /**
      * NOTIF-HELD-DRAIN: true when this `waiting_approval` is a routine, transient tool-consent
      * of an autonomously-progressing mesh session rather than a genuine human-await modal —
@@ -3139,8 +3187,34 @@ export class CliProviderInstance implements ProviderInstance {
             this.lastAutoApprovalSignature = '';
         }, 5000);
         this.recordAutoApproval(modal?.message, buttonLabel, now);
+        // APPROVAL-INBOX-BLINDSPOT (Fix A) + BUTTON-INDEX-MISMAP (Fix C): stamp the
+        // local-resolution clock so the mesh forwarder can distinguish "auto-approve just
+        // fired / is firing" (suppress the coordinator notification — modal is being resolved
+        // locally) from "auto-approve is merely configured but has not fired for this modal"
+        // (forward it so the coordinator is told and a task_approval_needed ledger row is
+        // created). Only stamp when the click actually MATCHED a button: resolveModalMatched
+        // maps the array position to the real FSM display index and reports whether a button
+        // was pressed, so a mis-mapped/never-pressed modal does NOT falsely mark itself
+        // locally-resolved (which would suppress the coordinator notification for a modal that
+        // never got answered — the exact blind spot). Legacy adapters keep the void resolveModal.
+        this.lastAutoApproveFiredAt = now;
         setTimeout(() => {
-            this.adapter.resolveModal(buttonIndex);
+            const adapter = this.adapter as {
+                resolveModalMatched?: (i: number) => boolean;
+                resolveModal?: (i: number) => void;
+            };
+            if (typeof adapter.resolveModalMatched === 'function') {
+                const matched = adapter.resolveModalMatched(buttonIndex);
+                if (!matched) {
+                    // Click did not land on any button — undo the local-resolution stamp so the
+                    // next agent:waiting_approval is FORWARDED to the coordinator/inbox rather
+                    // than suppressed as "resolved locally".
+                    if (this.lastAutoApproveFiredAt === now) this.lastAutoApproveFiredAt = 0;
+                    LOG.warn('CLI', `[${this.type}] auto-approve resolveModal matched no button (index ${buttonIndex}) — surfacing approval to coordinator`);
+                }
+            } else {
+                adapter.resolveModal?.(buttonIndex);
+            }
         }, 0);
         return autoApproveActive;
     }

package/src/providers/spec/cli-adapter.ts

@@ -204,8 +204,21 @@ export class SpecCliAdapter implements CliAdapter {
                 // modal this frame still stays waiting_approval (no activeModal yet).
                 // `kind` carries the semantic modal class through to the auto-approve
                 // gate so a /model picker (kind='picker') is never auto-answered.
+                // BUTTON-INDEX-MISMAP (Fix C.1): keep `buttons` as the label list every
+                // existing consumer (pickApprovalButton, mesh_approve, auto-approve) reads,
+                // but ALSO surface `buttonMeta` carrying each button's real FSM display index
+                // alongside its label. A partial/non-contiguous modal (display indices [1,3,4]
+                // at array positions [0,1,2]) then no longer loses the index → label mapping
+                // once it leaves the adapter: a consumer that has an array position can recover
+                // the true FSM index without re-parsing. resolveModal() below relies on the same
+                // ordered list to translate an array position to the correct FSM index.
                 activeModal: modal
-                    ? { message: modal.title ?? state.label, buttons: modal.buttons.map(b => b.label), kind: modal.kind ?? null }
+                    ? {
+                        message: modal.title ?? state.label,
+                        buttons: modal.buttons.map(b => b.label),
+                        buttonMeta: modal.buttons.map(b => ({ index: b.index, label: b.label })),
+                        kind: modal.kind ?? null,
+                    }
                     : null,
                 activeInteractivePrompt: this.activeInteractivePrompt,
                 ...sessionFields,
@@ -420,8 +433,29 @@ export class SpecCliAdapter implements CliAdapter {
     }
 
     resolveModal(buttonIndex: number): void {
-        // CliAdapter buttonIndex is 0-based; spec buttons are 1-based.
-        this.driver.dispatch({ kind: 'click_modal_button', index: buttonIndex + 1 });
+        this.resolveModalMatched(buttonIndex);
+    }
+
+    resolveModalMatched(buttonIndex: number): boolean {
+        // BUTTON-INDEX-MISMAP (Fix C): `buttonIndex` is an ARRAY POSITION into the
+        // label list this adapter surfaced via getStatus().activeModal.buttons (the
+        // same order pickApprovalButton / mesh_approve pick from). The FSM matches a
+        // click by the button's DISPLAYED number (evaluator sets button.index =
+        // Number(m[1])), which is NOT `arrayPos + 1` for a partial / non-contiguous
+        // modal — e.g. a "1. Yes / 3. Always / 4. No" set parses to display indices
+        // [1,3,4] at array positions [0,1,2]. Blindly sending `arrayPos + 1` then
+        // targets a non-existent display index (2) and handleClickModalButton finds
+        // no button → nothing is pressed. Look up the real FSM display index from the
+        // same ordered button list instead, and fall back to the legacy +1 only when
+        // no modal is captured (defensive; the driver's own guard rejects a miss).
+        const buttons = this.latestModal?.buttons ?? [];
+        const target = (buttonIndex >= 0 && buttonIndex < buttons.length)
+            ? buttons[buttonIndex].index
+            : buttonIndex + 1;
+        // clickModalButton returns whether the FSM actually found a button for `target`
+        // and dispatched its confirm keys — surfaced so mesh_approve can distinguish a
+        // real press from a silent miss (the exact false-success the mis-map produced).
+        return this.driver.clickModalButton(target);
     }
 
     async resolveAction(data: unknown): Promise<void> {

package/src/providers/spec/fsm-driver.ts

@@ -118,6 +118,13 @@ export interface ISpecDriver {
     subscribe(listener: (ev: DashboardEvent) => void): () => void;
     start(): void;
     dispatch(cmd: DashboardCommand): void;
+    /**
+     * BUTTON-INDEX-MISMAP (Fix C.3): click a modal button by its FSM display index and report
+     * whether a button was actually matched and its confirm keys dispatched. Unlike the
+     * fire-and-forget `dispatch('click_modal_button')`, callers that need to know the click
+     * landed (mesh_approve → SpecCliAdapter.resolveModalMatched) can observe a miss.
+     */
+    clickModalButton(index: number): boolean;
     updateMeta(meta: Record<string, unknown>, replace?: boolean): void;
     snapshot(): string;
     getCursorPosition(): { row: number; col: number };
@@ -428,7 +435,7 @@ export class FsmDriver implements ISpecDriver {
             case 'send_message': this.handleSendMessage(cmd.text); return;
             case 'pty_write': this.adapter.send_keys(cmd.data); return;
             case 'click_control': this.handleClickControl(cmd.control_id, cmd.payload); return;
-            case 'click_modal_button': this.handleClickModalButton(cmd.index); return;
+            case 'click_modal_button': this.clickModalButton(cmd.index); return;
             case 'attach_image': this.handleAttachImage(cmd.blob, cmd.mime); return;
             case 'resize': this.adapter.resize(cmd.cols, cmd.rows); return;
             case 'cancel': this.adapter.send_keys('\x03'); return;
@@ -1318,11 +1325,25 @@ export class FsmDriver implements ISpecDriver {
         }
     }
 
-    private handleClickModalButton(index: number): void {
+    /**
+     * BUTTON-INDEX-MISMAP (Fix C.3): public modal-click entry that returns whether a button
+     * matching the requested FSM display index was actually found and its confirm keys were
+     * dispatched. The old private handleClickModalButton silently `return`ed on a miss (no
+     * modal captured, or no button whose `.index` equals the requested display index), so a
+     * mis-mapped index looked identical to a successful press. Callers that need to know
+     * whether the click landed (mesh_approve → resolveModal) can now observe the miss instead
+     * of reporting success into the void. The generic `dispatch('click_modal_button')` path
+     * keeps ignoring the return (fire-and-forget UI clicks).
+     */
+    clickModalButton(index: number): boolean {
+        return this.handleClickModalButton(index);
+    }
+
+    private handleClickModalButton(index: number): boolean {
         const m = this.currentEval?.modal;
-        if (!m) return;
+        if (!m) return false;
         const btn = m.buttons.find(b => b.index === index);
-        if (!btn) return;
+        if (!btn) return false;
 
         const rule = stateById(this.spec, this.currentStateId)?.extract?.buttons;
         if (rule?.select_mode === 'arrow_keys') {
@@ -1343,9 +1364,10 @@ export class FsmDriver implements ISpecDriver {
             const confirm = (rule.key_for_index || '\r').replace(/\{index\}/g, '') || '\r';
             if (nav) this.adapter.send_keys(nav);
             this.submitModalConfirm(confirm);
-            return;
+            return true;
         }
         this.submitModalConfirm(btn.key);
+        return true;
     }
 
     /**