fix(tui): abort stall after post-tool and post-compact silence

Awaiting-response with a null stream is no longer a permanent stall exemption. Execution-watchdog-exempt tools stay bounded by stall timeout instead of pinning forever.

Verification: bun run check (7664 pass).

Author: TheGreatAxios

docs/ARCHITECTURE.md

@@ -419,7 +419,7 @@ tool call
 
 **Approval log** (`src/permission/approval-log.ts`, CL-5666): every consequential decision the gate makes — auto-mode allow/deny or an interactive prompt's allow-once/allow-with-scope/deny/timeout/abort — is appended as one JSONL record to `approvals.jsonl` in the session dir, carrying the classifier/auto-shell rule name that fired (the existing `auto-shell-policy.ts`/`classify.ts` rule names, plus a small closed set of additional fixed literals the log itself defines for decisions those modules don't otherwise name — `auto-allowed-tool`, `non-interactive`, `mega-chain` — never model- or user-authored text), whether the decision was `auto` or `interactive`, a shell chain's segment count, and queued/displayed/settled timestamps. `displayedAt` is set by `PermissionRequest.markDisplayed`, called from `gate-wire.ts`'s `open()` the moment a request actually reaches the overlay host — distinct from when it was raised, so the gap it exposes is the CL-5664 signal (a queued gate arming its timeout before the operator could see it). No command text, file content, path, credential, or other free text is ever recorded — only tool name, rule, mode, segment count, and timing; a sub-agent's free-text dispatch label is deliberately left out, even though it would enable a per-agent breakdown, because nothing constrains what a model puts in it. A hard size cap on the serialized line is defense in depth against a future field reintroducing free text. Writes are fire-and-forget and swallow their own errors; the log defaults to a no-op so nothing depends on it being wired. `scripts/approval-forensics.ts` aggregates across local sessions the same way `intervention-forensics.ts` does for stop/nudge events: per-tool counts by outcome and mode, duration/display-delay percentiles, mega-chain counts, and a duplicate-rate proxy (sessions that hit the same rule more than once).
 
