[BUG] Claude Desktop (Windows) spawns two identical instances of the same local MCP stdio server on every cold start

Status Open
Maintainer reply None cached
Activity 2 comments · opened Aug 29, 2026

Preflight Checklist

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

What's Wrong?

Claude Desktop on Windows launches two identical child processes of the same local MCP stdio server every time the app starts (a plain cold start, not on session resume). Both share the same parent process (claude.exe) and the exact same command line. This leaves the MCP communication channel in an inconsistent state: some tool calls succeed, others time out or fail with no clear pattern.

What Should Happen?

A single instance of the local MCP stdio server should be launched per Claude Desktop session on cold start, not two.

Error Messages/Logs

Get-Process -Name "thunderbird-mcp" -ErrorAction SilentlyContinue

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
     67       5      576       4268       0,00   5392   2 thunderbird-mcp
     67       5      576       4268       0,00  20668   2 thunderbird-mcp

Verified with Get-CimInstance Win32_Process that both processes share the same ParentProcessId (claude.exe) and the exact same command line: serve --toolsets mail,folders,search,admin --read-only

Steps to Reproduce

  1. Configure any local MCP stdio server in claude_desktop_config.json. Example used here:

"thunderbird": {
"command": "C:\\Users\\<user>\\AppData\\Local\\thunderbird-mcp\\venv\\Scripts\\thunderbird-mcp.exe",
"args": ["serve", "--toolsets", "mail,folders,search,admin", "--read-only"],
"env": { "PYTHONUTF8": "1", "PYTHONUNBUFFERED": "1" }
}

  1. Fully quit Claude Desktop (confirm it's not left running in the system tray).
  2. Relaunch Claude Desktop with a plain cold start, no session resume involved.
  3. In PowerShell, run: Get-Process -Name "<mcp-server-name>" -ErrorAction SilentlyContinue
  4. Observe two processes with the same command line and the same parent claude.exe.

Reproduced twice in separate sessions, immediately after killing any leftover process and doing a clean cold start, with different claude.exe PIDs as parent each time. Same exact pattern both times.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.40609.0.0 (Windows, MS Store)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This bug affects Claude Desktop specifically, not the Claude Code CLI/extension. Related issue #82407 describes a similar dual-spawn pattern for local MCP servers, but scoped to the VS Code extension and triggered by resuming a chat session — this report is a distinct trigger (a plain Desktop cold start, no resume). The shared symptom (two child processes racing for the same MCP server, only one correctly tracked by the client) suggests a common root cause in how Claude's client-side process management spawns and tracks local MCP server children.

Impact observed: intermittent tool call failures, diagnostic tools (connection status, log listing) failing inconsistently, cascading timeouts, and at least one crash of the server process from an IPC buffer overrun likely aggravated by two instances competing for the same stream.

Workaround: manually kill one of the two duplicate processes via PowerShell (Stop-Process -Id <PID> -Force) without restarting Claude Desktop, since restarting the app re-triggers the duplication.

This was surfaced while debugging an unrelated issue (unreliable email search via a Thunderbird MCP bridge) and isolated as the root cause after step-by-step diagnosis, including review of the MCP server's own logs via "View logs" in Claude Desktop's developer settings.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