Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Channel notification handler stops surfacing inbound messages after ~2-3h (Docker/Linux) [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#47112•Fetched 2026-04-13 05:41:08
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
3koozy3koozy
Participants
3koozy3koozygithub-actions[bot]github-actions[bot]
Timeline (top)
labeled ×5commented ×1cross-referenced ×1

Root Cause

  • anthropics/claude-code#46744 and #46016 describe "inbound never works" — those may be caused by the plugin poll-loop crash (now fixed in anthropics/claude-plugins-official#1377)
  • This issue is specifically about time-based degradation: inbound works initially but stops after ~2-3 hours, with strace/ss evidence proving the plugin is still alive and polling

Fix Action

Workaround

Restart the Claude Code session every ~2 hours. This resets the notification handler and inbound messages work again.

Code Example

$ ss -tnp | grep bun
ESTAB 0 0 172.x.x.x:36950  149.154.166.110:443  users:(("bun",pid=74,fd=17))
ESTAB 0 0 172.x.x.x:50600  149.154.166.110:443  users:(("bun",pid=74,fd=16))

---

$ timeout 10 strace -p 74 -e trace=network,write,read -f
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000017           2         8           write
------ ----------- ----------- --------- --------- ----------------

---

$ curl -fsS https://api.telegram.org/bot$TOKEN/getMe
✅ Bot API reachable (329ms)

$ curl -fsS https://api.telegram.org/bot$TOKEN/getWebhookInfo
✅ No webhook set, pending_update_count: 0

---

Total: 18  |  Sockets: 7  |  Pipes: 0
RAW_BUFFERClick to expand / collapse

Bug Description

Claude Code's internal handler for notifications/claude/channel events stops surfacing inbound Telegram messages after approximately 2–3 hours in long-running sessions on Docker/Linux. The Telegram plugin remains alive and actively polling — this is a Claude Code-side bug, not a plugin bug.

Important: This is a separate bug from the plugin poll-loop crash (which we fixed in anthropics/claude-plugins-official#1377). That fix keeps the plugin alive; this bug causes Claude Code itself to silently drop the notifications the plugin sends.

Environment

  • Claude Code: latest (tested over multiple versions)
  • Plugin: telegram@claude-plugins-official 0.0.5 (with poll-loop retry fix applied)
  • OS: Debian bookworm-slim in Docker container on Linux host
  • Runtime: Bun (plugin), Node.js 22 (Claude Code)
  • Does NOT reproduce on Windows native (same plugin, same Claude Code version)

Evidence

During the stall — plugin is alive and actively polling

$ ss -tnp | grep bun
ESTAB 0 0 172.x.x.x:36950  149.154.166.110:443  users:(("bun",pid=74,fd=17))
ESTAB 0 0 172.x.x.x:50600  149.154.166.110:443  users:(("bun",pid=74,fd=16))

2 ESTABLISHED TCP connections to Telegram's API servers. The plugin is connected and polling.

strace confirms active write syscalls

$ timeout 10 strace -p 74 -e trace=network,write,read -f
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000017           2         8           write
------ ----------- ----------- --------- --------- ----------------

The plugin is actively writing (8 write syscalls in 5 seconds) — these are mcp.notification() calls being written to the MCP stdio socket. Claude Code receives them but does not surface them.

Outbound MCP tools still work

During the stall, calling the reply tool from Claude Code successfully sends messages to Telegram. This proves:

  • The MCP stdio pipe (stdin/stdout sockets) is healthy in both directions
  • The plugin process is responsive to MCP tool calls
  • Network connectivity to api.telegram.org is working

Bot API probe during stall

$ curl -fsS https://api.telegram.org/bot$TOKEN/getMe
✅ Bot API reachable (329ms)

$ curl -fsS https://api.telegram.org/bot$TOKEN/getWebhookInfo
✅ No webhook set, pending_update_count: 0

FD inspection confirms healthy process

Total: 18  |  Sockets: 7  |  Pipes: 0

Plugin has 7 socket FDs (MCP stdio + TCP to Telegram) — fully operational.

What we ruled out

HypothesisEvidence against it
Plugin poll-loop crashedstrace shows active syscalls, ss shows ESTABLISHED sockets
Network/DNS issueBot API probe succeeds, curl works, Gmail MCP works indefinitely
Docker NAT / vpnkitGmail MCP (same Docker network) works for hours
IPv6 routing failureDisabled IPv6 entirely, stall persists
TCP keepalive timeoutsAdded aggressive keepalives (60s), stall persists
Webhook conflictgetWebhookInfo confirms no webhook
Plugin process diedProcess alive with 3h+ uptime

Reproduction steps

  1. Run Claude Code in a Docker container (Debian-based, Linux host)
  2. Start with --channels plugin:telegram@claude-plugins-official
  3. Verify inbound Telegram messages work (send a DM to the bot)
  4. Wait ~2-3 hours (leave session idle or active — both reproduce)
  5. Send another DM to the bot
  6. Observe: no <channel source="telegram"> tag appears in the conversation
  7. Verify outbound still works: call the reply tool — message arrives in Telegram
  8. Verify plugin is alive: ss -tnp | grep bun shows ESTABLISHED connections

Expected behavior

notifications/claude/channel events should be surfaced for the entire lifetime of the session, not just the first 2-3 hours.

Workaround

Restart the Claude Code session every ~2 hours. This resets the notification handler and inbound messages work again.

Difference from existing issues

  • anthropics/claude-code#46744 and #46016 describe "inbound never works" — those may be caused by the plugin poll-loop crash (now fixed in anthropics/claude-plugins-official#1377)
  • This issue is specifically about time-based degradation: inbound works initially but stops after ~2-3 hours, with strace/ss evidence proving the plugin is still alive and polling

Related

  • anthropics/claude-plugins-official#1377 — PR fixing the plugin-side poll-loop crash (separate bug)
  • anthropics/claude-code#46744 — Telegram plugin: inbound messages not delivered
  • anthropics/claude-code#46016 — similar
  • anthropics/claude-code#46356 — similar

🤖 Generated with Claude Code

extent analysis

TL;DR

The most likely fix for the issue of Claude Code stopping to surface inbound Telegram messages after 2-3 hours is to identify and address the root cause of the time-based degradation, potentially related to the handling of notifications/claude/channel events.

Guidance

  • Investigate the Claude Code's event handling mechanism to identify potential issues that could cause the time-based degradation of notifications/claude/channel events.
  • Review the code for any timeouts, caching, or other mechanisms that could be causing the notification handler to stop working after 2-3 hours.
  • Consider adding logging or debugging statements to the Claude Code to gather more information about the issue and help identify the root cause.
  • Verify that the issue is not related to the Docker or Linux environment by testing the Claude Code on a different platform or in a native environment.

Example

No specific code example can be provided without more information about the Claude Code's implementation, but a potential debugging approach could involve adding logging statements to the event handling mechanism to track when and how notifications/claude/channel events are being processed.

Notes

The issue seems to be specific to the Claude Code's handling of notifications/claude/channel events and does not appear to be related to the Telegram plugin or the Docker/Linux environment. However, without more information about the Claude Code's implementation, it is difficult to provide a more specific solution.

Recommendation

Apply a workaround by restarting the Claude Code session every 2 hours to reset the notification handler, while continuing to investigate and address the root cause of the issue. This will ensure that inbound Telegram messages continue to work, even if the underlying issue is not yet resolved.

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…

FAQ

Expected behavior

notifications/claude/channel events should be surfaced for the entire lifetime of the session, not just the first 2-3 hours.

#api#indexing error#inference speed#output truncation#response parsing

Still need to ship something?

×6

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

Back to top recommendations

TRENDING