Telegram plugin: inbound channel notifications not delivered in tmux/headless sessions

Bug Description

When Claude Code is run inside a tmux session (headless, no direct TTY), the Telegram plugin's MCP server successfully polls messages and the MCP stdio transport socket is connected, but inbound channel notifications are never displayed or processed by Claude Code. Outbound reply tool calls work perfectly.

Environment

• Claude Code: v2.1.81
• OS: Oracle Linux (cloud VM) and macOS
• Telegram plugin: telegram@claude-plugins-official v0.0.1
• Runtime: bun (for server.ts / grammY)
• Launch method: tmux new-session -d -s cc 'claude --dangerously-skip-permissions'

Steps to Reproduce

1. Install and configure the Telegram plugin (~/.claude/channels/telegram/.env with bot token, access.json with allowed user)
2. Start Claude Code inside tmux: tmux new-session -d -s cc 'claude --dangerously-skip-permissions'
3. Confirm CC starts, bun server.ts spawns, and MCP tools (mcp__plugin_telegram_telegram__reply) are available
4. Send a message to the Telegram bot from an allowed user
5. Observe: bot shows "typing" indicator, but CC never displays the incoming message

Diagnosis

Extensive debugging confirmed:

What works:

• Telegram Bot API receives messages (getUpdates returns them)
• bun server.ts polls and consumes updates (getUpdates returns empty after consumption)
• MCP stdio transport sockets are connected (verified via ss -xp):
• bun fd 0 (stdin) ↔ claude fd 30 (unix socket)
• bun fd 1 (stdout) ↔ claude fd 33 (unix socket)
• Outbound reply tool works — CC can send messages to Telegram chats successfully
• access.json allowlist is correctly configured

What fails:

• mcp.notification({ method: 'notifications/claude/channel', ... }) from bun server.ts is written to stdout (socket) but CC never processes or displays the incoming message
• CC stays at the idle ❯ prompt — no channel message appears

Additional observation:

• The bun server.ts process also tends to silently crash after some time, with no error logs. When this happens, CC doesn't detect the child process death and doesn't restart it. The MCP tools remain listed as available even though the server is dead.

Controlled Test

To rule out interference from other services, we:

1. Stopped ALL other services on the machine (including openclaw-claude-proxy on port 3456)
2. Confirmed only CC + bun server.ts were running
3. Verified port 3456 was free, no other claude/bun processes
4. Same result: messages consumed by bun, never delivered to CC

Expected Behavior

1. Incoming Telegram messages should appear in the CC session as <channel source="plugin:telegram:telegram" ...> tags, regardless of whether CC runs in tmux or a direct terminal
2. If the MCP server child process (bun) crashes, CC should detect this and either restart it or surface an error

Suggested Fixes

1. Channel notification delivery: Investigate why notifications/claude/channel MCP notifications are not processed when CC runs in tmux/without a direct TTY
2. MCP child process monitoring: Add health checks or process exit detection for plugin MCP servers, with automatic restart or user-visible error when a plugin server dies
3. Silent bun crashes: The grammY polling server exits without any error output — consider adding a watchdog or crash logging

Workaround

Currently the only workaround is to run Claude Code in a direct terminal session (not tmux/screen/nohup). This limits CC+Telegram to environments with an active terminal connection.