[BUG] MCP progress notifications are no longer displayed in the UI (regression)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/48005
2. https://github.com/anthropics/claude-code/issues/37123
3. https://github.com/anthropics/claude-code/issues/45839

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

these are similar ones, but the most important bit covered by this issue is that transient status isn't streamed anymore (MCP notification/progress APIs) for long-running tools, not just that the tool invocation itself is hidden.

Cross-SDK reproduction on 2.1.126

Independently confirming this regression with three separate MCP servers, all targeting the same Claude Code 2.1.126 client. The bar never renders in any of them.

1. TypeScript MCP SDK 1.29.0 (canonical pattern from docs/server.md)

const server = new McpServer(
  { name: 'progress-mcp-ts', version: '0.0.1' },
  { capabilities: { tools: {}, logging: {} } },
);

server.registerTool(
  'progress_demo',
  {
    description: 'Emit fake progress notifications to test the client UI.',
    inputSchema: {
      steps: z.number().int().min(1).max(1000).optional().default(10),
      delay_ms: z.number().int().min(0).max(60000).optional().default(200),
    },
  },
  async ({ steps, delay_ms }, ctx) => {
    const progressToken = ctx._meta?.progressToken;
    for (let i = 1; i <= steps; i++) {
      if (progressToken !== undefined) {
        await ctx.sendNotification({
          method: 'notifications/progress',
          params: { progressToken, progress: i, total: steps, message: `Step ${i}/${steps}` },
        });
      }
      if (i < steps) await new Promise((r) => setTimeout(r, delay_ms));
    }
    return { content: [{ type: 'text', text: JSON.stringify({ status: 'done', steps }) }] };
  },
);

Tested at 10×200 ms (2 s) and 30×500 ms (15 s). No bar. Brief flicker as the tool-call container opens, then collapses to the result with no progress UI in between.

2. rmcp 1.6.0 (Rust, canonical pattern)

#[tool(description = "Emit fake progress notifications to test the client UI")]
async fn progress_demo(
    &self,
    Parameters(args): Parameters<ProgressDemoArgs>,
    ctx: RequestContext<RoleServer>,
) -> Result<CallToolResult, ErrorData> {
    let steps = args.steps.unwrap_or(10).max(1);
    let delay_ms = args.delay_ms.unwrap_or(200);
    let token = ctx.meta.get_progress_token();
    for i in 1..=steps {
        if let Some(ref tok) = token {
            let params = ProgressNotificationParam::new(tok.clone(), i as f64)
                .with_total(steps as f64)
                .with_message(format!(\"Step {i}/{steps}\"));
            let _ = ctx.peer.notify_progress(params).await;
        }
        if i < steps {
            tokio::time::sleep(std::time::Duration::from_millis(delay_ms)).await;
        }
    }
    /* ... */
}

Same outcome. No bar.

3. Real-world MCP server (dolusoft/ssh-mcp)

ssh_upload emits await-ordered, throttled progress during SFTP transfers. Frame ordering is verified (notifications precede the response on the wire — confirmed with a stdin/stdout probe). No bar.

Common factor

Three different SDKs (TS, rmcp, custom rmcp wrapper). Three different transports of the same protocol. One identical outcome under Claude Code 2.1.126: no progress UI.

The only common factor is the Claude Code client. Server-side all three are MCP-spec compliant.

Worth noting alongside the UI regression

Active progress emission in 2.1.126 also triggers the stdio transport kill described in #47378 / #53617 — so on top of the missing UI, the next call to the server returns -32000 Connection closed. This makes it a double regression, not just a missing-render: opting into progress today actively breaks subsequent tool calls.

For consumers, the pragmatic move is to gate progress emission behind an opt-in flag until both #51713 and #47378 are resolved (we've done this in dolusoft/ssh-mcp via SSH_MCP_PROGRESS_ENABLED, default off).

Yes, output is absent. Especially hard when start mcp ssh. And I don't see anything. Very big bug.

Is this about stdout/stderr, inband json MCP status messages, inband json MCP progress messages, or all three? Just want to point out that an MCP server that's sending back json status and progress and that should work as well.

See:
https://modelcontextprotocol.io/specification/draft/basic/utilities/progress

Adding a third independently-verified repro on the Go SDK (github.com/modelcontextprotocol/go-sdk@v1.4.0), against Claude Code 2.1.147. Behavior matches @zahidzorbaz's TypeScript repro: req.Session.NotifyProgress(...) calls leave the binary correctly (verified via MCP Inspector and direct stdio capture), but Claude Code shows no inline progress text during the call, and --debug logs contain no trace of received progress notifications either.

To answer @tcfurrer's scoping question: this is specifically about in-band JSON MCP notifications/progress per the spec (https://modelcontextprotocol.io/specification/2025-06-18/basic/utilities/progress). The spec is unambiguous that "either side can send progress notifications" and that the message field "SHOULD provide relevant human readable progress information" — i.e. it exists specifically for client display.

Closing related issue #4157 with "use streaming tool responses instead" was incorrect — MCP has no streaming tool-response mechanism (a tools/call returns a single CallToolResult); notifications/progress is the protocol's only spec-compliant path for incremental updates during a long tool call.

Strongly +1 on the bug status and regression label. Also note related #55374 — server-side notifications/message is also silently dropped, which means the natural fallback (have the server emit log records instead) is also blocked in Claude Code today.

This issue was fixed as of version 2.1.153.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.