Telegram channel plugin: inbound messages never reach an interactive --channels session

Summary

The official telegram channel plugin (v0.0.6) delivers outbound messages fine (the reply MCP tool works reliably), but inbound messages from Telegram never surface as new turns in a Claude Code session that was invoked with --channels plugin:telegram@claude-plugins-official while that same session is also being driven interactively (typed to directly in the terminal).

Environment

• Claude Code version: 2.1.220
• Plugin: telegram 0.0.6 (claude-plugins-official)
• Platform: macOS (Darwin 23.4.0)
• Bot: grammy-based long-polling server (server.ts), spawned as an MCP stdio child of the claude --channels session

Steps to reproduce

1. Configure the telegram channel (/telegram:configure <token>), pair a Telegram account, set dmPolicy: "allowlist" with the paired user's ID in allowFrom.
2. Open/attach to the claude --channels plugin:telegram@claude-plugins-official session interactively (e.g. via a terminal) and have a normal back-and-forth conversation with it.
3. From the paired Telegram account, DM the bot in a private chat.
4. Observe: the bot never replies. No <channel source="telegram" ...> tagged turn appears anywhere in the session transcript (~/.claude/projects/.../<session-id>.jsonl).

What was verified as healthy

• getMe / getWebhookInfo confirm the bot token is valid and polling is active (pending_update_count: 0 after each send — Telegram is handing updates to the bot process).
• access.json is correctly configured: dmPolicy: "allowlist", sender's numeric Telegram ID present in allowFrom. Confirmed the ID matches (@userinfobot).
• Chat type confirmed private (1:1 DM), ruling out the group/mention gating path in gate().
• Outbound works: calling the reply MCP tool (mcp__plugin_telegram_telegram__reply) with the paired chat_id successfully delivers a message to the Telegram app, both before and after restarting the bot process.
• Restarting the bot process entirely (killing the bun server.ts child and its bun run --cwd ... start wrapper, then running /reload-plugins to respawn it fresh) did not change the behavior — inbound still never arrives.
• /reload-plugins alone (without manually killing the process first) did not actually restart the child process — the same PID and uptime persisted across the reload, suggesting reload only reconnects to an existing healthy-looking server rather than cycling it.
• Grepped the full raw session transcript (.jsonl) for any occurrence of an inbound channel notification (channel source="telegram", chat_id payloads matching the sender's ID as actual message content rather than quoted source code) — zero real inbound deliveries were found across ~270 transcript lines and multiple Telegram messages sent by the user during the session, including after waiting several idle minutes with no interactive input.

Hypothesis

server.ts emits inbound messages via mcp.notification({ method: 'notifications/claude/channel', ... }) over the stdio MCP transport. This looks correct on the plugin side (per source review of server.ts). The break appears to be on the harness side: MCP server-initiated notifications for the channels feature do not appear to be converted into new conversation turns when the target --channels session is concurrently being used as an interactive session (human typing directly into the same session). It's possible these notifications are simply dropped rather than queued when the harness isn't in the specific idle/wait state the channels feature expects.

Impact

Users cannot both (a) use a --channels-invoked session interactively via terminal and (b) reliably receive/respond to inbound messages from the paired channel (Telegram in this case) during that time. This wasn't obvious from the documentation and is easy to stumble into simply by opening a terminal into the channel session to check its status.

Suggested next steps for investigation

• Confirm whether notifications/claude/channel pushes from a plugin MCP server are queued and delivered once the current interactive turn completes, or dropped outright if the session isn't in a specific waiting state.
• If dropped: queue and flush inbound channel notifications after the current turn finishes, regardless of whether the session was also driven interactively.