Channel-plugin message arriving mid-turn is queued but intermittently never executes — silent permanent loss (2.1.198 & 2.1.204, telegram plugin)

Summary

A message delivered by a channel plugin (official telegram plugin) while Claude Code is mid-turn is enqueued and rendered at the ❯ prompt as a queued command, but intermittently never executes when the turn ends. The queued item then sits permanently: it re-renders after every subsequent turn, keystrokes don't submit it, and later turns' queue-drain checks skip it. The message is silently lost — the sender gets no response and there is no error anywhere.

This looks like the same fault class as #66310, #38259 (exact CLI/Telegram variant, closed stale), #37250, and #61718 — reporting again with a stronger evidence set: 13 distinct dropped messages in ~30 hours across 4 independent sessions, on two different versions, with transcript-level proof of non-delivery.

Environment

• macOS 26.5.1 (Darwin 25.5.0), Apple Silicon (M4)
• Claude Code 2.1.198 AND 2.1.204 (both exhibit the bug; see version matrix)
• Official telegram plugin 0.0.6 (claude-plugins-official)
• Each bot runs in its own tmux session; terminal TUI (alternate screen)

Reproduction (intermittent — a race)

1. Run Claude Code with the telegram channel plugin in tmux.
2. While Claude is mid-turn (streaming/working), send a Telegram message to the bot.
3. Turn ends. Expected: the queued message fires a new turn. Actual (intermittently): the message renders at the ❯ prompt and never executes.

Once wedged: pressing Enter/Escape via tmux send-keys does nothing (the rendered text is a queued attachment, not input-buffer text); subsequent idle-arriving channel messages deliver fine and run turns, but the wedged item re-renders at the prompt after every turn and never drains. Observed persisting 5+ hours.

Evidence

Non-delivery proof: grepping all ~/.claude/projects/**/*.jsonl transcripts for the wedged message texts finds zero occurrences — the messages never entered any session transcript, while the same texts sit rendered at the ❯ prompt in tmux capture-pane output.

Pane state after a completed turn (typical):

⏺ Sounds good — standing by for how it lands. ...
✻ Worked for 4s
──────────────────────────────
❯ Generated in Suno, listening now      <- Telegram message, never executed
──────────────────────────────
  ⏵⏵ bypass permissions on (shift+tab to cycle)

Version matrix (rules out a recent regression):

| Session started | Claude Code | Wedges observed |
|---|---|---|
| Jul 2 | 2.1.198 | yes |
| Jul 9 | 2.1.204 | yes (3 sessions) |

Frequency: 13 distinct wedged messages in ~30h across 4 sessions (a monitoring script now samples panes every 5 minutes, which is how these are counted; the bug predates the monitoring — it was previously perceived as bots "randomly ignoring" messages).

Plugin side is innocent: server.ts delivers via a single fire-and-forget mcp.notification({method: 'notifications/claude/channel', ...}) — no queue, no retry, no delivery ack — so the loss happens after handoff, in core's queued-command handling. The plugin has no way to detect or recover the drop.

A keyboard-composed message does NOT flush the wedged item: typing a new message + Enter at the TTY runs a normal turn, after which the wedged item re-renders — so the queue-drain skip appears permanent for that item, not just delayed.

Expected behavior

Every queued message either executes when the turn ends or surfaces an explicit error. Silent permanent loss of a user message is the worst-case failure mode for channel-driven use.

Notes

• CHANGELOG 2.1.199 fixed a related-sounding loss ("message sent while Claude was working being silently lost when the turn ended at the --max-turns limit") — this report is NOT that case (no --max-turns involved).
• Happy to provide more detail or run a debug build; this fleet reproduces the race organically several times a day.