MCP stdio server silently disconnects mid-session; child process orphaned to systemd

Description

MCP servers using stdio transport silently lose their connection to Claude Code mid-session. The child process does not crash — it gets reparented to systemd (PPid changes from the Claude process to systemd --user), becoming an orphan that continues running but can no longer communicate with the session.

This was observed with the official Telegram plugin (telegram@claude-plugins-official v0.0.1) but the root cause is in Claude Code's MCP process management, not the plugin itself.

Reproduction

Trigger 1: Long-running Bash commands

1. Start Claude Code with --channels plugin:telegram@claude-plugins-official
2. Send messages from Telegram — replies work fine
3. Run a long Bash command (~90 seconds)
4. Try to reply via Telegram tool → Error: No such tool available: mcp__plugin_telegram_telegram__reply

Trigger 2: claude mcp list

1. Same setup, Telegram tools working
2. Run claude mcp list from within the session (via Bash tool)
3. Telegram MCP tools immediately become unavailable

Forensic evidence

Session trace (session 539f1bbf, 2026-03-20)

18:49:16 — reply tool works fine (sent msg 28)
18:49:34 — new inbound message arrives
18:49:38 — session starts long Bash commands (spawning Claude CLI subprocesses)
18:51:33 — Bash commands complete
18:51:36 — ToolSearch for telegram reply → "No matching deferred tools found"
18:51:40 — direct tool call → "No such tool available"
18:51:43+ — 4 more ToolSearch attempts, all fail

Process state after disconnect

# The bun server is still running...
$ ps aux | grep 'bun server.ts'
max  3096449  1.5  0.1  74693952  93180  ?  Sl  15:37  0:00  bun server.ts

# ...but reparented to systemd (PPid 2859), not Claude (PID 3091007)
$ cat /proc/3096449/status | grep PPid
PPid: 2859  # systemd --user

# Not in Claude's process tree at all
$ pstree -p 3091007 | grep bun
(no match)

# stdio fds point to sockets, not pipes to Claude
$ ls -la /proc/3096449/fd/0
socket:[13339398]

The server process survives but its stdio connection to Claude Code is severed. It becomes a zombie-like orphan — consuming resources, polling Telegram, but unable to deliver messages to anyone.

Expected behavior

1. MCP stdio connections should survive long-running tool calls
2. If disconnected, Claude Code should auto-reconnect (restart the child process and re-establish stdio)
3. At minimum, a /mcp restart command should be available for manual recovery without losing session context
4. Orphaned MCP child processes should be cleaned up

Environment

• Claude Code CLI v2.1.80
• Ubuntu 24.04, Linux 6.17.0-19-generic
• Telegram plugin v0.0.1 (telegram@claude-plugins-official)
• Plugin server: Bun 1.x + @modelcontextprotocol/sdk stdio transport

Related issues

• #36427 — Telegram MCP disconnects (macOS, similar symptoms)
• #36615 — Silent disconnect after idle (macOS)
• #36644 — Connection drops after first inbound message (Linux)
• #36308 — Feature request for MCP auto-reconnect