MCP: Claude Code on Windows runs Claude Desktop's stdio servers (undocumented); no opt-out, and name collisions are ambiguous

Summary

On Windows, Claude Code appears to launch MCP servers defined in Claude Desktop's claude_desktop_config.json in addition to Claude Code's own configured servers. This isn't documented, there's no documented way to disable it, and when the same server name is configured differently in each app, resolution is ambiguous.

Environment

• Claude Code CLI ~2.1.x on Windows 11
• Claude Desktop installed on the same machine

Observed behavior

• A server example-mcp is configured in Claude Code (~/.claude.json, user scope) as an SSE server (a remote gateway).
• The same name is configured in Claude Desktop (claude_desktop_config.json) as a stdio server (python -m ...).
• claude mcp get example-mcp and claude mcp list show only the SSE definition, "Connected".
• Yet the running Claude Code process spawns the Desktop stdio server (python -m ... as a child of claude.exe), and tool calls are served by that stdio server, not the SSE one.

Why it matters

The two transports are not interchangeable. The SSE server executes on the remote gateway (no local secret); the stdio server runs locally and reads a local API key. When that shared key was rotated, the SSE path kept working but the inherited stdio path returned 401 on every call — an invisible failure, because every surface-level signal ("connector present / Connected") stayed green while the actual tool calls failed. It cost a small team a multi-hour outage before the inherited-stdio path was identified as the culprit.

Questions / requests

1. Does Claude Code on Windows intentionally load MCP servers from Claude Desktop's config? (claude mcp import-from-desktop is documented as macOS/WSL-only and explicit; this behavior appears automatic on Windows.)
2. Is there a supported way to disable it so Claude Code uses only its own configured servers? Name-based filters (deniedMcpServers) don't help when both definitions share a name — they'd disable the wanted SSE one too.
3. When the same server name is defined in both configs with different transports, which wins, and can that be made deterministic/configurable?

At minimum this should be documented; ideally there's a setting to opt out, plus a defined precedence for name collisions. A distinct "connected but the tool call errors" signal (vs. "connected") would also have surfaced this immediately.