claude-code - 💡(How to fix) Fix [FEATURE] Per-banner "Don't show again" dismissal for MCP connection notifications

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Because there's no way to dismiss it, I see the same incorrect error every single session. Over time I've started ignoring all connection banners— which means the day GHL or GTM genuinely fails to attach, I'll miss it, because I've trained myself to tune the red banner out. A "Don't show this again" on the Garmin banner specifically would let me silence the one I've already verified as a false alarm, while still catching real failures from the other two servers.

Root Cause

I run three MCP servers in Claude Desktop: GHL (GoHighLevel), a GTM server, and Garmin Connect. Garmin authenticates at process start and works correctly— I can ask for last night's sleep or my training load and it returns data every time. But on every launch, Claude Desktop shows a red "Could not attach to MCP server Garmin Connect" banner anyway (the false-positive in #27492). The tool is fine; the banner is wrong. Because there's no way to dismiss it, I see the same incorrect error every single session. Over time I've started ignoring all connection banners— which means the day GHL or GTM genuinely fails to attach, I'll miss it, because I've trained myself to tune the red banner out. A "Don't show this again" on the Garmin banner specifically would let me silence the one I've already verified as a false alarm, while still catching real failures from the other two servers. That's the core value: dismissal isn't just about reducing annoyance, it preserves the signal of the banners that do matter.

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

When an MCP server fails to attach— or appears to fail but actually works (the known false-positive in #27492 and modelcontextprotocol/servers#2729)— Claude Desktop shows a red "Could not attach to MCP server X" banner on every launch and, in Cowork, on activity. For servers the user knows are fine (e.g. a Garmin MCP that returns data despite the banner), these are pure noise with no way to silence them.

Proposed Solution

Add a "Don't show this again" action to MCP connection banners— ideally per-server, so a user can acknowledge a specific known-noisy server while still seeing genuinely new failures from others. A persistent dismissal (remembered across restarts) would be sufficient; a per-server mute toggle in Settings → Connectors / Developer would be the fuller version. Why this is distinct from #27586 #27586 asks for better wording on the banners. This asks for user-controlled suppression of banners the user has already triaged. Both are needed: clearer messages for real failures, and a mute for known false-positives.

Alternative Solutions

No response

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

I run three MCP servers in Claude Desktop: GHL (GoHighLevel), a GTM server, and Garmin Connect. Garmin authenticates at process start and works correctly— I can ask for last night's sleep or my training load and it returns data every time. But on every launch, Claude Desktop shows a red "Could not attach to MCP server Garmin Connect" banner anyway (the false-positive in #27492). The tool is fine; the banner is wrong. Because there's no way to dismiss it, I see the same incorrect error every single session. Over time I've started ignoring all connection banners— which means the day GHL or GTM genuinely fails to attach, I'll miss it, because I've trained myself to tune the red banner out. A "Don't show this again" on the Garmin banner specifically would let me silence the one I've already verified as a false alarm, while still catching real failures from the other two servers. That's the core value: dismissal isn't just about reducing annoyance, it preserves the signal of the banners that do matter.

Additional Context

Environment Claude Desktop 1.9659.2 (390d6c), 2026-05-28 build. Windows 11 and macOS. Reproducible with any MCP server that hits the false-attach UI bug.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [FEATURE] Per-banner "Don't show again" dismissal for MCP connection notifications