claude-code - 💡(How to fix) Fix [BUG] Claude Desktop spawns duplicate MCP server instances on cold launch, causing concurrent-writer data loss [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 Code

What's Wrong?

Note: This is a Claude Desktop bug, not a Claude Code CLI bug. Filing here as the primary Anthropic public repository that accepts bug reports.

Related to #36800 (duplicate channel plugin spawn in Claude Code CLI) but distinct: that issue concerns Claude Code CLI spawning duplicate channel plugins mid-session. This report concerns Claude Desktop app spawning duplicate instances of regular MCP servers on cold launch. Different app, different trigger, possibly shared root cause in harness lifecycle management.

Summary

Claude Desktop spawns two instances of every configured MCP server during application startup, with approximately 2 minutes between first and second spawn. Both instances share the same parent Claude process and write to the same underlying files.

For MCP servers that maintain in-memory state or caches (memory persistence, session tracking, etc.), this creates a silent concurrent-writer race condition where stale caches from one instance can overwrite legitimate writes from the other. Reproduces deterministically across multiple cold launches on macOS.

Environment

• Claude Desktop (latest available as of April 2026)
• macOS (M1 and M4 Apple Silicon tested)
• Multiple MCP servers configured, all Node.js-based, all using local file persistence
• Custom MCP servers for persistent memory and agent coordination

Impact

Severity: Medium-to-High for stateful MCP servers.

For MCP servers maintaining in-memory state:

1. Both instances load state from disk at spawn
2. Both instances independently accept tool calls from the Claude app
3. Writes from one instance update disk but do not update the other instance's in-memory cache
4. Subsequent writes from the second instance flush its stale cache, silently overwriting the first instance's legitimate writes

Observed outcome: A custom memory-persistence MCP server lost approximately 15 newly-created topics and multiple glossary updates over the course of a single working session due to exactly this mechanism. Recovery required bypassing the MCP layer entirely and performing direct file edits to replay lost work.

For stateless MCP servers, impact is limited to duplicate resource usage. For any MCP server maintaining caches, session state, rate limits, authentication tokens, or any in-memory state — the duplicate-spawn condition can cause silent corruption or authentication thrashing.

What Should Happen?

One instance per configured MCP server, spawned once at application launch. No duplicate spawning, no shared-file race conditions, no silent data loss for stateful MCP servers.

If duplicate spawn is intentional for some reason (redundancy, failover), this should be documented, and single-writer coordination between instances should prevent concurrent-writer races.

Error Messages/Logs

Steps to Reproduce

Reproduction Steps

1. Cold-launch Claude Desktop with multiple MCP servers configured
2. Wait approximately 3 minutes after app launch
3. Check process list with ps aux | grep -E "mcp|node" or equivalent
4. Observe two instances of every configured MCP server under the same parent Claude process

Actual Behavior

Two instances of every configured MCP server. First spawn at T+0 seconds (approximately), second spawn at T+2 minutes. Both children of the same Claude main process.

Evidence — Post-Reboot Diagnostic

Process list sample after a fresh cold launch:

MCP Server          First spawn (T+0)    Second spawn (T+~2min)
wilson-with-memory  PID 1457/1461        PID 5018/5019
time-server         PID 1455/1462        PID 5016/5017
[Additional MCP servers] — all show 2 instances each

All duplicate spawns share the same parent Claude process ID.

Reproduced across three independent cold launches during testing. Same pattern each time. Not affected by process cleanup, machine restart, or MCP server configuration changes.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

N/A — Claude Desktop app, not Claude Code CLI (see description). Latest available version as of April 2026.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workaround

For stateful MCP servers, the only reliable workaround is avoiding MCP tool calls during long sessions:

1. Cold-launch the Claude app before starting any session
2. Identify and kill duplicate MCP server processes manually via process list
3. Route persistent-memory writes through direct file edits rather than through the MCP layer
4. Keep sessions shorter than ~2 hours where feasible, or budget explicit "MCP freeze" discipline for longer sessions

None of these workarounds are practical for typical users; they require manual process management and awareness of the underlying issue.

Root Cause Hypothesis (Not Verified)

The 2-minute gap between first and second spawn, and the fact that both spawns come from the same parent Claude process, suggests that Claude Desktop's MCP lifecycle management may be registering MCP servers through two distinct code paths during startup — possibly one for initial configuration load and one for post-initialization or feature-ready events. If both paths trigger a fresh spawn rather than reusing the first-spawned instance, duplicate children would result.

This hypothesis aligns with the pattern described in #36800 (duplicate spawn with no apparent trigger, harness-level behavior). Source-level analysis would be required to confirm.

Impact Context

This bug is easy to miss because:

• Duplicate spawns are invisible unless users check process lists
• Stateless MCP servers exhibit no user-visible symptoms
• Data loss for stateful MCP servers is silent (no error, no warning)
• Users may attribute lost data to their own errors rather than a framework-level race condition

As MCP adoption grows and more developers build stateful MCP servers (memory systems, session persistence, user-scoped data stores), the blast radius of this bug will grow. Fixing it now benefits the broader MCP ecosystem.