claude-code - 💡(How to fix) Fix [BUG] v2.1.132: notifications/claude/channel rendered to prompt but not auto-submitted (TUI idle never starts a turn)

Summary

notifications/claude/channel MCP notifications are received and rendered in the TUI but not auto-submitted — Claude shows the user input as ❯ <text> on the prompt and sits idle, waiting for an Enter that never comes. Affects production deployments running Claude Code with the Telegram channel plugin.

Related but distinct from #45408: that issue describes notifications being silently dropped. In our reproduction the notification IS rendered to the prompt; only the auto-submit step is missing.

Environment

Steps to Reproduce

1. Start Claude Code in tmux with the Telegram plugin enabled (--channels plugin:telegram@claude-plugins-official)
2. Have a back-and-forth conversation via Telegram so the plugin has been delivering notifications successfully
3. After Claude finishes a turn and returns to idle, send a Telegram message
4. Plugin fires mcp.notification({ method: 'notifications/claude/channel', params: { content, meta } })
5. Claude Code TUI renders the content on the prompt as ❯ <text> (visible via tmux capture-pane)
6. No turn starts — TUI sits at the prompt waiting for Enter

Evidence

tmux capture-pane -t claude-code -p immediately before manual intervention:

✻ Worked for 2m 19s

────────────────────────────────────────────────────────────────────────────────
❯ pode escrever o procedure e testar
────────────────────────────────────────────────────────────────────────────────
  ⏵⏵ bypass permissions on (shift+tab to cycle)
  ✗ Auto-update failed · Try claude doctor or npm i -g @anthropic-ai/claude-c…
                        control this session from your phone · /remote-control

tmux display-message -p '#{session_activity}' showed last activity ~14h prior — the input had been sitting on the prompt unprocessed for that entire time.

The session jsonl confirmed the user-message entry was never written until intervention:

• File: ~/.claude/projects/<workspace>/<sessionId>.jsonl
• The line "role":"user","content":"pode escrever o procedure e testar" first appears at 2026-05-08T20:21:21.204Z — exactly when we forced a respawn. No prior occurrence.

Plugin is innocent

server.ts line ~958 only fires the MCP notification — it has no terminal/tmux code at all:

mcp.notification({
  method: 'notifications/claude/channel',
  params: {
    content: text,
    meta: { chat_id, message_id, user, user_id, ts, ... }
  }
})

grep -rE "send-keys|load-buffer|paste-buffer|tmux" plugins/.../telegram/0.0.6/ returns zero matches in the plugin source. The TUI is the layer that renders the prompt and decides whether to start a turn.

Workaround (no plugin patch needed)

kubectl exec <pod> -- su - agent -c "tmux send-keys -t claude-code Enter"

Effect: Claude immediately enters Contemplating… and processes the pending input. We've wired a 60s cron in our pod entrypoint that detects a stuck ❯ line via tmux capture-pane and sends Enter automatically.

Expected Behavior

When notifications/claude/channel is delivered while the TUI is idle, the TUI should start a turn with the notification content as the user message — without requiring a synthetic Enter.

Notes

• Affects multiple pods in our fleet (separate issue, multi-occurrence)
• When Claude is mid-turn, notifications appear to be queued/processed correctly. The bug is specific to the idle → idle transition
• We can share full session jsonl, plugin stderr, and tmux session timeline if useful — happy to attach scrubbed copies