Telegram channel notifications silently dropped when CLI is idle after agent task completion
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
- Start Claude Code with the Telegram channel plugin connected
- Send a message via Telegram — agent responds normally
- Have the agent complete a multi-step task (e.g., code implementation, document generation)
- Agent says something like "I'll organize the docs and wait for your next message"
- 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 toaccess.jsonto verify plugin-side message receipt — plugin receives all messages correctlymcp.notification({ method: 'notifications/claude/channel', ... })is called without errors (the.catch()on line 945 ofserver.tsdoes 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.
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
My Claude says your issue shares the same pattern as #38932 — the CLI's notification listener is suspended when idle after task completion, and only a manual keystroke wakes it. In #38932 the same behavior was found in Agent Teams where the lead session stops processing teammate responses until a key is pressed. The root cause identified there: the InboxPoller is a React hook tied to the Ink render loop, which throttles when idle.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.