-**Tool wall-clock budget vs. permission prompts.** Each tool `run()` is wrapped by an outer execution watchdog (`src/tui/tool-execution-watchdog.ts`). The watchdog arms when Settings set `tools.timeoutMs` / `tools.maxTimeoutMs`, when foreground `run_shell` has an effective timeout (120s default or per-call, plus 1000ms slack so this layer cannot beat shell-guard), or for `mcp__*` calls. Fleet wait tools are exempt, regardless of Settings: the generic per-tool budget never aborts a sub-agent run while the parent waits for it. That exemption is unconditional, not because the worker is otherwise bounded — there is no turn budget; `deadlineMs` is opt-in, and there is no no-progress or thrash stop. A stuck worker that never trips stall or deadline runs until the parent cancels it or, in eval mode, `--agent-timeout-ms` bounds it. `spawn_agent`, `wait_agents`, `ask_director`, `shell_collect`, and `run_shell` with `background: true` stay exempt. By default (`tools.waitForApproval`, Settings → Tools, **On**), an armed budget freezes while the operator is deciding on a permission prompt, so a late approve still runs the tool and the agent waits for the decision instead of timing out under the modal. When **Off**, the budget keeps ticking during the prompt; if it expires first the tool is skipped and the permission modal is dismissed via the budget AbortSignal (auto-deny with a timeout message). The TUI permission queue (`src/tui/gate-wire.ts`, backed by `src/permission/queue.ts`) attaches that signal so ghost prompts cannot outlive an already-aborted tool.
+**Tool wall-clock budget vs. permission prompts.** Each tool `run()` is wrapped by an outer execution watchdog (`src/tui/tool-execution-watchdog.ts`). The watchdog arms when Settings set `tools.timeoutMs` / `tools.maxTimeoutMs`, when foreground `run_shell` has an effective timeout (120s default or per-call, plus 1000ms slack so this layer cannot beat shell-guard), or for `mcp__*` calls. Fleet wait tools are exempt, regardless of Settings: the generic per-tool budget never aborts a sub-agent run while the parent waits for it. That exemption is unconditional, not because the worker is otherwise bounded — there is no turn budget; `deadlineMs` is opt-in, and there is no no-progress or thrash stop. A stuck worker that never trips stall or deadline still runs until the parent turn's stall budget fires, the operator cancels, or, in eval mode, `--agent-timeout-ms` bounds it. `spawn_agent`, `wait_agents`, `ask_director`, `shell_collect`, and `run_shell` with `background: true` stay exempt from the per-tool watchdog; `wait_agents`, `ask_director`, and `shell_collect` are still bounded by the TUI stall watchdog so an in-flight poll cannot pin the turn forever. By default (`tools.waitForApproval`, Settings → Tools, **On**), an armed budget freezes while the operator is deciding on a permission prompt, so a late approve still runs the tool and the agent waits for the decision instead of timing out under the modal. When **Off**, the budget keeps ticking during the prompt; if it expires first the tool is skipped and the permission modal is dismissed via the budget AbortSignal (auto-deny with a timeout message). The TUI permission queue (`src/tui/gate-wire.ts`, backed by `src/permission/queue.ts`) attaches that signal so ghost prompts cannot outlive an already-aborted tool.
 
 `mcp__*` tool calls are the exception to "arms only when Settings set it": they arm unconditionally with a 5-minute default (`DEFAULT_MCP_TOOL_TIMEOUT_MS`), overridable via `mcp.timeoutMs` and still capped by `tools.maxTimeoutMs` (CL-6895). Nothing else bounds an MCP call — the stall watchdog treats an in-flight tool as activity by design, so a wedged MCP server previously hung a tool call, and the turn, forever. On expiry the call returns a normal tool-error result ("MCP tool `<name>` timed out after `<n>`s — the server may be wedged; retry or continue without it"); the turn is never aborted. The MCP client itself (`src/mcp/client.ts`, wrapping `@modelcontextprotocol/sdk`) multiplexes concurrent requests over one connection by JSON-RPC message id with no serial queue or mutex in our code or in the vendored SDK's `Protocol.request()` — so concurrent calls to the same server are not expected to deadlock each other. Live forensics for CL-6895 showed multi-minute MCP calls that eventually completed successfully, consistent with a slow server response rather than a client-side deadlock.
 

docs/IMPLEMENTATION.md

