claude-code - 💡(How to fix) Fix Claude Desktop re-injects removed MCP connector into every Claude Code session

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…

Every time Claude Desktop launches a Claude Code session (whether starting a new conversation or resuming), it spawns claude.exe with an inline --mcp-config "{...}" flag containing a connector I removed from the UI several days ago (Brevo, via npx mcp-remote https://mcp.brevo.com/v1/brevo/mcp). The result is a Brevo OAuth consent tab opening in Chrome on every session start.

Root Cause

Every time Claude Desktop launches a Claude Code session (whether starting a new conversation or resuming), it spawns claude.exe with an inline --mcp-config "{...}" flag containing a connector I removed from the UI several days ago (Brevo, via npx mcp-remote https://mcp.brevo.com/v1/brevo/mcp). The result is a Brevo OAuth consent tab opening in Chrome on every session start.

Fix Action

Fix / Workaround

Workarounds attempted (none stick)

Currently the only reliable workaround appears to be a hosts file block (127.0.0.1 mcp.brevo.com), which is acceptable for one bad connector but does not scale.

RAW_BUFFERClick to expand / collapse

Environment

  • OS: Windows 11 (build 26200)
  • Claude Desktop: 1.8555.2.0 (MSIX, installed via Microsoft Store)
  • Claude Code CLI: 2.1.149
  • Cowork plugins enabled

Description

Every time Claude Desktop launches a Claude Code session (whether starting a new conversation or resuming), it spawns claude.exe with an inline --mcp-config "{...}" flag containing a connector I removed from the UI several days ago (Brevo, via npx mcp-remote https://mcp.brevo.com/v1/brevo/mcp). The result is a Brevo OAuth consent tab opening in Chrome on every session start.

What I've ruled out

  • Not visible in the UI. Brevo does not appear in Customize → Conectores (neither "Web" nor "Escritorio") and the connector directory search returns "No matches".
  • Not in claude.ai account. Not present in claude.ai/settings/connectors either.
  • Not in a Cowork plugin. The .mcp.json of each installed plugin under %APPDATA%\Claude\local-agent-mode-sessions\*\rpm\plugin_*\ declares Klaviyo for the email-marketing category. Brevo is only referenced in CONNECTORS.md documentation strings.
  • Not in any recently-modified file on disk. A grep for mcp.brevo.com across %APPDATA%\Claude\ and %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\ (excluding HTTP cache, logs, and session transcripts) modified in the last 48h returns nothing.

Smoking gun

  • Claude Desktop (Claude.exe) starts at T0.
  • ~/.claude.json mtime updates 6 seconds later with a fresh mcpServers.brevo block.
  • The spawned claude.exe (Claude Code CLI) inherits this via --mcp-config inline.

So the desktop app is rewriting ~/.claude.json from some local state on every launch, and that state still contains Brevo. The most likely store is the Electron LevelDB / IndexedDB under Local Storage\leveldb\ or IndexedDB\https_claude.ai_*\, but these files are exclusive-locked by the running app and cannot be inspected while it is running.

Workarounds attempted (none stick)

  1. claude mcp remove brevo -s user — removes the block from .claude.json, but the next desktop app startup rewrites it.
  2. Deleting OAuth cache under ~/.mcp-auth/mcp-remote-*/ — no effect on re-injection.
  3. Full restart of Claude Desktop (kill tray icon, relaunch) — Brevo block restored.
  4. Sign out + sign in from the app's account panel — Brevo block restored.

Hypothesis

The UI "Disconnect" action does not propagate to the local state that the desktop app uses to compose --mcp-config for Claude Code. A connector removed from the visible list still lives in some local persisted store.

What would help

  • Documented location of the connector state store, or a CLI command to purge a specific entry.
  • Confirmation whether this is a known issue and whether a fix is in progress.

Currently the only reliable workaround appears to be a hosts file block (127.0.0.1 mcp.brevo.com), which is acceptable for one bad connector but does not scale.

Related

Cross-posted as a comment in the r/ClaudeAI weekly bugs megathread: https://www.reddit.com/r/ClaudeAI/comments/1s7f72l/comment/onqzggt/

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 Claude Desktop re-injects removed MCP connector into every Claude Code session