claude-code - 💡(How to fix) Fix [BUG] Windows: MCP servers spawned twice at startup (directMcpHost + LocalMcpServerManager) [1 comments, 1 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Desktop

What's Wrong?

On Windows MSIX (Windows Store) Claude Desktop 1.4758.0, every MCP server configured in claude_desktop_config.json and every installed MCP extension is spawned twice at startup, with both instances remaining alive simultaneously. The duplication is caused by two internal managers initializing independently and not coordinating:

1. First wave (~T+5s after main start) — log lines from a first manager:

   [info] MCP Server connection requested for: <name>
   [info] Launching MCP Server: <name>

   Emitted in parallel for all configured MCPs. Spawns the first set of processes.

2. Second wave (~T+75s after main start) — log lines from LocalMcpServerManager:

   [info] [LocalMcpServerManager] Connecting to <name>
   [info] [LocalMcpServerManager] Using MCP server command: <path> with args and path: { ... }
   [info] [LocalMcpServerManager] Connected to <name> (N tools)

   Re-initializes the SAME MCPs sequentially, spawning a second process for each server without terminating the first wave's processes. No "stopping previous instance" log line appears between the two.

Both manager spawns have the Claude Desktop main process (Claude.exe from WindowsApps\Claude_1.4758.0.0_x64__pzs8sxrjxfjjc\app\) as direct parent — neither set of children is orphaned, both stay alive throughout the session.

Regression — when did this start?

grep over historical main1.log (~2 months of data):

Before 2 April 2026: zero occurrences of LocalMcpServerManager. After: it appears at every Claude Desktop startup, in addition to (not replacing) the first manager. The bug was therefore introduced around 2 April 2026 by whatever change added LocalMcpServerManager — possibly the same rollout linked to #42719 (closed 6 April).

What Should Happen?

Either:

• A single MCP manager should handle all MCP server spawns, OR
• The second manager should detect existing live instances spawned by the first manager and reuse them, OR
• The first manager's spawns should be properly terminated before the second wave starts.

Error Messages / Logs

Side-by-side excerpt from %APPDATA%\Claude\logs\main.log for one of 15 affected MCPs in my config (gleif). Same pattern reproduces for every MCP configured:

2026-04-25 04:40:19 [info] MCP Server connection requested for: gleif
2026-04-25 04:40:19 [info] Launching MCP Server: gleif
[... 75 second gap, no related log lines ...]
2026-04-25 04:41:31 [info] [LocalMcpServerManager] Connecting to gleif
2026-04-25 04:41:31 [info] [LocalMcpServerManager] Using MCP server command: C:\Users\<user>\go\bin\gleif-mcp-server.exe with args and path: { ... }
2026-04-25 04:41:31 [info] [LocalMcpServerManager] Connected to gleif (12 tools)

Concurrent process snapshot from Get-CimInstance Win32_Process:

gleif-mcp-server.exe   PID=12808   Started=2026-04-25T04:40:19   ParentPID=13664 (Claude Desktop main)
gleif-mcp-server.exe   PID=4612    Started=2026-04-25T04:41:31   ParentPID=13664 (Claude Desktop main)

Both alive simultaneously, both parented to main, no orphaned PIDs.

The duplication affects every kind of MCP server in my setup:

• Native binaries (direct child of main): gleif-mcp-server.exe, github-mcp-server.exe, nordic-registry-mcp-server.exe
• uvx-wrapped Python MCPs (direct child = uvx.exe): markitdown-mcp, mcp-server-fetch, mcp-server-odoo, playwright-mcp
• cmd.exe → npx wrapped Node MCPs (direct child = cmd.exe): chrome-devtools-mcp, firecrawl-mcp, shopify-mcp, task-master-ai, openbrand-mcp, mcp-remote (datagouv, openlegi-legifrance), @upstash/context7

Of 26 configured MCPs, 15 are duplicated at every startup (the others use UtilityProcess via Electron's built-in Node and don't appear to be affected — possibly because they go through a different code path).

Steps to Reproduce

1. Install Claude Desktop on Windows MSIX / Windows Store, version 1.4758.0
2. Configure 5+ MCP servers in %APPDATA%\Claude\claude_desktop_config.json and/or install several MCP extensions
3. Cold start Claude Desktop
4. Wait at least 90 seconds for both manager waves to complete
5. Open Task Manager → Details (or run Get-CimInstance Win32_Process -Filter "ParentProcessId=<main_pid>")
6. Observe: each configured MCP appears twice in the process list, both with the same parent (Claude Desktop main), spaced by ~75 seconds in CreationDate
7. Inspect %APPDATA%\Claude\logs\main.log — confirm the sequence above (Launching MCP Server: X at T+5s, then [LocalMcpServerManager] Connecting to X at T+~75s) for the same MCP, with no stop/cleanup log between the two

Impact

With 26 configured MCPs, fresh-start process count is 178 (matched via Get-CimInstance Win32_Process regex claude|node|python|uv|uvx|mcp|electron), of which approximately 50-60 are duplicate MCP server processes plus their wrapper chains (cmd.exe → uvx.exe → uv.exe → python.exe → mcp-binary.exe for Python, similar for Node). Memory footprint is ~6 GB at fresh start despite zero user interaction.

The first-wave processes appear to be dormant — LocalMcpServerManager (second wave) is the manager whose instances actually receive tool calls.

Workaround

Wrote a PowerShell script that:

1. Identifies the Claude Desktop main process and protects it (and any Cowork SDK sessions) from being killed
2. Lists direct children of the main process, groups them by inferred MCP identity (binary name, or first non-flag argument from cmd.exe / uvx.exe command lines)
3. For each group with ≥2 instances spaced by ≥30 seconds (the WAVE1/WAVE2 pattern), kills the earliest (the dormant first-wave instance from the historical manager). Windows cascade-kills wrapper children of each killed cmd.exe / uvx.exe.
4. Optionally registered as a Windows Scheduled Task triggered at logon (3 min delay) and every 10 minutes thereafter, executing silently with hidden window.

Result: −54 processes (180 → 126), −1072 MB RAM (−17.5%), zero functional impact — Claude Desktop stays responsive, all MCP tools continue to work via the second-wave instances. This empirically proves the first-wave processes are unused.

Script and details: happy to share if useful for the team.

Claude Code Version

N/A — this is Claude Desktop, not Claude Code CLI. Desktop version: 1.4758.0.0 (MSIX package Claude_pzs8sxrjxfjjc).

Platform

Windows MSIX (Windows Store)

Operating System

Windows 11 (Ryzen 5 3600X, 34 GB RAM, RTX 2060 Super)

Last Working Version

Any Claude Desktop version installed before 2 April 2026 (before LocalMcpServerManager was introduced).

Related Issues

• #33947 — MCP server and subagent processes not cleaned up on session end (macOS orphan focus, but same underlying area: missing MCP process lifecycle coordination)
• #32552 — LocalMcpServerManager doesn't reconnect after extension settings change (closed; same component, different lifecycle bug)
• #42719 — [Cowork] MCP extension tools unavailable on first message (closed 2026-04-06; LocalMcpServerManager rollout adjacent in time, possibly the same change set that introduced this duplication)
• #50339 — Claude Desktop ignores notifications/tools/list_changed in directMcpHost (open; same dual-pipeline architecture issue surface)