Claude won't reconnect with iMCP server following re-start

[wbiggers]

MacBook Pro, 14-inch, Nov 2024
Chip: Apple M4 Pro
Memory: 24 GB
MacOS: 26.5.1 (25F80)

Issue: Anthropic issues lots of Claude Desktop App updates. Every time one is issues, there is a message on the bottom left saying "reboot Claude to install the latest update" (or something to that effect. When I click that, Claude Desktop shuts down and reboots. I get a message that states something about claude desktop being unable to attach to iMCP server.

Notes: Chasing this down with Claude to help:
This log tells a clear story. Here is what it shows, extracted directly from the log:
What is working correctly:
The path /Applications/iMCP.app/Contents/MacOS/imcp-server is being used consistently from 2026-06-28T15:51:59 onward. The AppTranslocation path problem has been resolved.
The pattern causing your failures:
Every failure instance in this log follows the same sequence, extracted directly:

Initializing server... → Server started and connected successfully
Then immediately: [imcp_server] Network handler failed: connectionClosed followed by [imcp_server] Stdin handler failed: CancellationError() followed by [imcp_server] Connection closed, terminating...
Then: Server transport closed unexpectedly, this is likely due to the process exiting early
Then: Server disconnected

The critical observation:
The iMCP server side logs Connection closed, terminating... as a critical level event — and it terminates itself immediately upon startup in the failure cases. This is the iMCP process choosing to exit, not Claude Desktop failing to connect.

What distinguishes successful sessions from failed ones:
In every successful session in this log, the startup sequence completes through initialize, notifications/initialized, and tools/list message exchanges before any disconnect occurs. In every failed session, the iMCP server process terminates before the initialize handshake completes — within milliseconds of startup.
What this points to:
The iMCP server process itself is terminating on startup in these cases. The most common cause of this pattern — where a process starts and immediately exits with CancellationError on stdin — is that the iMCP background service (the macOS-side component) is not running or is in a bad state when Claude Desktop tries to connect to it.
Suggested next step:
After a Claude Desktop update triggers the failure, check whether the iMCP app itself is running as a background process. Open Activity Monitor and search for imcp. If it is not running, try launching iMCP.app manually from /Applications before restarting Claude Desktop, then see if the connection succeeds.
This is the most actionable diagnostic step I can identify from the log. Whether this fully resolves the issue depends on iMCP's internal behavior, which I cannot determine from this log alone.

Inferred: Based on the log pattern showing the iMCP server terminating itself within milliseconds of startup specifically after Claude Desktop restarts, not during normal operation.
Your manual workaround sequence would be:

Quit Claude Desktop
Force quit the iMCP process in Activity Monitor (or quit iMCP.app if it has a menu bar icon)
Relaunch iMCP.app to get a fresh instance
Then launch Claude Desktop

That sequence should give Claude Desktop a clean iMCP process to connect to each time.
Whether there is a cleaner fix — such as iMCP handling reconnection gracefully — would be a question for the iMCP developer. The root cause appears to be on iMCP's side, not Claude Desktop's, since iMCP is the one issuing the terminating... critical event.

mcp-server-iMCP.log

[pdazero]

Same symptom here, and I traced it to a root cause: iMCP.app runs out of file descriptors. It never closes its side of a client socket, so every imcp-server that disconnects leaks one descriptor permanently.

Environment: iMCP 1.4.1, macOS 26.5, Claude Desktop.

Evidence

• lsof on the app process: 247 sockets stuck in CLOSE_WAIT, highest fd 255.
• launchctl limit maxfiles → soft limit 256. So the app tolerates ~248 client connections over its entire lifetime, then stops serving.
• The app's own log at the moment it broke: Too many open files (from CoreUI, which could no longer open a resource file — the process was simply out of fds).
• Every connection after that is refused instantly. The client logs Socket SO_ERROR [54: Connection reset by peer] within 30 ms of connecting, which surfaces as exactly the lines in this issue:

  Network handler failed: connectionClosed
  Stdin handler failed: CancellationError()
  Connection closed, terminating...
  

Minimal reproduction of the leak (no MCP client needed)

1. lsof -nP -p $(pgrep -x iMCP) -a -i — note the app's fds and its listening port.
2. Open a plain TCP connection to that port from any client, then close it from the client side.
3. Re-run the lsof. The app's descriptor for that connection is still there, now in CLOSE_WAIT, and it never goes away.

I verified both directions: before restarting the app, a fresh connection got an immediate RST and produced no fd on the app side at all; after restarting, the same connection was accepted (fd ESTABLISHED) — and when I closed it, that fd went straight to CLOSE_WAIT and stayed there. One descriptor lost per connection.

Why it looks random, and why it's getting worse now

The counter only resets when the app restarts, so the failure depends on how many connections have happened since launch, not on any particular action. That's also why the "quit iMCP → relaunch → works every time, but the bug returns within hours/days" workaround in #24 behaves the way it does.

It got much more visible recently because Claude Desktop now starts a separate copy of the server for its Cowork and Code sessions, which multiplies the connection count. The failure is asymmetric and that's the tell: the normal chat session keeps working because its connection was established before exhaustion, while the new sessions report:

Couldn't start this server for Cowork and Code sessions (they run their own copy of it),
so they can't use its tools: Connection closed

The accelerant: orphaned servers

Orphaned imcp-server processes (PPID 1) that outlive the MCP client retry forever. I found 7 of them stuck in SYN_SENT, 18 hours after Claude Desktop had closed them. This looks like the inverted exit paths described in grlee#1: stdin EOF falls into the reconnect loop instead of terminating.

The moment the app relaunches and publishes its Bonjour service, that pile of retrying orphans burns all ~248 descriptors in under a second — my app log shows connections C24→C248 all opening within 0.7 s, five seconds after launch. The app was dead on arrival, and Too many open files appeared a minute later.

Workaround — the order matters

Restarting the app alone does not hold, because the surviving orphans re-exhaust it within seconds. Kill them first:

1. pgrep -fl imcp-server, then ps -o pid,ppid,command -p <pids> — target the ones with PPID 1. Leave alone the one parented by Claude's disclaimer --pgroup helper; that one is managed and exits on its own.
2. kill the orphans.
3. osascript -e 'quit app "iMCP"', then open -a /Applications/iMCP.app.
4. Reconnect the server from your MCP client — it does not relaunch by itself.

After that, the app came back with a single fd in LISTEN and zero in CLOSE_WAIT.

Where the fix belongs

In the app, not the CLI: the accepted connection needs to be cancelled/closed when the peer disconnects, so the descriptor is released. Worth noting that grlee#1 fixes the orphan side but not this one, and on its own its 1-second reconnect loop would exhaust the leaking app in ~4 minutes whenever the app is unreachable for a while. #151 touches removeConnection but only to make it idempotent — it doesn't release the socket either.

This is a different bug from #174 (that one leaks unix sockets from the helper into mDNSResponder, taking down system-wide DNS) — same family, different process.