@@ -286,7 +286,7 @@ Provider and model configuration lives in JSON settings files. The global file h
   }
   ```
 
-  - `timeoutMs` / `maxTimeoutMs` — outer execution watchdog around each tool `run()`. Unset leaves the generic watchdog unarmed; set these to arm it. `maxTimeoutMs` clamps non-shell tools when set and does not cap a longer requested `run_shell`. Foreground `run_shell` always arms at the effective shell timeout (120s default, `settings.shell.timeoutMs` override, or per-call) plus 1000ms slack. Fleet wait tools are exempt: a dispatched sub-agent is bounded by stall, opt-in `deadlineMs`, and operator cancel, not the generic per-tool budget. Background shell is exempt too: a `run_shell` with `background: true` arms nothing (only a per-call timeout bounds the process; there is no 120s default) and `shell_collect` never arms (a bounded poll over a process that outlives the turn).
+  - `timeoutMs` / `maxTimeoutMs` — outer execution watchdog around each tool `run()`. Unset leaves the generic watchdog unarmed; set these to arm it. `maxTimeoutMs` clamps non-shell tools when set and does not cap a longer requested `run_shell`. Foreground `run_shell` always arms at the effective shell timeout (120s default, `settings.shell.timeoutMs` override, or per-call) plus 1000ms slack. Fleet wait tools are exempt: a dispatched sub-agent is bounded by stall, opt-in `deadlineMs`, and operator cancel, not the generic per-tool budget. Background shell is exempt too: a `run_shell` with `background: true` arms nothing (only a per-call timeout bounds the process; there is no 120s default) and `shell_collect` never arms the per-tool watchdog (a bounded poll over a process that outlives the turn). An in-flight `shell_collect`, `wait_agents`, or `ask_director` is still bounded by the TUI stall watchdog so it cannot pin the turn forever.
   - `waitForApproval` (default **true** when unset) — freeze that budget while a permission prompt is open so a late approve still runs the tool. **Settings → Tools** toggles this live for the next tool call and persists it here. When **false**, the budget keeps ticking during the prompt; on expiry the tool is skipped and the modal is auto-dismissed. The freeze is bounded: after **30 minutes** with the prompt still unanswered the budget resumes ticking on its own, so a prompt that never becomes visible (overlay open, UI gone) cannot hang a tool run indefinitely.
 
   Optional `mcp` block bounds MCP tool calls (`mcp__*` names) specifically — unlike `tools.*`, this arms **unconditionally** even with no settings at all, defaulting to **5 minutes**, since a wedged MCP server otherwise hangs a call forever with nothing to bound it (CL-6895):

docs/TUI.md

@@ -201,13 +201,16 @@ threshold, so a resumed session with already-stale activity shows the settled
 glyph immediately rather than alarming about silence the operator missed, and
 a stall that breaks and re-arms bursts again.
 
-Auto-abort (`shouldAbortForStall`) is reserved for a stream that had already
-started producing tokens and then went dead mid-flight — not for a run that
-is merely _awaiting_ the model's next response (right after submit, or the
-instant a tool batch resolves and `awaitingResponse` flips back to true).
-That wait has no signal to tell "still coming" from "never coming" apart, so
-it is never auto-aborted no matter how long it runs; it still surfaces via
-the notice, keeping the operator in control of whether to give up on it.
+Auto-abort (`shouldAbortForStall`) fires when a live turn has been silent
+past `STALL_TIMEOUT_MS`. That includes a stream that started producing
+tokens and then went dead, a wait for the model's next response that never
+arrives (right after submit, after a tool batch resolves, or after compact
+continuation re-entry), and an in-flight poll the per-tool execution
+watchdog leaves unarmed (`shell_collect`, `wait_agents`, `ask_director`).
+Ordinary in-flight tools stay exempt here — they have their own execution
+budget — and an open operator gate still blocks the clock. The notice
+still arms first at `STALL_NOTICE_MS` and hands over to the abort at the
+budget so the two never speak at once.
 The notice is a live diagnosis, not a sticky banner: it comes down on the
 same paint as the activity that ends the silence, including when the turn
 settles before the next monitor tick.

src/tui/runtime-bridge.ts

@@ -1461,6 +1461,7 @@ export function attachSessionBridge(
     stallTimeoutMs,
     isProcessing: bag.turn.isProcessing,
     streamingType: bag.turn.streamingType,
+    currentToolName: bag.turn.currentToolName,
     activeToolCalls: bag.turn.activeToolCalls,
     stallNoticeMs,
     repeating: bag.turn.repeating,

src/tui/stall-watchdog.test.ts

@@ -13,9 +13,7 @@ import {
 } from "./stall-watchdog.js";
 
 describe("shouldAbortForStall", () => {
-  // Mid-stream hang: tokens already flowed, then everything went silent —
-  // the one shape auto-abort is willing to act on. The generic guards
-  // (status, threshold, exemptions) are exercised against this base.
+  // Mid-stream hang: tokens already flowed, then everything went silent.
   const base = {
     status: "running" as const,
     awaitingResponse: false,
@@ -24,6 +22,7 @@ describe("shouldAbortForStall", () => {
     stallTimeoutMs: STALL_TIMEOUT_MS,
     isProcessing: true,
     streamingType: "text" as const,
+    currentToolName: null,
     activeToolCalls: [],
   };
 
@@ -70,17 +69,23 @@ describe("shouldAbortForStall", () => {
   });
 
   test("long tool runs are not stalls", () => {
-    expect(shouldAbortForStall({ ...base, streamingType: "tool" })).toBe(false);
+    expect(
+      shouldAbortForStall({
+        ...base,
+        streamingType: "tool",
+        currentToolName: "bash",
+      }),
+    ).toBe(false);
   });
 });
 
-// The other shape silence can take: awaiting the model's next response, with
-// no tokens yet — set right after submit and again the instant the last
-// outstanding tool call resolves (`turnStateOnSubmit`, the `tool.done`
-// handler). A slow model produces exactly this state for as long as it takes
-// to reply, so it is never auto-aborted, however long the silence — only the
-// notice may surface. This is the regression coverage for CL-5640.
-describe("shouldAbortForStall — awaiting the model's next token is never auto-aborted", () => {
+// Awaiting the model's next response with no tokens yet — set right after
+// submit, after the last tool call resolves, and after compact continuation
+// re-entry (`turnStateOnSubmit`, `tool.done`, `beginSystemContinuation`).
+// Cadence still ticks and the notice still arms at STALL_NOTICE_MS; past
+// STALL_TIMEOUT_MS this shape auto-aborts so a continuation that never lands
+// cannot freeze the turn.
+describe("shouldAbortForStall — awaiting-response with a null stream eventually aborts", () => {
   const awaiting = {
     status: "running" as const,
     awaitingResponse: true,
@@ -89,25 +94,35 @@ describe("shouldAbortForStall — awaiting the model's next token is never auto-
     stallTimeoutMs: STALL_TIMEOUT_MS,
     isProcessing: true,
     streamingType: null,
+    currentToolName: null,
     activeToolCalls: [],
   };
 
-  test("does not abort a run merely awaiting a response, however long", () => {
-    expect(shouldAbortForStall(awaiting)).toBe(false);
+  test("aborts a run awaiting a response once the stall budget elapses", () => {
     expect(
-      shouldAbortForStall({ ...awaiting, nowMs: STALL_TIMEOUT_MS * 10 }),
+      shouldAbortForStall({ ...awaiting, nowMs: STALL_TIMEOUT_MS - 1 }),
     ).toBe(false);
+    expect(shouldAbortForStall(awaiting)).toBe(true);
+    expect(
+      shouldAbortForStall({ ...awaiting, nowMs: STALL_TIMEOUT_MS * 10 }),
+    ).toBe(true);
   });
 
   // Mirrors the tool.done handler: the last outstanding call just resolved,
-  // awaitingResponse flips true and streamingType resets to null, then the
-  // model itself takes a long-but-healthy while to start its next reply.
-  test("healthy post-tool-batch wait never auto-aborts", () => {
+  // awaitingResponse flips true and streamingType resets to null, then nothing
+  // else arrives.
+  test("post-tool-batch silence auto-aborts after the stall budget", () => {
     expect(shouldAbortForStall({ ...awaiting, activeToolCalls: [] })).toBe(
-      false,
+      true,
     );
   });
 
+  // Same turn shape as compact continuation: beginSystemContinuation calls
+  // turnStateOnSubmit, which is awaitingResponse + null streamingType.
+  test("post-compact continuation silence auto-aborts after the stall budget", () => {
+    expect(shouldAbortForStall(awaiting)).toBe(true);
+  });
+
   test("a parallel fan-out with sibling tools still running is not a stall", () => {
     expect(
       shouldAbortForStall({ ...awaiting, activeToolCalls: ["call-2"] }),
@@ -132,6 +147,37 @@ describe("shouldAbortForStall — awaiting the model's next token is never auto-
   });
 });
 
+describe("shouldAbortForStall — execution-watchdog-exempt tools do not pin forever", () => {
+  const collect = {
+    status: "running" as const,
+    awaitingResponse: false,
+    lastActivityAt: 0,
+    nowMs: STALL_TIMEOUT_MS,
+    stallTimeoutMs: STALL_TIMEOUT_MS,
+    isProcessing: true,
+    streamingType: "tool" as const,
+    currentToolName: "shell_collect",
+    activeToolCalls: ["collect-1"],
+  };
+
+  test("in-flight collect auto-aborts after the stall budget", () => {
+    expect(
+      shouldAbortForStall({ ...collect, nowMs: STALL_TIMEOUT_MS - 1 }),
+    ).toBe(false);
+    expect(shouldAbortForStall(collect)).toBe(true);
+  });
+
+  test("wait_agents is bounded by the same stall budget", () => {
+    expect(
+      shouldAbortForStall({
+        ...collect,
+        currentToolName: "wait_agents",
+        activeToolCalls: ["wait-1"],
+      }),
+    ).toBe(true);
+  });
+});
+
 describe("applyStallRecovery", () => {
   test("aborts then notifies with the default message", () => {
     const calls: string[] = [];
@@ -170,6 +216,7 @@ describe("shouldNoticeStall", () => {
     stallNoticeMs: STALL_NOTICE_MS,
     isProcessing: true,
     streamingType: null,
+    currentToolName: null,
     repeating: false,
     activeToolCalls: [],
   };
@@ -207,15 +254,12 @@ describe("shouldNoticeStall", () => {
     );
   });
 
-  test("a healthy wait for the model's next token keeps noticing rather than handing over to an abort", () => {
-    // Unlike the mid-stream case above, this shape never reaches "abort" —
-    // see the shouldAbortForStall describe block above — so the notice keeps
-    // surfacing indefinitely instead of going silent once the old timeout
-    // would have fired.
-    expect(shouldNoticeStall({ ...base, nowMs: STALL_TIMEOUT_MS })).toBe(true);
-    expect(shouldNoticeStall({ ...base, nowMs: STALL_TIMEOUT_MS * 10 })).toBe(
+  test("an awaiting-response wait hands over to abort at the stall budget", () => {
+    expect(shouldNoticeStall({ ...base, nowMs: STALL_TIMEOUT_MS })).toBe(false);
+    expect(shouldAbortForStall({ ...base, nowMs: STALL_TIMEOUT_MS })).toBe(
       true,
     );
+    expect(stallLevel({ ...base, nowMs: STALL_TIMEOUT_MS })).toBe("abort");
   });
 
   test("a long tool run is not stuck", () => {
@@ -224,9 +268,27 @@ describe("shouldNoticeStall", () => {
         ...base,
         awaitingResponse: false,
         streamingType: "tool",
+        currentToolName: "bash",
       }),
     ).toBe(false);
   });
+
+  test("in-flight collect notices, then aborts at the stall budget", () => {
+    const collect = {
+      ...base,
+      awaitingResponse: false,
+      streamingType: "tool" as const,
+      currentToolName: "shell_collect",
+      activeToolCalls: ["collect-1"],
+    };
+    expect(shouldNoticeStall(collect)).toBe(true);
+    expect(shouldNoticeStall({ ...collect, nowMs: STALL_TIMEOUT_MS })).toBe(
+      false,
+    );
+    expect(shouldAbortForStall({ ...collect, nowMs: STALL_TIMEOUT_MS })).toBe(
+      true,
+    );
+  });
 });
 
 describe("the stall level the indicator reads", () => {
@@ -239,6 +301,7 @@ describe("the stall level the indicator reads", () => {
     stallNoticeMs: STALL_NOTICE_MS,
     isProcessing: true,
     streamingType: null,
+    currentToolName: null,
     activeToolCalls: [],
     repeating: false,
   };
@@ -256,16 +319,10 @@ describe("the stall level the indicator reads", () => {
     expect(stallLevel({ ...midStream, nowMs: STALL_TIMEOUT_MS })).toBe("abort");
   });
 
-  // Awaiting the model's next token (right after submit, or right after a
-  // tool batch resolves) never escalates to "abort" — see
-  // shouldAbortForStall's dedicated describe block — so this shape stays at
-  // "notice" indefinitely instead of handing over.
-  test("a healthy wait for the model's next token stays at notice, never abort", () => {
+  test("an awaiting-response wait notices, then aborts at the stall budget", () => {
     expect(stallLevel({ ...base, nowMs: STALL_NOTICE_MS })).toBe("notice");
-    expect(stallLevel({ ...base, nowMs: STALL_TIMEOUT_MS })).toBe("notice");
-    expect(stallLevel({ ...base, nowMs: STALL_TIMEOUT_MS * 10 })).toBe(
-      "notice",
-    );
+    expect(stallLevel({ ...base, nowMs: STALL_TIMEOUT_MS })).toBe("abort");
+    expect(stallLevel({ ...base, nowMs: STALL_TIMEOUT_MS * 10 })).toBe("abort");
   });
 
   test("the indicator keeps reading stalled across the abort threshold", () => {