MCP stdio servers lose stdin pipe after ~10-20 minutes, process orphaned to PID 1

Environment

• Claude Code: 2.1.81
• OS: macOS 15.5 (Darwin 25.3.0)
• Terminal: cmux (Ghostty-based)
• MCP servers affected: Telegram plugin (claude-plugins-official), Linear (mcp-remote SSE), koan-ix, build-watcher — ALL stdio servers

Expected Behavior

MCP stdio servers maintain persistent connection throughout the session.

Actual Behavior

After 10-20 minutes, the stdio pipe from Claude Code to the MCP server breaks silently. The server process survives but becomes unreachable.

Detailed Diagnosis

1. Before failure: Tool works normally (mcp__plugin_telegram_telegram__reply sends messages)
2. After failure: Error: No such tool available: mcp__plugin_telegram_telegram__reply
3. Server process still alive, orphaned to launchd:

``
PID 52235 PPID 1 /Users/pramod/.bun/bin/bun server.ts
``

1. lsof shows broken stdin pipe:

``
bun 52235 FD 0u unix -> (none) # stdin pipe BROKEN
bun 52235 FD 1u unix -> 0xfd3b... # stdout still has a socket
``

1. /mcp reconnect spawns a NEW process — the orphan keeps running, creating zombie MCP servers

Timing Pattern

• Happens during active use AND idle periods
• Reducing MCP server count (6 → 2 global) did not help
• Affects ALL stdio servers, not just one plugin
• Frequency: every 10-20 minutes, sometimes as short as 5 minutes

Steps to Reproduce

1. Enable any stdio MCP plugin (e.g., Telegram channel)
2. Verify tool works
3. Wait 10-20 minutes
4. Try tool again → "Error: No such tool available"
5. Verify: ps -o ppid= -p <server-pid> → shows PPID=1

Impact

• Stateless servers: /mcp reconnect works (new process, no state loss)
• Stateful servers (Telegram bot): orphaned process holds bot polling loop, new process re-initializes
• Accumulates zombie processes over a long session

Analysis

The parent side (Claude Code) appears to close/lose the file descriptors to the child MCP server. The child survives because it has its own event loop (Telegram polling, etc.). This suggests the pipe management in Claude Code's MCP client is the issue, not the server.

A keepalive or reconnect-on-broken-pipe mechanism would fix this. Alternatively, detect the broken pipe and auto-restart the server process.

Related Issues

• #21341 (locked) — MCP server connection failures
• #35287 — MCP stdio servers hang on init
• #36964 — Telegram MCP dies after startup (Windows)