Telegram channel notifications silently dropped when CLI is idle after agent task completion

Resolved ๐Ÿ’ฌ 3 comments Opened Mar 28, 2026 by Lohengram Closed Apr 1, 2026

Summary

Telegram MCP channel plugin delivers messages successfully (confirmed via ackReaction โ€” bot reacts with ๐Ÿ‘€), but Claude Code does not process the MCP notifications/claude/channel events when the CLI is in an idle/input-waiting state after an agent completes a task.

Environment

  • macOS (Darwin 25.3.0)
  • Claude Code CLI (latest)
  • Telegram plugin v0.0.4 (claude-plugins-official)
  • grammy-based long-polling, MCP stdio transport

Steps to Reproduce

  1. Start Claude Code with the Telegram channel plugin connected
  2. Send a message via Telegram โ€” agent responds normally
  3. Have the agent complete a multi-step task (e.g., code implementation, document generation)
  4. Agent says something like "I'll organize the docs and wait for your next message"
  5. Send a new message via Telegram

Expected: Claude Code processes the notification and responds
Actual: No response. The message is silently dropped.

Observed Behavior

| Action | Result |
|--------|--------|
| Telegram message while CLI idle | No response (๐Ÿ‘€ ack reaction confirms plugin received it) |
| Send 2โ€“3 repeated messages | Eventually gets a response |
| Type anything in CLI to "wake" session | Telegram messages work again |
| Agent completes another task | Back to unresponsive state |

Diagnosis

  • ackReaction: "๐Ÿ‘€" was added to access.json to verify plugin-side message receipt โ€” plugin receives all messages correctly
  • mcp.notification({ method: 'notifications/claude/channel', ... }) is called without errors (the .catch() on line 945 of server.ts does not fire)
  • The issue is Claude Code's MCP notification event loop not processing incoming channel notifications when the CLI is waiting for user input after an agent task completes
  • This is not a plugin bug โ€” the notification is sent over stdio but Claude Code doesn't act on it

Workaround

Currently the only workaround is to type something in the CLI to "activate" the session, after which Telegram messages are processed again โ€” until the next agent task completion cycle.

Additional Context

The pattern suggests that after an agent finishes work and Claude Code returns to its input prompt, the MCP notification listener may be suspended or deprioritized. The fact that repeated messages (2โ€“3x) sometimes break through suggests a race condition or buffering issue rather than a complete listener shutdown.

View original on GitHub โ†—

This issue has 3 comments on GitHub. Read the full discussion on GitHub โ†—