Desktop app does not auto-reconnect a stdio MCP server after its binary is updated; stays "disconnected" until full app restart

Summary

When a locally-installed stdio MCP server's binary is replaced/restarted out from under the desktop app (e.g. the backing app auto-updates), Claude Desktop shows the server as "disconnected" and does not attempt to re-spawn it. The only recovery is a full quit-and-relaunch of Claude Desktop.

Environment

• macOS 15.5 (Darwin 25.5.0), Apple Silicon (Mac14,3)
• MCP server: Day One extension (local.mcpb.automattic.dayone-cli, from Automattic), a binary type extension running /usr/local/bin/dayone mcp

Steps to reproduce

1. Install a stdio-based MCP server whose command is a binary provided by a separate host app.
2. Confirm it connects and tools load.
3. Have the host app update/replace its binary while Claude Desktop is running (in my case the Day One app auto-updated, build Core/1771 -> Core/1774 on 2026-08-04).
4. Observe the "Server disconnected" toast.

Expected

Claude Desktop detects the dropped stdio connection and automatically re-spawns the server process (with backoff/retry), restoring the tools without user intervention.

Actual

The server stays in a disconnected state indefinitely. A full restart of Claude Desktop was required to reconnect. After restart it connected immediately with no other changes.

Evidence it is not a server-side crash

Running the exact launch command manually (/usr/local/bin/dayone mcp) starts cleanly, and the server's own logs show healthy sessions handling initialize and tools/list with no errors. The binary and its symlink resolve correctly. So the server was fine -- the desktop app simply never re-established the connection.

Suggested fix

Add automatic reconnection/re-spawn with retry for stdio MCP servers when the pipe closes, rather than requiring a manual app restart.