[FEATURE]: Render MCP progress notifications for running tool calls #57794

• I have verified this feature I'm about to request hasn't been suggested before.

Resurrecting #26328 (and its duplicates #24965, #28186, #14499), closed as "not planned" by the stale bot on 2026-08-18 with the note "If the issue is still relevant please open a new one." It is still relevant.

Current state (v2.1.2 and dev HEAD): the token half of those reports is fixed — callTool passes onprogress, the SDK injects a progressToken, and spec-compliant servers emit notifications/progress. But the handler is a no-op (packages/core/src/mcp/client.ts:349-360):

callTool: (input) =>
  request("call MCP tool", (signal) =>
    client.callTool(
      { name: input.name, arguments: input.args ?? {}, ... },
      // Requesting progress keeps long calls alive under the SDK's timeout; execution is the hard wall.
      { signal, timeout: execution, onprogress: () => {} },
    ),
  ).pipe(Effect.map(toCallToolResult)),

The SDK matches each incoming notifications/progress to the registered handler (_progressHandlers), calls the no-op, and the message evaporates. The TUI shows a static "running" line for the whole call.

The ask: render the latest progress message (and progress/total when present) for a running MCP tool call — the rendering proposal in #26328 is exactly right:

⚙ mcp_service [query=…] · Calculating embeddings [42/800]

A concrete case: I run an MCP server that executes Ansible playbooks against real infrastructure. A run takes minutes and emits progress per play and per task (TASK [Configure nginx] …). The user watches a static spinner the whole time, and the model has no mid-run channel either — it cannot tell a stuck run from a slow one. Every long-running MCP tool (migrations, embedding runs, batch operations) has this shape.

Scope: only the rendering is missing; the token, the handler registration, and the notification dispatch are all in place. The onprogress callback needs to forward into the tool-call state the TUI renders.

Aside, in case the intent was real: the comment on line 357 says the token keeps calls alive "under the SDK's timeout", but resetTimeoutOnProgress is never set, so the per-request timer doesn't actually reset on progress. Harmless today — execution is a 12-hour wall — but the comment overstates what the no-op does.