Allow hiding/removing unused cloud connectors (Gmail, Google Calendar, etc.)

[tarekbadrsh]

Description

Cloud connectors (Gmail, Google Calendar, Google Drive) appear as MCP servers in Claude Code even when they are not connected and not needed. They show up with "Needs authentication" status and there is no way to hide or remove them.

Example:

claude.ai Gmail: https://gmail.mcp.claude.com/mcp - ! Needs authentication
claude.ai Google Calendar: https://gcal.mcp.claude.com/mcp - ! Needs authentication

Problem

• These are built-in platform connectors that cannot be removed via CLI (claude mcp remove) or local settings
• Users who don't use these services have no way to declutter their MCP server list
• They add noise to the tool/MCP server listing

Requested Feature

Provide an option to hide or disable unused cloud connectors, either:

• Via claude mcp remove CLI command
• Via a setting in settings.json (e.g., blockedMcpServers or similar)
• Via the claude.ai Connectors UI (a "Hide" or "Remove" option for unconnected connectors)

Environment

• Claude Code CLI
• macOS

[github-actions]

Found 3 possible duplicate issues:

1. Add setting to disable cloud MCP connectors from claude.ai #22301
2. Allow disabling claude.ai MCP connectors per-client (Claude Code vs Chat) #26625
3. Claude.ai MCP servers auto-injected into Claude Code without opt-in — causes OOM crashes on resource-constrained systems #20412

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

[chenwei791129]

You can disable the claude.ai cloud connectors (Gmail, Google Calendar, etc.) by setting the ENABLE_CLAUDEAI_MCP_SERVERS environment variable to false.

Add this to your ~/.claude/settings.json:

{
  "env": {
    "ENABLE_CLAUDEAI_MCP_SERVERS": "false"
  }
}

Reference: https://code.claude.com/docs/en/mcp#use-mcp-servers-from-claude-ai

[ch4zm]

Why doesn't Anthropic simply set this ENABLE_CLAUDEAI_MCP_SERVERS option to false by default? Are they stupid?

[cruppertautomation-ai]

Well, their child kind of thinks so, but phrased it a bit nicer, here is full picture:

Claude Code: Disabling MCP Servers Is Not Persisted

GitHub Issues: - #11085 — Persistent MCP enable/disable (open since 2025-11-05, 17 comments) - #20412 — Cloud servers auto-injected without opt-in (open since 2026-01-23, 24 comments, 100+ upvotes) - #29368 — Can't hide unused cloud connectors (open since 2026-02-27) - #31249 — Per-server granularity for ENABLE_CLAUDEAI_MCP_SERVERS (open since 2026-03-05)

The Bug

When you disable a claude.ai-synced MCP server (Gmail, Google Calendar) via the /mcp menu in Claude Code, the disable is session-only. On the next session, the servers reappear, fail authentication, and show as failed on shutdown. There is no way to persistently disable individual cloud-synced servers.

Symptoms

Three MCP servers show as failed every time you close Claude Code
Two are claude.ai Gmail and claude.ai Google Calendar (authentication_error — no OAuth token configured)
Third is tailwindcss-docs (stderr output about callback port logged as ERROR — false positive)
Disabling via /mcp has no effect on next session
Root Cause

Claude.ai-synced MCP servers are re-fetched from the cloud on every session start. Any local disable state is overwritten. The ENABLE_CLAUDEAI_MCP_SERVERS env var only supports true/false globally — no per-server control.

Workaround Applied

Set ENABLE_CLAUDEAI_MCP_SERVERS=false in both account settings files (~/.claude-private/settings.json and ~/.claude-neo/settings.json). This disables ALL claude.ai-synced servers, not just Gmail and Calendar.

Judgment

How easy to fix: Trivial. The internal disabledMcpServers mechanism already exists for local servers. Extending it to respect cloud-synced servers is a small change — probably a single conditional check during the sync step. Adding per-server granularity to ENABLE_CLAUDEAI_MCP_SERVERS (e.g., denylist syntax) is equally straightforward.

How old: The core request for persistent MCP enable/disable is from November 2025 — over four months. The cloud-sync auto-injection complaint is from January 2026 — almost two months. Both are well-established issues with significant community engagement.

Should this be addressed: Yes. This is a basic UX expectation — disable means persist the setting. A disable button that resets every session is misleading and wastes user time. The fix is small, the demand is clear (100+ upvotes on #20412), and the workaround (nuclear kill of all cloud servers) is crude. Four months without a fix for what amounts to a one-line change is hard to justify.