Telegram channel stops processing inbound messages after completing a turn

This is blocking production usage for us. After every turn completes,
the session stops processing new Telegram messages entirely until
manual terminal input is given. The only workaround is /mcp reconnect
or pressing Enter — neither is acceptable for an always-on bot setup.

Please prioritize this fix. The root cause has already been analyzed
in #36477 by @salty-flower. This needs to be addressed in the main
REPL loop to process channel notifications even when idle between turns.

This is related to the channels bug in #36477 — the Discord channels plugin stops processing after the first response in v2.1.85.

We built a custom MCP server that replaces the broken channels plugin entirely. It connects directly to the Discord gateway via discord.js (event-driven, no polling) and pushes messages to Claude Code through the standard MCP notification protocol.

We've been running it in production across 13 AI agents on Discord. Full architecture breakdown and a downloadable template here:

https://www.MetroPointTechnology.com/claude-discord-fix

I am experiencing similar issues. Telegram is unreliable, and I have to message claude 3-5 times and each time pray that it will respond on Telegram

Same experience here on Telegram (Claude Code v2.1.87, macOS). Outbound messages work, inbound completely dead.

This is the same root cause as #36477, where @salty-flower identified 4 core bugs: channel name mismatch, stale MCP connection handlers, no auto-reconnect, and duplicate client instances. The fact that both Telegram and Discord are affected confirms this is a platform-level issue in how Claude Code handles channel notifications — not plugin-specific.

10+ open issues, same symptoms, zero Anthropic response so far. Would love to see this acknowledged.

Same experience here on Mac Tahoe 26.2, Claude Code v2.1.91.
Why is Claude advertising that they shipped this feature when it is clearly not working AT ALL?

Workaround: use --dangerously-load-development-channels server:<name> instead of --channels plugin:<name>@<marketplace>

We've confirmed that the --channels plugin:telegram@claude-plugins-official path does not deliver inbound notifications/claude/channel to the session, while a bare .mcp.json server entry with --dangerously-load-development-channels works end-to-end on the same machine, same token, same Claude Code version (2.1.92).

Steps

1. Add the plugin's MCP server directly to your project's .mcp.json (or ~/.claude.json for global):

{
  "mcpServers": {
    "telegram": {
      "command": "bun",
      "args": [
        "run", "--cwd",
        "/Users/<you>/.claude/plugins/cache/claude-plugins-official/telegram/0.0.4",
        "--shell=bun", "--silent", "start"
      ]
    }
  }
}

(Adjust the version path to match your cached plugin version.)

1. Launch with the development flag instead of --channels:

claude --dangerously-load-development-channels server:telegram

1. Send a message from Telegram — it arrives as a <channel source="telegram" ...> tag and Claude responds via the reply tool.

Why this works

The --dangerously-load-development-channels server:<name> flag activates channel routing for a bare MCP server entry (keyed by the name in .mcp.json). It bypasses the plugin resolution + allowlist path that --channels plugin:<name>@<marketplace> uses. The MCP server itself is identical — same binary, same capability negotiation — but the CLI-side activation path is different and apparently not affected by the bug.

Environment

• Claude Code 2.1.92
• macOS 15.4 (Darwin 25.3.0, arm64)
• Telegram plugin 0.0.4
• Auth: claude.ai OAuth (not API key)

This also works for Discord and custom channel servers — any plugin that advertises experimental.claude/channel can be registered as a bare .mcp.json entry and activated with --dangerously-load-development-channels server:<name>.

Update: We've published a full Rust drop-in replacement for the official Bun-based Telegram plugin: hdcd-telegram (v0.1.0).

• 3.5 MB static binary vs ~100 MB Bun runtime
• ~5 MB RAM per instance vs ~100 MB
• <50 ms startup vs 2-3 seconds
• Immediate shutdown on stdin EOF (no zombie 409 Conflict)
• Full feature parity: all 8 message types, 4 tools, access control, permission relay, voice transcription via whisper
• Compatible with existing access.json and .env — zero migration

Works with the --dangerously-load-development-channels server:telegram workaround described above. Pre-built binaries for Linux, macOS (Intel + Apple Silicon), and Windows available on the releases page.

I confirm that the @maciek-hyperdev solution worked for me

Still reproducing on Claude Code 2.1.109 + telegram plugin 0.0.6 (commit 79caa0d), macOS Darwin 25.4 (Apple Silicon). Inbound went silent again today after one completed turn — same pattern as the original report. Not fixed in 0.0.6.

Setup: claude running inside a detached tmux session, started/restarted by a LaunchAgent watchdog every 5 min. (Note: the --channels plugin:<name>@<marketplace> flag was removed in 2.1.105 — the plugin now auto-loads from enabledPlugins in settings.json.)

Repro:

1. Start the session, send a Telegram message — works.
2. Wait for the turn to complete fully (assistant returns to idle, no tool calls in flight).
3. Send a second message. A significant fraction of the time it never arrives in the session. Outbound works (scheduled scripts using the same bot token can still sendMessage).

Workarounds we run (all needed together; none is sufficient alone):

• Idle nudge: every 2 min, watchdog sends Escape + Enter to the tmux pane if no screen change. Unsticks ~80% of cases without a full restart.
• Orphan-consumer avoidance (per #38098): set "enabledPlugins": { "telegram@claude-plugins-official": false } in ~/.claude/settings.json and override to true in the channel project's .claude/settings.local.json. Prevents every other CC instance on the machine from spawning a competing getUpdates consumer that drain-steals messages.
• Hard restart with --continue: if the session is idle >10 min with no screen change, kill+restart and resume context.

Local gotcha worth flagging (not an upstream bug, but it broke us for weeks): tmux constructs its socket as $TMUX_TMPDIR/tmux-$UID/default. If your watchdog sets TMUX_TMPDIR=/private/tmp/tmux-501, it ends up looking at /private/tmp/tmux-501/tmux-501/default — which never exists, so the watchdog believes the session is dead and crash-loops it every 2 min. Correct value is TMUX_TMPDIR=/private/tmp.

Second local gotcha: a stale Homebrew claude symlink pinned at v1.0.6 on /opt/homebrew/bin/claude will be silently preferred over an nvm-installed 2.1.x by a LaunchAgent that doesn't inherit nvm's PATH. v1.0.6 exits immediately with "needs update" → tmux tears down the pane → watchdog crash-loops. Pin an absolute CLAUDE_BIN path in the watchdog.

Confirming @maciek-hyperdev's finding: the bug is specifically in the plugin-channel activation path (was --channels plugin:..., now the auto-load path). A plain .mcp.json + --dangerously-load-development-channels server:telegram does not exhibit the silent-inbound failure. So the plugin code itself is fine — it's the CLI-side activation/notification routing that drops inbound notifications/claude/channel between turns.

Would really appreciate any acknowledgement that this is being looked at — a month with no Anthropic response across #38259, #38098, and #36477, all describing the same root issue.

Follow-up: switched to @maciek-hyperdev's hdcd-telegram v0.1.2 drop-in with --dangerously-load-development-channels server:telegram on Claude Code 2.1.110, macOS arm64. Channel is responsive again — inbound messages land reliably, outbound reply works, no 409 Conflict / zombie process issues. Retiring the bun plugin entirely (enabledPlugins: false globally). Confirming the workaround fix.

One gotcha for anyone copying this: the --dangerously-load-development-channels confirm prompt shows on every launch (not sticky), so any tmux/LaunchAgent restart script has to auto-ack it — grep for "development channels" case-insensitive and send Enter.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.