Telegram channel plugin: inbound photos downloaded but never surfaced as a conversation turn — no reply sent

Environment: Windows 11, Claude Code CLI 2.1.212 (npm install), telegram plugin v0.0.6 (external_plugins/telegram)

Summary:
The Telegram channel plugin's bot process correctly receives, gates, and downloads inbound photo messages, but the resulting MCP notification (notifications/claude/channel) never surfaces in the Claude Code session as an inbound turn. No <channel source="telegram"> message appears in the transcript, no reply tool call happens, and the Telegram user gets no response at all.

Steps to reproduce:

1. Pair a Telegram account via /telegram:access (allowlist confirmed working).
2. Start a Claude Code CLI session with the telegram plugin enabled.
3. From the paired Telegram account, send a photo (with or without caption) to the bot.
4. Observe: the photo is downloaded to ~/.claude/channels/telegram/inbox/<timestamp>-<id>.jpg (filesystem timestamp confirms delivery), but no corresponding message appears in the CLI session, and Telegram never receives a reply.

Expected behavior: The inbound photo should appear in the active session as <channel source="telegram" chat_id="..." message_id="..." user="..." ts="..." image_path="...">, triggering a normal turn where Claude reads the image and calls reply.

Actual behavior: Silent drop after download. Reproduced across 5 separate messages over 2 days, including one that arrived ~40s after a brand-new CLI session started (ruling out a stale/orphaned session as the cause).

Root cause analysis:

• Verified via process tree (Get-CimInstance Win32_Process) that exactly one bun.exe server.ts instance was running, as a child of the active claude.exe CLI session — no 409/zombie-poller conflict.
• ~/.claude/telegram-obsidian-error.log (a companion hook that mirrors channel turns to a local log) is empty, consistent with the harness never producing an assistant turn with a reply tool call for these messages.
• server.ts's own code path (gate → download → mcp.notification(...)) completes without throwing (file lands in inbox), so the gap appears to be on the Claude Code client side: background MCP channel notifications aren't reliably being consumed and injected as a new conversation turn.

Impact: Telegram channel is effectively non-functional for inbound photos in this environment — messages are silently lost after download with no error surfaced to either the CLI user or the Telegram sender.

🤖 Generated with Claude Code