[BUG] Claude Desktop v1.1.3541: Mass MCP server kills — utility processes terminated on second instance detection and growthbook account refresh

Description

Claude Desktop v1.1.3541 (Windows, MSIX) periodically kills ALL running MCP server utility processes simultaneously, causing every connected MCP server (20 in my setup — 14 from config, 6 from extensions) to disconnect at once. This happens multiple times per day and is the primary cause of widespread MCP instability.

Root Cause (from log analysis)

Two distinct triggers cause mass utility process termination:

Trigger 1: Second Instance Detection

When a second Claude Desktop instance starts (cause unclear — possibly auto-update check, deep link, taskbar re-click, or notification), the second instance detects it is not the main instance and kills all utility processes belonging to the main instance:

2026-02-19 17:50:46 [info] Starting app { ... version: '1.1.3541' }
2026-02-19 17:50:46 [info] Starting app { ... version: '1.1.3541' }   ← DUPLICATE
2026-02-19 17:50:47 [info] Not main instance, returning early from app ready
2026-02-19 17:50:54 [info] Closing utiltiy proccess: id=1
2026-02-19 17:50:54 [info] Killing utiltiy proccess: success=true id=1
2026-02-19 17:50:54 [info] Closing utiltiy proccess: id=0
2026-02-19 17:50:54 [info] Killing utiltiy proccess: success=true id=0
2026-02-19 17:50:54 [info] [EventLogging] Queuing event: desktop_mcp_unexpected_close  ← x12 events

In mcp.log, 12 servers die within 0.04 seconds:

2026-02-19T16:50:54.477Z [info] [powerbi-desktop] Server transport closed unexpectedly
2026-02-19T16:50:54.482Z [info] [Context7] Server transport closed unexpectedly
2026-02-19T16:50:54.485Z [info] [PDF Tools] Server transport closed unexpectedly
2026-02-19T16:50:54.489Z [info] [reference-mcp] Server transport closed unexpectedly
2026-02-19T16:50:54.495Z [info] [deepl] Server transport closed unexpectedly
2026-02-19T16:50:54.499Z [info] [tool-discovery] Server transport closed unexpectedly
2026-02-19T16:50:54.504Z [info] [desktop-commander] Server transport closed unexpectedly
2026-02-19T16:50:54.512Z [info] [zotero] Server transport closed unexpectedly
2026-02-19T16:50:54.518Z [info] [outlook] Server transport closed unexpectedly
2026-02-19T16:50:54.522Z [info] [perplexity] Server transport closed unexpectedly
2026-02-19T16:50:54.529Z [info] [memory] Server transport closed unexpectedly
... (plus more within the next few seconds as remaining servers notice the disconnect)

Trigger 2: Growthbook Account Change Refresh

A growthbook feature flag refresh on "account change" also triggers utility process kills — without the "Not main instance" message:

2026-02-19 20:00:56 [info] [growthbook] refreshing for account change
2026-02-19 20:00:57 [info] Closing utiltiy proccess: id=19
2026-02-19 20:00:57 [info] Killing utiltiy proccess: success=true id=19
2026-02-19 20:00:57 [info] [EventLogging] Queuing event: desktop_mcp_unexpected_close  ← x11 events
2026-02-19 20:00:59 [info] [growthbook] refreshing for account change   ← rapid retries follow
2026-02-19 20:01:00 [info] [growthbook] refreshing for account change
2026-02-19 20:01:01 [info] [growthbook] refreshing for account change

11 MCP servers killed simultaneously, followed by a growthbook retry storm.

Scale of Impact

On February 19 alone:

• 82 individual Server transport closed unexpectedly events in mcp.log
• 4 mass crash events (killing 4–12 servers each within milliseconds)
• ~12 rolling failure cycles where servers repeatedly crash after restart attempts
• 652 cumulative desktop_mcp_unexpected_close events in main.log since Feb 11

Historical: 10 occurrences of "Not main instance" since Feb 11, each followed by mass utility process kills. Additionally, 600+ "Killing utiltiy proccess" events total.

The Cascade Problem

After each mass crash:

1. All 20 servers attempt to restart simultaneously
2. Servers with their own startup issues (slow init, DNS timeouts, TLS, Docker containers) fail immediately
3. These servers enter crash-restart-crash loops
4. Result: near-continuous failure across most servers, compounding the mass crash with individual failures

Steps to Reproduce

1. Configure Claude Desktop with 10+ MCP servers (mix of custom config and DXT extensions)
2. Leave Claude Desktop running normally
3. Wait for any of these events:

• A second app instance is spawned (auto-update, taskbar click while running, deep link)
• A growthbook "account change" refresh fires

1. All MCP servers disconnect simultaneously within milliseconds
2. Check main.log for "Killing utiltiy proccess" entries
3. Check mcp.log for clustered "Server transport closed unexpectedly" entries

Expected Behavior

• Second instance detection should gracefully defer to the main instance without killing its utility processes
• Growthbook account refresh should NOT trigger utility process recycling
• MCP servers should survive app-internal state transitions

Actual Behavior

• Second instance kills ALL utility processes from the main instance
• Growthbook refresh kills ALL utility processes
• Every MCP server disconnects simultaneously, then auto-restarts into a chaotic state

Environment

• OS: Windows 11 Pro for Workstations 10.0.26220
• App Version: 1.1.3541 (MSIX, updated from 1.1.3363 on same day)
• CPU: Intel Core i7-1165G7
• RAM: 64GB
• MCP Server Count: 20 active (14 config + 6 extensions)
• Server types: Node.js, NPX, UVX, Python exe, Windows binary, WSL/Docker containers

Key Log Signatures to Search For

In main.log:

• Not main instance, returning early from app ready — precedes Trigger 1
• Killing utiltiy proccess (note: typo "utiltiy" and "proccess" is in the actual code)
• Closing utiltiy proccess — always paired with killing
• [growthbook] refreshing for account change — precedes Trigger 2

In mcp.log:

• Clusters of Server transport closed unexpectedly for 10+ servers within 1 second

Suggested Fix

The utility process cleanup logic in the second-instance / singleton check path needs to be scoped:

• Only kill utility processes owned by the exiting instance, not the main instance
• Growthbook refresh should not trigger any utility process lifecycle changes
• Consider adding graceful MCP server handoff between instances instead of hard-killing

Additional Notes

• The typos "utiltiy proccess" in the log messages (main.log) suggest this code path may not have been thoroughly tested
• The desktop_mcp_unexpected_close telemetry events are being sent — Anthropic should have server-side data showing the scale of this issue across all users
• This bug likely affects ALL Windows users with multiple MCP servers, not just high-count configurations