Claude Code Telegram Plugin Bug: MCP Notifications Silently Dropped — Workaround via File Polling and tmux Injection

A Reddit user discovered a bug in Claude Code: the MCP notification system silently drops inbound messages on the stdio transport. The Telegram plugin itself is fine — the problem is in Claude Code's client. The user confirmed the bug by tracing the call chain:

• handleInbound() fires ✅
• gate() returns deliver ✅
• bot.api.sendChatAction('typing') fires (user sees typing indicator) ✅
• mcp.notification({ method: 'notifications/claude/channel', ... }) is called ✅
• Claude Code receives it and silently does nothing ❌

The bug is reproducible on WSL2, Linux, and likely all platforms. A GitHub issue has been opened: #46744.

Workaround

Since the MCP notification path is broken, the user built an alternative delivery system:

• Patch server.ts to write incoming messages to a local JSON inbox file
• A shell watcher polls every 5 seconds, detects when Claude is idle, and injects the message via tmux send-keys
• A watchdog auto-restarts the service if Claude stalls

Key pitfalls encountered:

• tmux new-session silently fails in systemd without export TERM="xterm-256color" and -x 220 -y 50
• kill 0 in the trap causes SIGSEGV ~60s after startup — use kill $WATCHER_PID
• Idle check MUST exclude "esc to interrupt" or the watcher spams while Claude is processing

Full code, systemd unit, cron fallback, and verification checklist are available at: https://github.com/LozzKappa/claude-code-telegram-bot

Latency with the workaround is 5–9 seconds. The real fix needs to come from Anthropic — fixing the MCP notification handler inside Claude Code.