--channels telegram MCP subprocess intermittently fails to spawn (no error, mcp list falsely shows Connected)

Description

When launching a session with claude --channels plugin:telegram@claude-plugins-official, the Telegram channel's MCP subprocess (bun) intermittently fails to spawn. When this happens:

• All incoming Telegram messages (text and images) are silently written to ~/.claude/channels/telegram/inbox/ but never surfaced to the session — no reply is ever sent.
• claude mcp list still reports plugin:telegram:telegram Connected, which is misleading — this appears to spin up a separate transient test process rather than reflecting the actual session state.
• The session's tool list is missing all Telegram-specific tools (reply, react, edit_message, download_attachment).
• ps --ppid <session_pid> shows no bun child process, while other stdio MCP servers configured in the same session (Gmail, Google Calendar, Google Tasks, Open-Meteo) all spawn correctly as children.
• ~/.claude/channels/telegram/bot.pid does not exist, indicating the plugin's server.ts never reached the point of writing its PID file — the subprocess was never started, not started-then-crashed.
• No error or log output is produced anywhere indicating the spawn failure.

Environment

• Platform: Linux (Ubuntu), bun available in PATH (~/.bun/bin)
• Plugin: telegram v0.0.6 (claude-plugins-official)
• Not reproducible with a fixed trigger — appears to be a race condition in --channels startup that occurs intermittently across multiple independent sessions.

Steps to reproduce

1. Launch claude --channels plugin:telegram@claude-plugins-official (repeat across multiple sessions/days).
2. Send a message to the paired Telegram bot.
3. Sometimes the session responds normally; other times the message sits unanswered in inbox/ indefinitely.
4. When it fails, check ps --ppid <pid> for a missing bun child and confirm bot.pid is absent, despite claude mcp list reporting Connected.

Impact

This has recurred at least 3 times over two weeks (first noticed ~2026-07-05, diagnosed in depth 2026-07-16, recurred again 2026-07-18). Restarting the session does not reliably fix it — one restart attempt on 2026-07-16 reproduced the exact same broken state. Since there's no error surfaced anywhere, the only way to detect it is to manually inspect process trees, which isn't something an end user should have to do to find out their messages are being silently dropped.

At this point it's affecting trust in the channel enough that I'm considering moving this workflow to Codex if it isn't addressed.