Claude.ai MCP servers auto-injected into Claude Code without opt-in — causes OOM crashes on resource-constrained systems

This keeps coming back after every login/re-auth. I have to patch tengu_claudeai_mcp_connectors back to false in .claude.json every single time, and it gets silently overwritten again on the next auth sync.

I'm running a file watcher as a workaround now. That's how bad this is - I need a background daemon to defend my CLI tool's configuration from itself 🤯

A few things that make this particularly frustrating:

• Claude Code has claude mcp add/remove for managing MCP servers. That's the correct, explicit CLI workflow. But there's no equivalent command to manage or disable the servers being injected from claude.ai. You give us a

proper tool, then bypass it.

• I now have duplicate MCPs. I configure my company MCP locally for my CLI workflow, and then claude.ai injects its own company MCP on top. Duplicate tools, wasted context tokens, confusion about which one is active.
• CLI and web are different environments with different needs. Figma, Miro, Stripe - these are desktop integrations that make sense in a browser. They're completely irrelevant in a terminal coding session and just add noise.
• There's no opt-out. No CLI flag, no config setting that persists. The only defence is patching a cached feature flag that the server keeps overwriting.

This is a developer tool. Silently injecting MCP servers that users didn't ask for, can't disable through any official mechanism, and that keep reappearing after every login - that's not a feature, it's a hostile UX pattern.

Please give us a persistent opt-out or, better yet, make this opt-in.

+1 on this. I have my own locally-configured MCP servers for Atlassian and Slack via .mcp.json, so the auto-injected "claude.ai" duplicates are unwanted. They show up in every new project and have to be manually disabled each time via /mcp.

Attempted to use deniedMcpServers in user settings to block them globally, but the serverName regex (^[a-zA-Z0-9_-]+$) rejects the "claude.ai" naming format (dots and spaces). Related: #23838.

Would appreciate either an opt-in toggle for the claude.ai MCP sync, or fixing deniedMcpServers to accept these server names so users can selectively block them.

+1 on needing a persistent opt-out for cloud MCP connector injection.

My use case: I have Hugging Face MCP enabled in claude.ai for research in the web UI chatbot. It works great there. But when I'm coding in Claude Code CLI, I don't need it — it just consumes context tokens and clutters the tool list. The two environments (web chatbot vs. local CLI) have fundamentally different needs, and the current behavior forces them to share the same MCP configuration with no separation.

I discovered the injected servers only after noticing Claude Code sessions engaging with Hugging Face tools I never configured locally. After investigating all local config files (~/.claude.json, .mcp.json, ~/.claude/settings.json) and finding nothing, I concluded they were being injected server-side. The official docs confirm this under "Use MCP servers from Claude.ai".

What I'd like to see (in order of preference):

1. "mcpConnectors": "disabled" setting in ~/.claude/settings.json — simple, persistent, doesn't affect claude.ai web UI. This was proposed in #22301 before it was closed as a duplicate of this issue.

1. Granular per-connector control — e.g., "disabledMcpConnectors": ["claude.ai Hugging Face"] in settings.json, persisting across sessions and projects. This would also resolve the duplicate server problem others have reported.

1. At minimum, make claude mcp remove work for cloud connectors, or add claude mcp disable --cloud <name> as a persistent toggle.

The current workarounds (/mcp per-session, feature flag hacking tengu_claudeai_mcp_connectors that gets overwritten on re-auth, SessionStart hooks) are all fragile and require ongoing maintenance. A first-class setting would resolve this cleanly.

Additional workaround for others landing here: you can force-disable all MCP servers (including cloud connectors) for a session with:

claude --strict-mcp-config --mcp-config '{}'

This is a nuclear option (kills local MCPs too), but useful when you need a clean coding session with zero MCP overhead.

Also noting that deniedMcpServers in managed settings can't block these servers because the serverName regex rejects the "claude.ai ..." naming format (#23838) — so even the enterprise tooling can't address this.

Another possible workaround might be to make a dedicated MCP config file and inject it with

claude --strict-mcp-config --mcp-config "$(cat ~/.claude-local-mcp.json)"

But that's a brutish workaround that shouldn't be necessary.

+1 on this. My use case is slightly different but related:

I need different authentication credentials for the same MCP server type across different Claude Code projects (different orgs/contexts), while still keeping the MCP server enabled for
claude.com web chats.

