CLI --load: Ctrl+C / SIGTERM discards the whole run — no partial summary, exit 130 #2834

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

CLI

Inspector version

2.13.0 (v2/main @ d7f6cee, built from source)

Node version

v22.23.4

Operating system (and browser, for the web client)

Linux (Debian)

Transport

Streamable HTTP

MCP server under inspection

A small instrumented Streamable HTTP server built on the repo's own createTestServerHttp (test-servers), exposing:

• sleep {ms} — waits ms, returns ok
• flaky {ms, failEvery, mode} — every failEvery-th call fails instantly (mode: "tool" → isError: true), the rest wait ms and succeed
• unique {ms} — waits ms, then throws

It also records server-side arrivals, in-flight count and arrival rate, so the CLI summary could be checked against ground truth. Happy to share the ~100-line script.

Steps to reproduce

1. Start a long run: mcp-inspector --cli http://127.0.0.1:7400/mcp --transport http --method tools/call --tool-name sleep --tool-arg ms=10 --load --load-duration 20 --format json
2. After ~3 s press Ctrl+C (or kill -INT <pid>; a CI job timeout sends SIGTERM).

Expected behavior

The run stops starting calls, lets (or cancels) in-flight calls, prints the summary of what completed — marked e.g. "interrupted": true — and then exits 130. A second Ctrl+C exits immediately.

Actual behavior

stdout and stderr are both empty (0 bytes); exit code 130. Every number from the run is lost — which is exactly when you want them (you stopped it because the server was struggling, or CI hit its timeout).

Cause: the CLI calls runToolLoad(...) with no signal (clients/cli/src/cli.ts, the if (load) branch), so nothing turns SIGINT/SIGTERM into an early end. The engine already supports signal — mcpdo passes one — but mcpdo documents that it prints no summary on Ctrl-C either.

Logs, errors, or screenshots

Related nit (same area): --load-connections 3 --load-concurrency 2 returns envelope code error from the CLI but load_flag_conflict from mcpdo for the same mistake (both exit 1). Using load_flag_conflict in both would let scripts branch on one code.

Already prototyped a fix?

No response

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).