Telegram channel: incoming messages sometimes fail to submit into the TUI, silently lost (not just at startup)

Description

Running Claude Code headless in a tmux session with the Telegram channel plugin (plugin:telegram@claude-plugins-official), driven by a systemd service that keeps a long-lived /loop session open to answer incoming Telegram messages via the reply tool.

Observed bug: an incoming Telegram message sometimes appears typed into the prompt box but the Enter/submit never registers — the message sits unsubmitted indefinitely, and the bot never processes or replies to it. This is distinct from (and happens in addition to) intermittent plugin:telegram:telegram MCP server disconnects, which also independently break the reply tool mid-session.

Reproduced today (2026-07-04):

1. A message ("Скинь статус моста") sat stuck in the input box unsubmitted for several minutes.
2. Restarting the whole session (systemctl restart on the wrapping service, which kills and recreates the tmux session and re-issues /loop) did not fix the underlying issue — within ~90 seconds of a fresh restart, a new incoming message ("проверь, что сообщения из Telegram реально доходят") got stuck the same way.
3. Attempting to manually recover the stuck message via tmux send-keys -t <session> Enter (retried every ~2s for 30s, both alone and preceded by a literal space keystroke) did not submit it — instead it silently cleared the input line with no reply ever generated. Net effect: the message was lost, not recovered.
4. Separately (same day, different incident, ~05:47 local), the bot's own turn self-reported an explicit Telegram MCP plugin disconnect ("Telegram-плагин только что отключился — MCP-сервер plugin:telegram:telegram разорвал соединение") mid-session, while the tmux session itself stayed alive and responsive to the terminal.

Impact: real user messages sent over Telegram are silently dropped with no error surfaced to the sender — the person on Telegram has no indication their message wasn't received, and the operator only notices by inspecting the raw tmux pane.

What already has a workaround: the wrapper's own startup script types its 3 known startup lines (channel launch command, trust-prompt confirmation, /loop command) using a retry-until-confirmed helper (type text, then retry Enter every 2s up to 60s until a known confirmation string appears in the pane). This works reliably for those 3 fixed lines. The bug only affects messages injected into the running session after startup, i.e. actual incoming Telegram messages during normal operation — those don't appear to go through an equivalent retry/confirmation path.

Ask: could the Telegram channel's message-injection path (however it types/submits incoming messages into the CLI) get the same kind of submit-confirmation retry the startup flow already has? Or alternatively, some way to detect/report a failed injection so the operator (or the bot itself) knows a message was dropped, rather than it disappearing silently.

Environment

• Claude Code v2.1.201, Sonnet 5
• Ubuntu server, headless mode via tmux + systemd, claude --channels plugin:telegram@claude-plugins-official then /loop