Current options are all bad:

• Keep global enabled + add project-scoped = duplicate tools (both appear)
• Disable globally = loses MCP in web chats
• The cachedGrowthBookFeatures hack = not per-project, and unreliable

What would solve this:

• Project-scoped servers should fully override/hide global servers with the same name (not coexist)
• Or: a per-project setting to ignore specific claude.ai MCP servers

The duplicate tools issue is the main friction - if local configs could shadow global ones cleanly, this would be a non-issue.

This bug was costing me an extra 75% ON MY USAGE! FIX IT ALREADY. Thanks to everyone on the thread who help workaround it.

Set this environment variable in your Claude Code settings:

```
// In ~/.claude/settings.json, add to the "env" object:
"env": {
"ENABLE_CLAUDEAI_MCP_SERVERS": "false"
}

  Or export it in your shell before launching Claude Code:
  `export ENABLE_CLAUDEAI_MCP_SERVERS=false`

Set this environment variable in your Claude Code settings:

That completely removes the claude.ai MCPs instead of just deactivating them. I think most users would like the cluade.ai MCP servers available for activation when needed, but deactivate by default.

Adding my experience here. I had no idea this was happening until I ran claude mcp list and saw three servers I never configured locally:

claude.ai Vercel: https://mcp.vercel.com - Connected
claude.ai Google Calendar: https://gcal.mcp.claude.com/mcp - Connected
claude.ai Gmail: https://gmail.mcp.claude.com/mcp - Connected

I set these up on claude.ai months ago for the web UI — never intended them for CLI use. A terminal tool silently establishing outbound HTTP connections to third-party services based on web dashboard config set in a completely different context violates the principle of least surprise.

What makes this worse:

• No local config to prevent the connections (only disallowedTools to muzzle usage after they're already connected and consuming context)
• settingSources: [] in the SDK doesn't block them either — confirmed via testing
• The only real kill switch is the web dashboard, which per other comments here has its own issues

This should require explicit local opt-in per environment, not silent auto-loading. Something like disableAccountMcp: true in settings.json, or at minimum a first-session prompt: "Your account has 3 MCP integrations. Enable in CLI? [y/N]"

https://claude.ai/settings/connectors

You probably have those added here. Just remove them

Warning to reporters and readers of this issue:

This issue has no assignee. Of the ~5,947 currently open issues in this repository, only ~96 have assignees. Unassigned issues are subject to automatic "stale" labeling and auto-closure after 14 days of inactivity via sweep.ts. The "stale" label cannot be removed by the issue creator, and new activity does not remove it. Additionally, the duplicate-detection bot creates circular chains of duplicate references, leading to further automatic closures. See #19267 and this comment for documentation of this behavior.

This means your privacy concern will likely be silently deleted from the record without being addressed.

If you believe that auto-installing OAuth connectors to your private email and calendar without consent is a privacy violation, you may want to pursue channels that cannot be auto-closed:

• Anthropic Privacy Team: privacy@anthropic.com
• Data Protection Officer: dpo@anthropic.com
• Formal Data Subject Access Request (DSAR): Email the above addresses citing your applicable privacy law (GDPR, CCPA, Israel's Protection of Privacy Law Amendment 13, etc.) requesting what data was collected and on what legal basis these connectors were installed without consent
• Regulatory complaint: If Anthropic does not respond adequately, file with your jurisdiction's data protection authority (EU: national supervisory authority; US/California: Attorney General; Israel: Privacy Protection Authority at gov.il; UK: ICO; Brazil: ANPD)

Anthropic's own privacy policy states: "You'll always be in control and can turn off these features in your account settings." Auto-installing connectors to private email via server-side feature flags, with no notification and no clean opt-out, contradicts this commitment.

You probably have those added here. Just remove them

This is incorrect. Disabling them in https://claude.ai/settings/connectors does NOT disable them or remove them from Claude Code. They still still be enabled because the local MCP settings are CACHED, so disabling connectors has ZERO effect.

Anthropic needs to set ENABLE_CLAUDEAI_MCP_SERVERS to false by default and stop angering their customers with this wasteful, sneaky behavior users did not ask for and did not expect

I noticed unsolicited MCP auth prompts for gmail.mcp.claude.com appearing in claude code without explicitly configuring them, which set off alarm bells in my head.

These should be opt-in, and not just because they might be wasting resources.

Took me about twenty minutes to find a way to disable the two MCP servers (the Gmail and Calendar MCPs) that showed up one day without my consent. /mcp only showed what they were but didn't let me disable them.

Instead, I found out you can type /plugin, tab to the Installed tab, and arrow all the way down to find the MCP servers and disable each using spacebar granularly (instead of the ENABLE_CLAUDEAI_MCP_SERVERS env var, which disables all of them at once).

But my gripe is that I never consented to enabling these third-party MCPs in the first place. Furthermore, once I found out, I had a hard time finding how to disable them. They weren't enabled on my claude.ai account in the first place, nor were they found in my settings.json. I ended up finding the line "tengu_claudeai_mcp_connectors": true under .claude.json which is a hidden config file.

The behavior of claude code automatically trying to auth with services I didn't set up myself bypasses user consent and is also plain annoying, as "claude.ai connectors need auth" warnings kept popping up in my sessions. Hey, at least it's failing loudly, so I could tell that they're trying to access these servers in the first place. I don't want to imagine what would happen if they just all connected silently and claude's attempts to read my third-party data just got buried underneath a whole wall of rapid tool calls you'd need ctrl+o and a sharp eye to find.

Adding another use case: I want these MCP servers available in the claude.ai web app but not in Claude Code CLI sessions, where they add noise and context bloat.

Tried adding disabledMcpServers to ~/.claude/settings.json with the server display names (e.g. "claude.ai Fathom", "claude.ai Slack", etc.) but it has no effect on OAuth-connected servers — only locally-configured ones seem to be affected by that setting.

A per-client toggle (web vs. CLI) or making disabledMcpServers work for OAuth servers (with documented name format) would solve this.

Another data point: this is not just cosmetic/noisy on my machine.

Environment:

• Claude Code 2.1.75 (also saw it on 2.1.74)
• macOS 26.3.1 on Apple Silicon

What I am seeing:

• In ~/.claude.json, the current project already has disabledMcpServers set to "claude.ai Gmail" and "claude.ai Google Calendar".
• Despite that, claude mcp list still shows both connectors in Claude Code as Needs authentication.
• claude mcp get/remove cannot target them by name, so they are still in a weird half-managed state.

More importantly, I am also seeing Claude Code occasionally drop straight back to the shell after a turn with the red footer showing 1 MCP server failed immediately beforehand. I cannot prove causality from logs yet, but in practice this feels correlated with unexpected session termination, not just an annoying status warning.

So from this setup: per-project disable state is already present, but the claude.ai Gmail/Calendar connectors still surface as failed, and the bug appears severe enough to coincide with sessions unexpectedly ending.

A Notification hook on start can detect and warn about duplicate MCP servers:

SETTINGS_FILES=(
    "$HOME/.claude/settings.json"
    ".claude/settings.json"
)
ALL_SERVERS=""
for f in "${SETTINGS_FILES[@]}"; do
    [ -f "$f" ] || continue
    SERVERS=$(jq -r '.mcpServers // {} | keys[]' "$f" 2>/dev/null)
    ALL_SERVERS+="$SERVERS
"
done
DUPES=$(echo "$ALL_SERVERS" | sort | uniq -d)
if [ -n "$DUPES" ]; then
    echo "⚠️ Duplicate MCP servers detected:" >&2
    echo "$DUPES" >&2
    echo "These may be auto-synced from claude.ai. Remove duplicates from ~/.claude/settings.json" >&2
fi
TOTAL=$(echo "$ALL_SERVERS" | grep -c .)
if [ "$TOTAL" -gt 5 ]; then
    echo "⚠️ $TOTAL MCP servers loaded — this may cause high memory usage" >&2
fi
exit 0

To proactively prevent OOM, add a memory monitor:

COUNTER="/tmp/cc-mcp-check"
COUNT=$(cat "$COUNTER" 2>/dev/null || echo 0)
COUNT=$((COUNT + 1))
echo "$COUNT" > "$COUNTER"
[ $((COUNT % 20)) -ne 0 ] && exit 0
FREE_MB=$(free -m 2>/dev/null | awk '/Mem:/ {print $7}')
if [ -n "$FREE_MB" ] && [ "$FREE_MB" -lt 1000 ]; then
    echo "🔴 LOW MEMORY: ${FREE_MB}MB free. Consider disabling unused MCP servers." >&2
fi
exit 0

Until there's an official opt-out for cloud-synced MCP servers, you can also remove them from the settings file on session start:

SETTINGS="$HOME/.claude/settings.json"
[ -f "$SETTINGS" ] || exit 0
jq '.mcpServers = (.mcpServers // {} | with_entries(select(.value.command != null or .value.url != null)))' "$SETTINGS" > "${SETTINGS}.tmp" && mv "${SETTINGS}.tmp" "$SETTINGS"
exit 0

Adding a use case: I run Claude Code across multiple project directories, each with different needs. I want each project to act as a sandbox where I explicitly allowlist which MCP servers are available — opening access case by case.

But cloud connectors get injected into every project uniformly, with no per-project control.

A proper allowedMcpServers or disabledMcpServers setting at project scope (in .claude/settings.json) would solve this cleanly.

For now, using ENABLE_CLAUDEAI_MCP_SERVERS=false as a workaround.

adding on, having MCP's injected in from the desktop app into a claude code session is really annoying, and chews up so many tokens for no reason. I added gmail, calendar and slack because i wanted the desktop app todo stuff, that added 10K tokens to every session i opened in claude code, which i never used.

need a real fix for this.

Endorsed. This eats away tokens like crazy. 60k tokens just for a "session init" per each new chat in claude code is insane.

+1 — adding a data point + a workaround that's a bit different from the SessionStart hook approach upthread.

Use case: two-tier default by path

• Inside /home/me/WORKSPACE/** → only Linear + Mixpanel enabled (team workflow)
• Everywhere else → all claude.ai MCPs off (context bloat + different trust boundary — cf. @sunir upthread)

What I tried

1. disabledMcpServers: [...] in ~/.claude/settings.json → schema validator rejects the field (not declared in settings schema)
2. deniedMcpServers: [{serverName: "claude.ai Linear"}] → regex ^[a-zA-Z0-9_-]+$ rejects dots/spaces so actual server names never match
3. SessionStart hook writing ~/.claude.json → fires after MCP connect — too late for current session
4. --strict-mcp-config --mcp-config <file> → doesn't affect claude.ai OAuth first-party servers
5. ENABLE_CLAUDEAI_MCP_SERVERS=false → too nuclear (per @nick-youngblut — removes instead of deactivating, losing per-project granularity)

Workaround: wrapper function that pre-populates state BEFORE claude runs

clauded() {
  local cfg=$HOME/.claude.json cwd=$PWD list
  case "$cwd" in
    /home/me/WORKSPACE|/home/me/WORKSPACE/*)
      list='["claude.ai Canva","claude.ai Figma","claude.ai Gmail","claude.ai Google Calendar","claude.ai Google Drive","claude.ai Microsoft 365"]' ;;
    *)
      list='["claude.ai Canva","claude.ai Figma","claude.ai Gmail","claude.ai Google Calendar","claude.ai Google Drive","claude.ai Linear","claude.ai Microsoft 365","claude.ai Mixpanel"]' ;;
  esac
  if [ -f "$cfg" ] && command -v jq >/dev/null; then
    local t; t=$(mktemp)
    jq --arg p "$cwd" --argjson l "$list" \
       '.projects //= {} | .projects[$p] //= {} | .projects[$p].disabledMcpServers = $l' \
       "$cfg" > "$t" && mv "$t" "$cfg" || rm -f "$t"
  fi
  claude "$@"
}

Works — but I'm mutating Claude Code's internal state file from bash, which shouldn't be my job. Also likely subject to @mattheworiordan's observation that tengu_claudeai_mcp_connectors gets silently reset on re-auth.

API proposal

A unified policy field, applied before MCP connections initialize:

{
  "mcpPolicy": {
    "default": "disabled",
    "overrides": [
      {
        "pathPattern": "/home/me/WORKSPACE/**",
        "enabled": ["claude.ai Linear", "claude.ai Mixpanel"]
      }
    ]
  }
}

Properties wanted:

• Works across all MCP sources uniformly (claude.ai OAuth, .mcp.json, plugin-provided) — not 5 overlapping fields
• Cascades by path prefix (no per-subproject config needed)
• Live /mcp changes still work but reset to policy on next session start
• Separate from existing allowedMcpServers / deniedMcpServers / disabledMcpjsonServers — doesn't collide with the existing enterprise surfaces

Current field surface is (as far as I can tell) 5 overlapping layers with inconsistent semantics:

| Field | Applies to | Scope | Takes OAuth names? |
|---|---|---|---|
| enabledMcpjsonServers / disabledMcpjsonServers | .mcp.json sourced | user/project | No |
| allowedMcpServers / deniedMcpServers | Enterprise policy | managed | No (regex blocks ./ ) |
| disabledMcpServers | Runtime state | per-abs-path in ~/.claude.json | Yes (but not in settings schema) |
| pluginConfigs.*.mcpServers | Plugin-provided | plugin | N/A |
| ENABLE_CLAUDEAI_MCP_SERVERS env | All claude.ai | global on/off | N/A |

It'd be great if one unified mechanism could replace the ad-hoc state file dance.

Happy to help test if this gets picked up.

I did create an additional - duplicate issue #57235. Sorry for that. I just closed it. But perhaps you'll find some additional information that help solving the problem!

I can reproduce this issue on Claude Code v2.1.133 (Linux, Ubuntu 24.04) with a Claude Pro subscription and API key auth.
Findings:

Normal startup: System tools: 2.9M tokens (1454%) — context is full before any user input
With --bare flag: System tools: 1.4k tokens (0.7%) — completely normal

What I ruled out:

No MCP servers configured (claude mcp list returns empty)
No active VS Code Extension connection (IDE lock directory empty)
All plugins moved to backup directory — 2.9M tokens persist
No credentials.json (logged out) — 2.9M tokens persist with API key
Without any auth (no API key, no OAuth) — 721 tokens (normal)

Key observation: The 2.9M tokens appear whenever any authentication is active (API key or OAuth), regardless of whether MCP servers, plugins, or VS Code are running. The --bare flag is the only workaround that produces a clean context.
The ENABLE_CLAUDEAI_MCP_SERVERS=false flag from #50062 does not resolve the issue in v2.1.133.
Environment:

Claude Code version: 2.1.133
Platform: Ubuntu 24.04 LTS, linux-x64
Model: claude-sonnet-4-6
Auth: Claude Pro OAuth + API key (both tested separ

Additional comment for Issue #20412:
After extensive debugging, I found that the root cause of the 2.9M token "System tools" bloat in my case is the sandbox block in .claude/settings.json.
Reproduction:

Start claude in any directory without a .claude/settings.json → System tools: ~13k tokens (normal)
Add a .claude/settings.json with "sandbox": { "enabled": true } → System tools: 2.9M tokens

Even a minimal sandbox config triggers the issue:
json{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true
}
}
What I ruled out:

Plugins (moved entire plugin directory to backup — 2.9M persists)
MCP servers (claude mcp list returns empty)
VS Code Extension (closed VS Code — 2.9M persists)
Project files (renamed .claude directory — drops to 13k)
credentials.json / OAuth login (API key only — same result)
ENABLE_CLAUDEAI_MCP_SERVERS=false flag — no effect

Workaround: Remove the sandbox block entirely from settings.json.
Environment:

Claude Code version: 2.1.133
Platform: Ubuntu 24.04 LTS, linux-x64
Model: claude-sonnet-4-6

TurboTax Connector suddenly started like an MCP today and attempted to prompt inject my subagent...

any update? hello??

export ENABLE_CLAUDEAI_MCP_SERVERS=false on your .bashrc or equivalent fixes this.

@cardoso-neto Unfortunately that disables everything, rather than just specific MCP servers.

Thank you all for the reports and workarounds here.

As of v2.1.182:

• "disableClaudeAiConnectors": true in .claude/settings.json (project, user, or managed-policy level) opts out before any connection is attempted. A project-level false cannot override a user- or policy-level true.
• deniedMcpServers accepts connector display names with spaces and dots (e.g., {"serverName": "claude.ai Slack"}) for per-connector denial. Match is exact and case-sensitive.

ENABLE_CLAUDEAI_MCP_SERVERS=0 and --safe-mode continue to work. Tool-search deferral is now on by default, so connector schemas aren't loaded into context until used.

The default is unchanged — connectors still load unless disabled. Closing as completed for the opt-out controls; please open a fresh issue for opt-in default, first-run consent, or per-project credentials.