claude-code - 💡(How to fix) Fix Security · `claude mcp add` echoes Authorization Bearer token to stdout — enables credential leak via paste-back verification

Summary

`claude mcp add --transport http <name> <url> -H "Authorization:Bearer $TOKEN"` prints the literal header value to stdout when confirming the save. Users following standard verification flows (paste terminal output to AI assistant · share with teammate · paste into bug report) inadvertently leak their credentials.

Repro

```bash claude mcp add --transport http example-mcp https://example.com \ -H "Authorization:Bearer eyJEXAMPLE_38_CHAR_TOKEN_PLACEHOLDER" ```

Actual output:

``` Added HTTP MCP server example-mcp with URL: https://example.com to local config Headers: { "Authorization": "Bearer eyJEXAMPLE_38_CHAR_TOKEN_PLACEHOLDER" } File modified: /Users/<user>/.claude.json ```

The literal Bearer token appears in stdout · captured by any tool watching the terminal session and persisted in shell scrollback.

Impact

• Standard verification UX is "paste output into chat/issue to confirm" — that leaks the token
• Token cannot be redacted from logs · forces full rotation flow
• Silent leak — most users do not realize the echo happened (it looks like a normal confirmation)
• Related to #18692 (closed) and #28942 (open) but distinct · those are about config-file content / env var resolution · this is about terminal stdout echo on success

Proposed fix · any one closes the leak class

1. Mask header values by default · `"Authorization": "Bearer ****"` or `"Bearer ****<last4>"` — matches AWS CLI which masks access keys in `aws configure` confirmations
2. Be silent on success · require `--verbose` flag for full echo
3. Add `--no-echo-headers` flag · opt-in suppression for users who know to ask

Option 1 (mask by default) is least disruptive · matches existing prior art.

Workaround for now

```bash claude mcp add ... -H "Authorization:Bearer $TOKEN" >/dev/null 2>&1 ```

But this requires every user to know the leak risk in advance. Default-safe behavior is the right answer.

Provenance

Caught 2026-05-20 during a routine MCP install for the Smartsheet MCP server · forced a full Smartsheet API token rotation. Documented this on our side as a recurring credential-leak axis (third incident in same day across different leak shapes).