Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Telegram channels plugin polling loop dies silently, no reconnect — message delivery stops permanently [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#53335•Fetched 2026-04-26 05:18:24
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
RealDoctorMixRealDoctorMix
Participants
github-actions[bot]github-actions[bot]RealDoctorMixRealDoctorMix
Timeline (top)
labeled ×4commented ×1

Error Message

The agent itself doesn't crash. The Telegram → agent message path simply breaks invisibly. There is no log line, no error message, and no UI indication that delivery has stopped. From the user's perspective, the bot has just gone dead.

Error Messages/Logs

There are no error messages — that is part of the bug. The journal / stdout / stderr show nothing when the polling loop dies.

Root Cause

Workaround for affected operators: an external watchdog that periodically counts outbound connections from the claude PID and restarts the service when the count drops to 0. Belt-and-braces only — root cause is in the plugin.

Fix Action

Fix / Workaround

Workaround for affected operators: an external watchdog that periodically counts outbound connections from the claude PID and restarts the service when the count drops to 0. Belt-and-braces only — root cause is in the plugin.

Code Example

There are no error messages — that is part of the bug. The journal / stdout / stderr show nothing when the polling loop dies.
Diagnostic evidence captured externally:
Process is alive and healthy after the failure:
$ pgrep -fa claude
NNNNN /usr/bin/claude --channels plugin:telegram@claude-plugins-official --dangerously-skip-permissions

$ ps -o stat,wchan -p NNNNN
STAT WCHAN
Ssl+ ep_pol
Normal Node.js event-loop wait state — process is doing nothing, waiting on epoll.
Zero outbound connections to Telegram:
$ ss -tnp | grep "pid=NNNNN" | wc -l
0
At startup, the same query returned ~9 connections (the expected number for the plugin's polling + Anthropic API). They drop to 0 over time and never come back.
Direct stdin still works:
Writing to the agent's stdin via tmux send-keys (or any equivalent) reaches the input handler and the agent processes the prompt normally. Only the Telegram → agent message path is broken.
Telegram has the messages:
DMs sent from the allowlisted user show double-tick delivery in the Telegram client. The plugin simply isn't pulling them.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

When running Claude Code with --channels plugin:telegram@claude-plugins-official, the plugin establishes outbound TCP connections to Telegram on startup, delivers DMs successfully for a short window, then silently stops polling. Outbound connections drop from ~9 to 0 with no reconnect attempt. The agent process remains alive and responsive (verified via direct stdin), but no further DMs from the allowlisted user reach the agent's input prompt. The agent itself doesn't crash. The Telegram → agent message path simply breaks invisibly. There is no log line, no error message, and no UI indication that delivery has stopped. From the user's perspective, the bot has just gone dead.

What Should Happen?

The plugin should either:

Maintain a robust polling loop with automatic reconnect on transient failures (network blip, Telegram-side timeout, etc.), or Surface the disconnect to the agent / user, so the human knows delivery has stopped

Currently it does neither — the disconnect is invisible. For a documented primary interaction surface on a paid product, silent failure is a bad failure mode.

Error Messages/Logs

There are no error messages — that is part of the bug. The journal / stdout / stderr show nothing when the polling loop dies.
Diagnostic evidence captured externally:
Process is alive and healthy after the failure:
$ pgrep -fa claude
NNNNN /usr/bin/claude --channels plugin:telegram@claude-plugins-official --dangerously-skip-permissions

$ ps -o stat,wchan -p NNNNN
STAT WCHAN
Ssl+ ep_pol
Normal Node.js event-loop wait state — process is doing nothing, waiting on epoll.
Zero outbound connections to Telegram:
$ ss -tnp | grep "pid=NNNNN" | wc -l
0
At startup, the same query returned ~9 connections (the expected number for the plugin's polling + Anthropic API). They drop to 0 over time and never come back.
Direct stdin still works:
Writing to the agent's stdin via tmux send-keys (or any equivalent) reaches the input handler and the agent processes the prompt normally. Only the Telegram → agent message path is broken.
Telegram has the messages:
DMs sent from the allowlisted user show double-tick delivery in the Telegram client. The plugin simply isn't pulling them.

Steps to Reproduce

  1. Pair the Telegram plugin per docs (bot token in ~/.claude/channels/telegram/.env, allowlist in ~/.claude/channels/telegram/access.json with dmPolicy: "allowlist")
  2. Launch: claude --channels plugin:telegram@claude-plugins-official --dangerously-skip-permissions
  3. Send a DM from the allowlisted Telegram user — delivers correctly, agent responds in the chat
  4. Wait 10–30 minutes (the exact trigger condition is unclear — possibly any transient network event, possibly a Telegram-side long-poll timeout)
  5. Send another DM — never reaches the agent. The Telegram client shows double-ticks (delivered to Telegram's servers) but the bot does not respond.
  6. Verify: ss -tnp | grep "pid=$(pgrep -f 'claude --channels')" returns no rows. The plugin has stopped polling entirely.

The agent is otherwise fully alive — tmux send-keys (or any direct stdin path) into the running session still produces normal responses. What I've ruled out

Environment variables (PATH, BUN_INSTALL, HOME, USER, TERM, LANG) — all set correctly TTY allocation — agent has a real PTY (verified Ssl+ foreground state) Pairing state — access.json and .env are intact, mode 600, correct allowlist DNS — getent hosts api.telegram.org resolves Authentication — credentials at ~/.claude/.credentials.json are valid (Max OAuth, future expiry) --dangerously-skip-permissions flag — symptom occurs both with and without systemd sandboxing — symptom reproduces under standalone tmux launch with no sandbox at all

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

N/A

Claude Code Version

2.1.117

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

Hypothesis: The plugin's polling loop has no reconnect-on-disconnect logic. When the connection to Telegram's long-poll endpoint drops, the loop exits and is never restarted. The agent process doesn't crash — it just stops listening on that channel.

Workaround for affected operators: an external watchdog that periodically counts outbound connections from the claude PID and restarts the service when the count drops to 0. Belt-and-braces only — root cause is in the plugin.

Plugin version: claude-plugins-official/[email protected] (cached at ~/.claude/plugins/cache/claude-plugins-official/telegram/0.0.6/)

Severity: Medium. The agent itself is unaffected, alternative input channels work, but Telegram is the documented primary interaction surface for --channels mode and silently failing without telemetry is a bad failure mode for a paid product.

Terminal context: running headless under systemd, claude wrapped in a detached tmux session, no interactive terminal. PTY provided by tmux. TERM=xterm-256color.

extent analysis

TL;DR

Implement a reconnect mechanism in the Telegram plugin's polling loop to handle transient connection drops.

Guidance

  • Verify the hypothesis that the polling loop exits when the connection to Telegram's long-poll endpoint drops by checking the plugin's code for reconnect-on-disconnect logic.
  • Consider implementing an external watchdog to periodically count outbound connections from the claude PID and restart the service when the count drops to 0 as a temporary workaround.
  • Review the claude-plugins-official/telegram plugin code (version 0.0.6) to identify the root cause of the silent failure and implement a fix.
  • Test the plugin with a reconnect mechanism to ensure it can handle transient network events and Telegram-side timeouts.

Example

No code example is provided as the issue does not include the relevant plugin code. However, a potential solution could involve modifying the polling loop to include a reconnect mechanism, such as:

// Pseudo-code example
while (true) {
  try {
    // Establish connection to Telegram's long-poll endpoint
    const connection = establishConnection();
    // Poll for updates
    pollForUpdates(connection);
  } catch (error) {
    // Handle connection drop and reconnect
    console.error('Connection dropped, reconnecting...');
    await reconnect();
  }
}

Notes

The provided information suggests that the issue is specific to the claude-plugins-official/telegram plugin (version 0.0.6) and may not be a regression. The root cause is likely the lack of reconnect-on-disconnect logic in the plugin's polling loop.

Recommendation

Apply a workaround by implementing an external watchdog to periodically count outbound connections from the claude PID and restart the service when the count drops to 0. This will mitigate the issue until a fix can be implemented in the plugin.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#environment variable#API middleware#SSR setup#ISR setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Telegram channels plugin polling loop dies silently, no reconnect — message delivery stops permanently [1 comments, 2 participants]