CLI/TUI error output may not apply the same URL-redaction as the web client's OAuth timeout path

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

All / shared core

Inspector version

2.7.0 (git tag) — static code-review finding, not run locally

Node version

N/A — static code review, no live run performed

Operating system (and browser, for the web client)

N/A — static code review

Transport

Not applicable / never connected

MCP server under inspection

N/A — this is a static code-review finding against the 2.7.0 tag source (clients/cli/src/error-handler.ts, clients/tui), not a live reproduction against a running MCP server.

Steps to reproduce

Found via static review of the 2.7.0 tag source, not a live run.

1. core/auth/requestTimeout.ts and core/mcp/fetchTracking.ts define and use redactUrlQuery(...) to scrub the OAuth-timeout error's URL (and network-log entries) before they reach the web client's UI.
2. clients/cli/src/error-handler.ts's classifyError(error, context?: {url?: string}) (~lines 130-160) passes context?.url and the raw error.message straight into the JSON error envelope with no redaction call.
3. The top-level handleError(error) — wired via .catch(handleError) in clients/cli/src/index.ts — calls formatErrorOutput/classifyError with no context at all, relying solely on error.envelope?.url from an already-constructed CliExitCodeError.
4. A repo-wide grep of clients/cli and clients/tui for "redactUrlQuery" returns zero matches.
   No live CLI/TUI run was performed; this is based on reading the above files against the 2.7.0 tag.

Expected behavior

CLI/TUI error output redacts query-string secrets/tokens from any URL it prints or serializes, the same way the web client's OAuth-timeout path does via redactUrlQuery, so a URL containing an OAuth code/token/state param isn't echoed verbatim to a terminal, log file, or piped output.

Actual behavior

classifyError/formatErrorOutput/handleError in clients/cli/src/error-handler.ts build their JSON error envelope directly from context?.url and error.message with no call to redactUrlQuery anywhere in clients/cli or clients/tui, so a URL with sensitive query parameters (e.g. an OAuth authorization code or token in a redirect/callback URL) can be printed unredacted to the terminal or to any log capturing CLI/TUI output.

Suggested fix: reuse redactUrlQuery (already exported from core/mcp/fetchTracking.js) inside classifyError/formatErrorOutput before the URL is written into the error envelope, so CLI/TUI error output gets the same redaction guarantee the web client already has.

Logs, errors, or screenshots

No response

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).

Start by reading core/mcp/fetchTracking.js for redactUrlQuery, then trace classifyError, formatErrorOutput, and handleError in clients/cli/src/error-handler.ts and the .catch(handleError) wiring in clients/cli/src/index.ts. Check the clients/tui paths identified by the issue and confirm that CLI/TUI error output no longer exposes sensitive URL query parameters.