Telegram channel plugin stops receiving messages after heavy activity (v2.1.138)

Description

The Telegram channel plugin (plugin:telegram@claude-plugins-official) silently stops receiving messages after periods of heavy activity. The Claude Code session remains alive and responsive at the prompt, but no new Telegram messages are delivered. The only fix is to /exit and restart the session.

Environment

• Claude Code version: 2.1.138
• OS: macOS (Darwin 25.3.0, Apple Silicon)
• Launch command: claude --channels plugin:telegram@claude-plugins-official --model claude-opus-4-6 --permission-mode bypassPermissions
• Session type: Long-running tmux session

Reproduction

1. Start a Claude Code session with --channels plugin:telegram@claude-plugins-official
2. Use the session for moderate-to-heavy work (multiple tool calls, file edits, Playwright browser automation, subagent spawns)
3. After the session finishes a burst of work and goes idle at the prompt, new Telegram messages stop being delivered
4. The session itself is alive — you can type commands at the prompt — but the channel listener appears dead
5. /exit and restarting the session restores message delivery

Frequency

This occurred 3 times in 24 hours on the same machine. We run two parallel Claude Code sessions (both with Telegram channels) — one session experienced the issue repeatedly while the other (which received more frequent messages, keeping the connection warm) did not.

Observations

• Not idle timeout: The user regularly goes 7-8 hours overnight without messaging, and this never happened on prior versions (v2.1.133 and earlier).
• Correlates with heavy activity: Each occurrence happened after a burst of tool calls (Playwright, file edits, subagent dispatches), not after pure idle time.
• Context usage may be a factor: Observed at 32%, 46%, and 82% context utilization across the three incidents.
• No error output visible: The tmux pane shows no error messages or stack traces — the plugin just silently stops delivering messages.
• Started with v2.1.138: Previous versions on this machine (v2.1.133, v2.1.128, v2.1.126) did not exhibit this behavior.

Version history on affected machine

2.1.138 — May 9 (current, issue started)
2.1.133 — May 8
2.1.128 — May 5
2.1.126 — Apr 30

Workaround

Monitor the session via tmux capture-pane from another session. When the plugin stops receiving, save context, /exit, and restart.