[Bug] Multiple Claude Code instances freeze on macOS due to file locking conflict

---

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/13268
2. https://github.com/anthropics/claude-code/issues/13280
3. https://github.com/anthropics/claude-code/issues/13219

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

Comment for GitHub Issue #13287

Experiencing Same Issue - Additional Evidence of IDE MCP Server Impact

I'm experiencing this exact issue on macOS 26.1.0 (Tahoe Developer Beta) with Claude Code v2.0.29, IDE MCP Server v2.0.60.

Timeline

• Before Dec 7, 2025 11:37 AM: Successfully ran up to 5 concurrent Claude Code sessions for 3 weeks with no issues
• Dec 7, 2025 11:39 AM: First occurrence of concurrent session failures
• Since 11:39 AM: 41% of sessions (24 out of 58) fail when running concurrently

Symptoms Matching This Issue

1. Sessions freeze/hang when running multiple instances simultaneously
2. Cannot run even 2 concurrent sessions (previously ran 5 successfully)
3. Sessions that were working fine suddenly stopped working on Dec 7

Additional Evidence: IDE MCP Server Message Routing Breakdown

I've done extensive debugging and found that the file locking issue causes a downstream effect on the IDE MCP server. When sessions are in this deadlocked state, the shared IDE MCP server starts routing JSONRPC responses to the wrong sessions:

From debug logs (~/.claude/debug/*.txt):

Session a0ab19cc-e994-4273-a347-00da16d4a6b0 (11:39 AM - BROKEN):

[DEBUG] MCP server "ide": Connection established with capabilities: {"hasTools":true,...}
[DEBUG] MCP server "ide": WS-IDE connection dropped after 32s uptime
[DEBUG] MCP server "ide": Connection error: Received a response for an unknown message ID: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"CLOSED_0_DIFF_TABS"}]}}
[DEBUG] MCP server "ide": WS-IDE connection dropped after 47s uptime
[DEBUG] MCP server "ide": Connection error: Received a response for an unknown message ID: {"jsonrpc":"2.0","id":3,"result":{"content":[{"type":"text","text":"[]"}]}}

Key finding: This session never made any IDE tool calls, yet received responses for message IDs 2 and 3. These responses came from a concurrent session (18ac6c4c, 11:37 AM) that WAS calling IDE tools (closeAllDiffTabs, getDiagnostics).

The response content proves it: "CLOSED_0_DIFF_TABS" matches the closeAllDiffTabs tool call from the earlier session.

Pattern Analysis

Working sessions (11:37 AM):

• 3 concurrent sessions
• 0 IDE errors
• All completed successfully

Broken sessions (11:39 AM onwards):

• IDE message ID collisions appear
• Sessions receive responses meant for other sessions
• Connections drop, sessions hang

Root Cause Theory

The file locking deadlock (as described in this issue) appears to cause:

1. Sessions to be in inconsistent states at the process level
2. The shared IDE MCP server cannot properly route responses to locked/deadlocked sessions
3. JSONRPC message IDs collide between sessions
4. Responses get delivered to wrong sessions
5. Sessions error with "unknown message ID" and hang

This suggests the file locking issue has wider impact than just freezing sessions—it's breaking inter-process communication between Claude Code and the IDE MCP server.

Environment

• macOS Version: 26.1.0 (Darwin 25.1.0) - Tahoe Developer Beta
• Claude Code: v2.0.29 (installed Oct 30)
• IDE MCP Server: Claude Code Cursor MCP v2.0.60
• Impact: Cannot run multiple concurrent sessions (previously worked for 3 weeks)

Proposed Fix Impact

If the file locking issue is resolved (as proposed in this issue), it should also fix:

• IDE MCP server message routing errors
• "Unknown message ID" errors
• Session hanging/freezing
• Cross-contamination of responses between sessions

Happy to provide full debug logs if useful for debugging.

---

Additional context: Initially thought this was a configuration issue and spent hours debugging MCP config files, but timeline analysis proved the config changes happened 2+ hours before the first failure, ruling them out as the cause.

+1 to this, opened a thread on reddit discussing this issue
https://www.reddit.com/r/ClaudeCode/comments/1pgtllc/can_no_longer_run_cc_in_parallel_in_vscode/

+1 this is a bit of a workflow killer

+1 started happening today for me too today with version 2.0.61. Happening with VSCode on Ubuntu 24.04.

Fixed!

An update to version 62 of Claude Code has solved all this

Wasn't solved for me on ver 62, also it happens on single instance too
edit: on mac

have the same problem on mac os on v62

Same issue on Ubuntu:
Version: 2.0.62
Model: Default Opus 4.5
IDE: Connected to VS Code extension version 2.0.62 (server version: 2.0.60)

When i open a second claude session the other one will just stop doing any work. you cant kill the current thing its thinking on with escape key.

Only 1 active claude cli session can be happening in vscode or the second one gets clipped by this bug.

Please make sure you update both the IDE extension and CC and restart the IDE fully.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Additional Report: 5+ Parallel Conversations Freeze

Environment:

• macOS (Darwin 25.1.0)
• VS Code Extension (not CLI)
• Been experiencing this for ~2 weeks

Reproduction:

1. Open 5+ Claude Code conversations in VS Code extension, all reviewing the same workspace
2. Work across them in parallel (common workflow for reviewing different aspects of a codebase)
3. After some time, multiple threads become unresponsive/stuck
4. Cmd+Shift+R (reload window) temporarily brings them back
5. Shortly after, they freeze again - it's like whack-a-mole

Compounding Issue - Lost Messages:
When conversations freeze, any message I sent to the frozen thread is lost after reload. The message was typed and sent, but the frozen process never persisted it. This means:

• I have to remember which threads I sent messages to
• Copy messages somewhere before reloading
• Re-paste them after reload

This makes the workflow significantly more painful than just the freeze itself.

Impact:
This is a workflow killer for anyone doing parallel code review or multi-threaded investigation work. The combination of freezes + lost messages means constant context-switching overhead and lost work.

Would love to see this prioritized - happy to provide logs or additional details if helpful.

this is a money saving bug for Anthropic, I suspect we wont get a fix any time soon.

2 months later... I'm still facing this bug while opening 2 Claude Code instances in 2 different folders on macOS.

Edit:
Sorry but I can't say what version I'm using as
❯ claude --version
is frozen ;-)

Title: [BUG] Multiple VSCode instances crash simultaneously when .claude.json is atomically rewritten

Description:

When two VSCode instances are open with different projects, both Claude Code processes crash simultaneously with exit code 1.

Root cause from logs:

One instance atomically writes .claude.json (rename from temp file), which kills all Claude Code processes across both VSCode windows:

2026-02-26T10:31:47.940Z [DEBUG] Renaming C:\Users\Alex\.claude.json.tmp.103136.1772101907938 to C:\Users\Alex\.claude.json
2026-02-26T10:31:47.941Z [DEBUG] File C:\Users\Alex\.claude.json written atomically
Within 1 second, all 4 channels die:

15:31:48.786 [error] Error from Claude (on channel o3k8bmlxb7): Error: Claude Code process exited with code 1
15:31:48.809 [error] Error from Claude (on channel kxipb90s20c): Error: Claude Code process exited with code 1
15:31:48.826 [error] Error from Claude (on channel 6tfl91yr4wu): Error: Claude Code process exited with code 1
15:31:48.836 [error] Error from Claude (on channel 9epk6inyqb): Error: Claude Code process exited with code 1
Environment:

Windows 10 Pro 10.0.19045
VSCode (latest)
Claude Code extension (latest)
Two separate VSCode windows, each with a different project
Related: #13287 (same root cause on macOS)

Additional evidence: recurring startup death clusters on macOS (v2.1.92 + v2.1.104)

Same pattern as OP, with better forensics. Documenting in case useful for root-cause work.

Environment: macOS 15.4 (Tahoe), CC v2.1.104, Ghostty + Terminal.app, ~35 sessions/day, 3 concurrent sessions typical.

Observations:

1. Recurring reason=other startup death clusters. Apr 12: 5 sessions died in 3 minutes. Apr 5: 9 sessions in 3 minutes (CC v2.1.92). Cross-version recurrence rules out a single-version regression.

1. Same NON-FATAL lock error as OP. Cannot acquire lock for 2.1.104 - held by PID 900. But: same lock error appears in sessions that survive 20s and 130s on the same day. The lock is not sufficient to cause the crash.

1. 314ms diagnostic blind spot. In the crashing session's debug log, the last healthy entry is at T+1.1s (ripgrep test PASSED), then 314ms later the session enters shutdown. Nothing logged in between. No fatal error, no signal, no exception. All MCP servers disconnect simultaneously (downstream symptom, not cause).

1. Session died before first user turn. No UserPromptSubmit in the debug log. No transcript file created. Terminal parent was still alive (verified via forensics hook).

1. Remote settings differential (untested hypothesis). The crashing session had fresh remote-settings fetch/save/apply during shutdown. Surviving sessions with the same lock error had 304/cached/no-change for remote settings.

Debug logs available (3 sessions: 1 crash + 2 survivors with same lock warning) if useful for the team's investigation.

Local workaround: Smart launcher that detects concurrent sessions and uses --strict-mcp-config with a minimal MCP config for secondary sessions, reducing startup surface.