Channels: inbound message arriving mid-turn strands in the TUI input line and is never auto-submitted on turn completion

Summary

When Claude Code runs with --channels plugin:telegram@<marketplace> and an inbound channel
message arrives while a turn is in flight, the message is rendered into the TUI input line
(after the ❯ prompt) but is intermittently never submitted when the turn completes. The
text sits at the prompt indefinitely (longest observed: 13.4 hours), and because deliveries
queue behind it, the session becomes permanently deaf to further channel input while the process
stays healthy — systemd active, plugin server process alive, zero errors logged.

Environment

• Claude Code v2.1.158, telegram plugin 0.0.6 (claude-plugins-official)
• Ubuntu 24.04 in WSL2 (systemd PID 1), session under tmux, launched via

exec claude --channels plugin:telegram@claude-plugins-official

• Also relevant: identical Channels deployments on native Ubuntu 24.04 (Hetzner) — same plugin,

same launch shape; the WSL2 host is where activity was heavy enough to surface it repeatedly.

Reproduction (probabilistic race — ~12 hits in one active day)

1. Start a Channels session (Telegram plugin), pair a DM.
2. Send a message that triggers a long turn (30s+).
3. While the turn is running (spinner up), send a second message.
4. Intermittently: the second message renders after ❯ but on turn completion is not submitted —

no queue-operation enqueue, no user turn in the session JSONL (grep count 0). It never
recovers on its own.

The race window appears to be turn-completion; frequency rises sharply with conversation tempo
(nearly every message sent during an active turn stranded, on the worst day).

Evidence collected

• Stranded text present in capture-pane output, byte-identical across samples 25+ minutes apart;

no spinner; JSONL grep -c for the text = 0.

• Plugin ruled out: the plugin's poll loop stayed alive (bot.catch + retry-on-error), and its

state directory shows zero inbound activity after the strand — consistent with deliveries
queuing behind the stuck item inside CC.

• On one occurrence the stranded text later entered the session as a **wrapper-less plain-text

turn** when Enter/retype was injected via tmux — confirming it sat in the raw input line, not
the channel queue path.

• Recovery quirk: on some occurrences a bare Enter (send-keys C-m) is a no-op — only retyping

the text (send-keys -l '<text>' + Enter) submits, suggesting the rendered line is not always
backed by the live input buffer.

Impact

Autonomous Channels bots go silently deaf while every process-level health signal stays green.
We now run a tmux-level watchdog that detects idle-with-nonempty-prompt and re-submits — works,
but it's a workaround typed into the pane from outside.

Ask

Auto-submit (or re-queue) buffered channel input on busy→idle transition, or expose the
buffered/stranded state so a supervisor can detect it without pane-scraping.