--channels mode: MCP channel notification handler stops firing after N messages (Telegram plugin)

Environment

• Claude Code: 2.1.81
• OS: macOS 25.3.0 (Darwin)
• Plugin: telegram@claude-plugins-official v0.0.2

Description

When running claude --channels plugin:telegram@claude-plugins-official, the first few Telegram DMs receive replies correctly, but after N messages (inconsistent — sometimes 3–4), subsequent DMs trigger the typing indicator in Telegram but Claude Code never processes them. The session stays alive but goes permanently silent for new messages.

Steps to Reproduce

1. Configure Telegram plugin (~/.claude/channels/telegram/.env with bot token, access.json with dmPolicy: "allowlist")
2. Run claude --channels plugin:telegram@claude-plugins-official --debug
3. Send several DMs to the bot
4. First few messages work correctly (full reply cycle)
5. After N messages, subsequent DMs show Telegram's typing indicator but no reply arrives and nothing appears in the terminal

Debug Log Evidence

With --debug, each working message logs:

[DEBUG] MCP server "plugin:telegram:telegram": notifications/claude/channel: <message text>
[DEBUG] Stream started - received first chunk
[DEBUG] MCP server "plugin:telegram:telegram": Calling MCP tool: reply
[DEBUG] MCP server "plugin:telegram:telegram": Tool 'reply' completed successfully

For the failing message, none of these lines appear — the notifications/claude/channel: handler never fires on Claude Code's side, even though:

• The Telegram bot server is still receiving messages (confirmed by typing indicator still appearing in Telegram)
• The bot's allowlist gate is still passing the messages (typing action is sent before the MCP notification)

The debug log shows a 1m24s gap after the last successful reply, then a UI event (Fast mode unavailable) with no channel notification, no stream, no API call — the MCP notification handler simply stopped firing.

Full Debug Log

https://gist.github.com/esilbe1/a2f2e4a76788f970fdb8c8a818fadd49

Additional Notes

• The issue appears intermittently with respect to message count (sometimes fails after 1, sometimes after 3–4)
• Running with --debug seems to extend how many messages work before the handler goes silent (without --debug, it failed after the 1st message; with --debug, it worked for 3 messages)
• This suggests a possible race condition or timing-sensitive bug where --debug mode's extra logging slows things down enough to change behavior
• The bot server process stays alive throughout (confirmed via ps); the issue is on Claude Code's side receiving the MCP notification