Channel notification handler stops surfacing inbound messages after ~2-3h (Docker/Linux)

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

| Hypothesis | Evidence against it |
|---|---|
| Plugin poll-loop crashed | strace shows active syscalls, ss shows ESTABLISHED sockets |
| Network/DNS issue | Bot API probe succeeds, curl works, Gmail MCP works indefinitely |
| Docker NAT / vpnkit | Gmail MCP (same Docker network) works for hours |
| IPv6 routing failure | Disabled IPv6 entirely, stall persists |
| TCP keepalive timeouts | Added aggressive keepalives (60s), stall persists |
| Webhook conflict | getWebhookInfo confirms no webhook |
| Plugin process died | Process 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