--channels inbound message silently dropped: shown as pending draft, never committed as a turn, no trace in MCP receive log

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Running an unattended claude --continue --channels plugin:telegram@claude-plugins-official --permission-mode bypassPermissions session inside tmux, an incoming channel message occasionally never gets committed as a real conversation turn. It appears to render in the terminal's input composer (❯ <message text>), but:

• No Enter/submit ever fires for it (confirmed: sending Enter via tmux send-keys had no effect on the frozen line).
• Typing a literal character overlays the display rather than appending to the stuck text, and backspacing back to empty restores the stuck text — indicating it's held in some internal pending/draft state, not a normal editable input buffer.
• The message never appears in the persisted session transcript (~/.claude/projects/<project>/<session-id>.jsonl).
• The message never appears in the MCP client's own debug log for the channel plugin (~/.cache/claude-cli-nodejs/<project>/mcp-logs-<server>/*.jsonl), which otherwise logs every notifications/claude/channel receipt as "notifications/claude/channel: <text>". The log shows the previous message being received and replied to normally, then silence — no entry at all for the message that got stuck.

This rules out the channel plugin (grammy/Telegram bot) as the source — the plugin has no logic that would drop an already-allowlisted sender's message, and if mcp.notification() were being called (which the code unconditionally does after gating), the CLI's own debug logging should show the receipt, but it does not. The failure appears to be inside the CLI's channel-notification-to-turn pipeline itself.

Impact

The message content is permanently lost — restarting the session (--continue) does not recover it, because Telegram's getUpdates offset has already advanced past it by the time the plugin reconnects. The sender has to notice the bot went silent and repeat themselves.

Observed pattern

In both cases I was able to capture, the lost message immediately followed an idle "are you there?"-style exchange that had completed normally (received, logged, replied to). I don't have a minimal repro beyond that — it's intermittent, roughly twice in ~24h of a fairly active channel session (dozens of messages).

Evidence timeline (one instance)

21:11:12  notifications/claude/channel: Test              <- received & logged normally
21:27:40  notifications/claude/channel: Hello?             <- received & logged normally
21:4x:xx  [customer sends: "Deploy the Awókey Broadcast component to production"]
                                                             <- appears in terminal composer, never logged, never in transcript
21:48:43  Sending SIGINT to MCP server process              <- I killed the session to recover

Environment

• claude --continue --channels plugin:telegram@claude-plugins-official --permission-mode bypassPermissions
• Running detached inside tmux (own socket), unattended
• Telegram channel plugin claude-plugins-official/telegram v0.0.6

What I've ruled out

• Not a plugin/grammy bug (allowlisted sender, no dedup/rate-limit logic that would drop it; added durable pre-gate logging on the plugin side as a workaround to confirm inbound receipt at the Telegram layer going forward).
• Not bun/MCP server crash (process stayed alive and connected both times; claude mcp get reported ✔ Connected).
• Not simply "message arrived while CLI was busy" — both times the CLI was idle (had just finished replying to the prior message) when the loss occurred.

Workaround in use

A cron-based watchdog that restarts the session if it detects a composer stuck with non-empty unsubmitted text (or other blocking dialogs) for 2+ consecutive 5-minute checks. This recovers connectivity but not the lost message content.

What Should Happen?

Claud should fix this issue of telegram messages getting dropped

Error Messages/Logs

Steps to Reproduce

Steps to reproduce:

1. Start an unattended channel session, detached (e.g. in tmux), with a paired/allowlisted sender able to DM it:

claude --continue --channels plugin:telegram@claude-plugins-official --permission-mode bypassPermissions

1. From the paired account, send a normal message (e.g. "test") and confirm it gets a normal reply.
2. Send an idle "are you there?"-style message (e.g. "Hello?") and confirm that also gets a normal reply.
3. Leave the session idle with no further activity. In the two instances I captured, the gap before the next message was on the order of tens of minutes to a few hours.
4. Send a new message from the same paired sender.
5. Observe: the message renders in the terminal's input composer (❯ <message text>) but never becomes a real turn:

• Enter (including via tmux send-keys) has no effect on it.
• Typing a character overlays the display rather than appending to the stuck text.
• Backspacing back to empty restores the original stuck text (confirms it's an internal pending/draft state, not a normal editable buffer).
• It never appears in ~/.claude/projects/<project>/<session-id>.jsonl (the persisted transcript).
• It never appears in ~/.cache/claude-cli-nodejs/<project>/mcp-logs-<server>/*.jsonl as a notifications/claude/channel: <text> line, even though the same log shows the previous message being received and replied to normally.

This is intermittent (roughly twice in ~24h of a fairly active channel session, dozens of messages exchanged) and I don't have a fully deterministic trigger beyond "follows a completed idle exchange, after the session has sat quiet for a while" — I was not able to force it on demand.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.224

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_