### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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

[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

Workaround ✓ Mentioned in description ↑

Activity 3 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

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" }
}

Fully quit Claude Desktop (confirm it's not left running in the system tray).
Relaunch Claude Desktop with a plain cold start, no session resume involved.
In PowerShell, run: Get-Process -Name "<mcp-server-name>" -ErrorAction SilentlyContinue
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 ↗

3 Comments

github-actions[bot] · 1 month ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

eidonnexus · 1 month ago

Thanks for the auto-check. This shares the same root symptom as #50422 and #36616 (Claude Desktop spawning duplicate MCP server processes on cold launch) — both closed as "invalid / not related to Claude Code" despite being well-documented Desktop-app bugs, not CLI bugs. #89745, filed 3 days ago and covering a related MCP process-management failure mode in Claude Desktop, was auto-closed by github-actions within hours with a generic "doesn't appear to be about Claude Code" message.

This report adds: Windows platform (both #50422/#36616 are macOS), matching ParentProcessId + identical command line confirmed via PowerShell/Get-CimInstance, and reproduction across two separate sessions with different claude.exe parent PIDs each time.

Given the pattern of automated closures on Claude Desktop bugs in this repo, I'd appreciate confirmation from a maintainer (not the auto-triage bot) on whether this is genuinely out of scope here. I was directed to this repo by Anthropic's own support chat (Fin) after describing this exact bug in full detail — if Desktop bugs belong elsewhere, a pointer to the correct channel would help future reporters avoid the same runaround.

viktorstockinger · 11 days ago

Same bug on Claude Desktop 2.19675.0.0 (Windows 11, MSIX/Store) — narrowed down: the first instance is "shut down", but its process tree is never terminated

Setup: a single local MCP extension (ant.dir.cursortouch.windows-mcp 0.7.2; manifest server.type: "python", command: "uv", args: ["--directory", "${__dirname}", "run", "windows-mcp"]). mcpServers in claude_desktop_config.json is empty, no other MCP server enabled. uv 0.11.6, Python 3.13.

Startup sequence (main.log, local time UTC+2):

03:34:21 Starting app
03:34:26 [LocalMcpServerManager] Connecting to Windows-MCP
03:34:26 [LocalMcpServerManager] Using MCP server command: C:\Users\<user>\.local\bin\uv.exe ...
03:34:26 MCP Server connection requested for: Windows-MCP
03:34:26 Launching MCP Server: Windows-MCP
03:34:26 MCP Server connection requested for: Windows-MCP
03:34:26 Launching MCP Server: Windows-MCP
03:34:26 Shutting down MCP Server: Windows-MCP
03:34:30 Checking if UtilityProcess should be used for extension Windows-MCP   <- relaunch
03:34:36 [localMcpBridge] ensureAllConfiguredConnected failed — announcing partial/empty set { error: 'Error: ensureAllConfiguredConnected timed out after 10000ms' }
03:34:37 [LocalMcpServerManager] Connected to Windows-MCP (18 tools)

mcp.log (UTC), first instance: Initializing server 01:34:26.347 → Server started and connected successfully .390 → Shutting down server... / Server transport closed (intentional shutdown) .954 — it never receives initialize. Second instance: Initializing server 01:34:30.979 → initialize → connected.

Same pattern ("Shutting down MCP Server" 4–5 s after "Starting app", then relaunch) on all 7 cold starts in my log since 2026-09-27.

Resulting process trees — both alive for the whole session, both parented by Claude.exe:

Claude.exe[22836]
├─ uv.exe[2916]  03:34:26   <- "shut down" instance, orphaned
│  └─ windows-mcp.exe[28080] 03:34:27 → python.exe (venv redirector)[9812] → python.exe (base Python313)[29416]
└─ uv.exe[33932] 03:34:30   <- active instance, serves all tool calls
   └─ windows-mcp.exe[28188] 03:34:31 → python.exe (venv redirector)[33732] → python.exe (base Python313)[5844]

Note that the orphan's windows-mcp.exe was created at 03:34:27, i.e. after the shutdown at 03:34:26.954 — uv kept launching the server after "shutdown".
(Two python.exe per tree is expected: the venv Scripts\python.exe is a redirector that starts the base interpreter as a child. Not part of the bug.)

The server itself shuts down correctly — tested outside Claude Desktop with the same command (uv --directory <ext> run --no-sync windows-mcp, stdio piped):

| Test | Result |
|---|---|
| close stdin 0.6 s after spawn (same timing as the orphan) | uv.exe exits within ~0.1 s, nothing left |
| close stdin after full startup | whole tree (uv, conhost, windows-mcp.exe, 2× python.exe) gone within 0.5 s |
| TerminateProcess on uv.exe only | conhost, windows-mcp.exe and both python.exe keep running |

So the "Shutting down" at 03:34:26 neither closed the first instance's stdin nor terminated its process tree. My guess (unverified): the two connection requested / Launching calls in the same tick race, the handle to the first child is lost/overwritten, and the shutdown acts on something else. Either way, on Windows the fix has to close stdin and/or kill the whole tree (job object / taskkill /T) — terminating only the direct child (uv.exe) is not enough.

Also inconsistent: mcp.log reports Server transport closed / Client transport closed for the active instance at 01:34:40, 3 s after initialize — yet that instance has handled every tool call since (43 tools/call so far). The transport state logged there does not reflect the real pipes/processes.

Impact: the orphan is not idle — its CPU time matches the active instance (~155 s each since startup), plus ~660 MB private commit (+42 MB for uv) and ~55 MB private working set. Orphans are cleaned up when Claude Desktop quits (job object), so they don't pile up across restarts, but every session runs with a duplicate server. Task Manager screenshot attached (two "Python (2)" groups).

Related: #53134 (same dual-manager startup, closed as not planned), #75574 (transport closed, previous generation never terminated; confirmed on Windows in the comments).