[BUG] --channels mode stops processing incoming messages after first response

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/36411
2. https://github.com/anthropics/claude-code/issues/36472
3. https://github.com/anthropics/claude-code/issues/36431

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Additional context from official plugin docs:

The Telegram plugin README states:

When you message the bot, the server forwards the message to your Claude Code session.

And:

Relaunch with the channel flag... The server won't connect without this

This confirms the intended usage is exactly what I'm doing: claude --channels plugin:telegram@claude-plugins-official should continuously receive and process forwarded messages.

The plugin itself works correctly — it polls Telegram, receives updates, and sends MCP channel notifications. Debug logs show:

MCP server "plugin:telegram:telegram": Channel notifications registered

The issue is that Claude Code's REPL doesn't process these notifications after the first response. It returns to the interactive prompt (❯) and waits for user input instead of processing the next queued notification.

Reproduction verified on: Ubuntu 24.04, Claude Code 2.1.80, Bun 1.3.11, plugin v0.0.1

Codex helped me to fix it. FYI.

Claude Code 2.1.80 Telegram MCP can reply once, then stop receiving inbound messages

• Trigger:
• Telegram reply works, but after that the next Telegram message no longer reaches Claude Code.
• /mcp shows the Telegram server as failed.
• The debug log shows a successful reply tool call, but the Telegram server later logs clean closes such as:
• UNKNOWN connection closed after 4s (cleanly)
• UNKNOWN connection closed after 28s (cleanly)
• Scope:
• Bun-installed Claude Code 2.1.80 on hosts in this repo when using the official Telegram channel plugin over stdio.
• Root cause:
• Claude Code can open an extra tool-only Telegram MCP connection when the shared connection cache is empty.
• That extra client is good enough to send reply, but it is not the app-state channel client that owns notifications/claude/channel.
• Separately, stdio channel clients are marked failed on close instead of being auto-reconnected, and stale close events can poison server state after a newer client already exists.
• Diagnosis path to re-run after future Claude Code updates:
• First separate reply success from inbound delivery failure:
• in the debug log, confirm Calling MCP tool: reply and Tool 'reply' completed successfully both happen.
• then check whether the next inbound Telegram message is missing or only resumes after a manual /mcp reconnect.
• Compare connection sequences around the reply:
• if you see Starting connection immediately before a reply call, but no nearby Channel notifications registered, that connection is likely tool-only.
• if later clean-close lines appear and /mcp flips to failed, inspect whether the close came from an old client instance rather than the current registered channel client.
• Inspect the installed CLI source, not docs:
• search the live cli.js for ZG6, bh, Tl, vk, Channel notifications registered, and the connected-client onclose handler inside the MCP state hook.
• verify whether tool calls prefer the already-connected app-state client, or whether they can silently create a fresh stdio client from cache miss.
• verify whether stdio channel servers auto-reconnect on close, and whether stale onclose events are ignored.
• Temporary local workaround in this repo:
• Keep a live local patch against the Bun-installed Claude Code cli.js so that:
• MCP tool calls reuse the already-connected app-state client when available;
• stale onclose events do not mark a newer Telegram client as failed;
• stdio MCP servers with claude/channel capability auto-reconnect on close.
• Current implementation location:
• ~/.local/share/bun/install/global/node_modules/@anthropic-ai/claude-code/cli.js

Independent Analysis: Plugin-Side Fix Not Possible

I ran Codex against the Telegram plugin source (server.ts) and Claude Code v2.1.81 binary to determine if a workaround exists. Conclusion: No reliable plugin-side fix is possible.

How the Plugin Works

server.ts is a correct stdio MCP server:

• Declares channel capability via experimental: { 'claude/channel': {} }
• Exposes reply, react, and edit_message tools
• Connects once to Claude Code over stdio using StdioServerTransport
• Forwards inbound Telegram messages via notifications/claude/channel
• Shuts down when stdio connection disappears

Each plugin process owns exactly one MCP transport and one JSON-RPC session — this is correct behavior.

Why Plugin Can't Fix It

1. No control over client reuse — The tool-routing decision is entirely in Claude Code core, before any plugin code runs.

1. Cannot prevent stale onclose handlers — That handler is installed in Claude Code core on the client object, not in the plugin.

1. Cannot repair poisoned host-side registry — Once core marks the server failed, the channel notification path is owned by the host; the plugin cannot re-register itself.

1. Keeping plugin alive after stdio closes doesn't help — The host-side pipe is already gone, and core bug is the stale close event changing host state.

1. Singleton daemon approach is outside plugin contract — Claude Code is spawning stdio sessions; the bug is in how core manages those sessions.

Confirmed v2.1.81 Still Broken

Tested today (Mar 21, 2026):

• First message: ✅ Processed and replied
• Second message: ❌ Not processed, Claude waits at prompt
• Two bun server.ts processes running after first reply (duplicate connection bug)
• /mcp shows server as connected but messages don't flow

Required Core Changes

1. Reuse existing channel-capable MCP client for tool calls when one already exists
2. Make onclose state transitions generation-safe so stale clients cannot mark the active client as failed
3. Auto-reconnect stdio channel servers, or preserve channel registration across unintended disconnects

Full analysis: https://gist.github.com/mohfoda1982-create/claude-code-channels-analysis (will upload if helpful)

Try formatting Claude Code "binary" (minified JS) and ask Codex to work on CC. Not plugin

@salty-flower Thanks for the detailed root cause analysis!

I tried having Codex analyze the issue, and it independently confirmed your findings — the bug cannot be fixed in server.ts alone. The fix must be in Claude Code core.

Confirmed on v2.1.81: The bug persists. After one reply, Claude waits at the prompt. Two bun server.ts processes spawn (the duplicate connection issue).

Would you be able to share your actual patch diff? The binary does contain the bundled JS, but manually locating and editing the minified function names (ZG6, bh, Tl, vk) is risky without a reference.

If you have a working patch, it would help the community while we wait for an official fix.

Real-world impact: messages consistently not delivered on first send

I am a daily user of the Telegram channel plugin and can confirm this is a serious UX issue that makes the feature nearly unusable in practice.

Observed behavior:

• Messages sent from Telegram frequently require 2-3 attempts before Claude Code processes them
• The bot correctly reacts with 👀 (confirming the MCP server received the message), but Claude Code never wakes up to respond
• This happens consistently throughout the day, not just on first session start
• Restarting the Claude Code session temporarily helps but the problem returns within minutes

Setup:

• Claude Code v2.1.81
• Telegram plugin v0.0.2 (claude-plugins-official)
• Running in VirtualBox VM on Ubuntu 24.04
• Single user, single session

Impact:
This is supposed to be a productivity tool for remote task execution (calendar, health tracking, network diagnostics, etc.). With unreliable message delivery, every interaction requires manual verification — defeating the purpose entirely.

Request: Please prioritize this fix. The notifications/claude/channel delivery reliability is the foundation of the entire channel feature. Without it, everything else is moot.

Related to #36431 and #36800.

Confirming this on Windows 11, Claude Code with Telegram plugin v0.0.4. First inbound message is delivered and replied to successfully. All subsequent Telegram messages are silently dropped — they never surface in the conversation even though the session remains active.

This matches the root cause described above: after the first reply, the channel notification path breaks and messages are lost.

Setup:

• Windows 11 Pro, Git Bash
• Claude Code (Opus 4.6)
• Telegram plugin v0.0.4
• Single session, single user

+1 for prioritizing the core fix — channel plugins are unusable for any back-and-forth conversation right now.

Windows-specific data point (v2.1.81, Windows 11)

Adding a Windows-specific reproduction to this issue. The behavior on Windows differs slightly from the Linux case above — the session successfully processes 1–3 exchanges before silently dropping messages, rather than failing after the first response. The process does not exit, so auto-restart wrappers cannot recover it.

Environment

• Claude Code: v2.1.81
• OS: Windows 11 (x86_64), ThinkPad
• Plugin: plugin:telegram@claude-plugins-official
• Runtime: Bun (Node.js rejected by plugin)
• Transport: MCP stdio (subprocess)
• Reproducibility: ~90% — occurs in nearly every session

Observed behavior

• Bot processes 1–3 messages successfully, then silently stops
• Process continues running — no exit, no crash dump, no console error
• Telegram getUpdates long-polling continues — messages consumed at network level but never dispatched to Claude Code
• Pressing Enter in the idle Claude Code terminal sometimes resumes delivery (~40% success rate) — consistent with the "waiting at interactive prompt" root cause identified in this thread
• Affects both DMs and group messages

Additional factors on Windows

Beyond the REPL prompt-wait issue identified here, two additional factors may contribute:

1. Duplicate spawn / 409 Conflict (ref #36800): Claude Code spawns a second plugin process ~3 min into a session. On Windows, the restart delay may not be sufficient for Telegram to release the polling lock, causing getUpdates to return 409, which the plugin silently swallows.

1. Windows stdio pipe handling (ref #36964): On Windows, MCP stdio pipe behavior for child processes differs from Unix. If the pipe buffer fills or a write fails, the transport may close silently — this could explain why the Windows failure threshold is 1–3 exchanges rather than after the first response.

Workarounds tried

• Auto-restart PowerShell loop: does not help — process doesn't exit during silent failure
• Manual Ctrl+C and relaunch: restores delivery for next 1–3 exchanges only
• Enter keypress in idle terminal: resumes delivery ~40% of the time

Confirmed the fix must be in Claude Code core, not the plugin — consistent with the analysis above.

Confirming this on v2.1.81 / macOS. Discord DMs — plugin receives inbound messages fine, typing indicator fires, but outbound replies silently don't land. Claude Code shows no error; it believes the reply tool succeeded. Intermittent — works for the first 1-3 exchanges then stops. Restarting claude --channels temporarily fixes it. No telemetry flags set, clean env. This is a critical workflow blocker for anyone using channels as a mobile interface to Claude Code.

@salty-flower Thanks for the detailed root cause analysis! I tried having Codex analyze the issue, and it independently confirmed your findings — the bug cannot be fixed in server.ts alone. The fix must be in Claude Code core. Confirmed on v2.1.81: The bug persists. After one reply, Claude waits at the prompt. Two bun server.ts processes spawn (the duplicate connection issue). Would you be able to share your actual patch diff? The binary does contain the bundled JS, but manually locating and editing the minified function names (ZG6, bh, Tl, vk) is risky without a reference. If you have a working patch, it would help the community while we wait for an official fix.

Sorry for not replying earlier. I was expecting a rapid fix from Anthropic given the apparent cause. Having seen the delay and so many people blocked by this issue, I am happy to provide my patched version, but with an important disclaimer: though it works for me, I can't guarantee its correct working. It's provided as-is without any warranty.

To see the diff, install Claude Code from npm then format it with biome (https://biomejs.dev/). Then diff on your own.

For Anthropic people seeing this - I am happy to take it down anytime given a notice. I do not intend to break your software.

cli.js

We hit this exact bug running 13 AI agents on Discord through Claude Code. The channels plugin stops processing after the first response — bot stays online (green dot) but the brain is dead. No error, no crash, just silence.

We couldn't wait for a fix, so we built a custom MCP server that replaces the channels plugin entirely. The architecture:

• Uses discord.js for a direct WebSocket connection to the Discord gateway (event-driven, not polling)
• Implements a standard MCP server using @modelcontextprotocol/sdk
• Pushes messages to Claude Code via MCP notifications — same protocol as the official plugin, but without the bug
• Exposes tools for reply, fetch_messages, react, and edit_message
• Launch with: claude --dangerously-load-development-channels server:your-server-name

We've been running this in production and it works reliably. We put together an architecture breakdown and a downloadable MCP server template you can adapt:

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

Hope this helps anyone else stuck on this.

MCP server-side data point (custom notifications/claude/channel emitter)

We maintain a custom MCP server that declares claude/channel capability and uses server.server.notification() to push cross-agent messages into Claude Code sessions via notifications/claude/channel.

Findings from a full day of debugging (macOS):

• Tested on v2.1.85 and v2.1.86. Push notifications work reliably on v2.1.85 but are intermittent on v2.1.86.
• server.server.notification() resolves when the MCP SDK transport write completes, NOT when the client renders. Our server marks messages as delivered after the await resolves, but that only proves the server side completed — not that the CLI displayed it.
• Sending multiple notifications in rapid succession (e.g. 5+ agents sending signals within seconds) sometimes causes all of them to render on v2.1.86. Other times, zero arrive. No consistent pattern.
• Any modification to the drain/delivery timing on our side (mutex guards, deferred marking, retry loops) made things worse or broke delivery entirely. Reverting to the original fire-and-forget pattern was the only stable state.
• The <channel> tag payload was verified as correctly formed during debugging.

Conclusion: The issue appears to be in Claude Code's REPL notification listener, not in the MCP transport or server-side emission. The await on notification() completes successfully, but the CLI doesn't always render the event — especially after it returns to the ❯ prompt. Regression between v2.1.85 and v2.1.86.

This affects custom MCP servers using the channel API, not just the official plugins.

Same issue, v2.1.86, macOS Darwin 25.3.0

Running claude --channels plugin:telegram@claude-plugins-official --model sonnet as a persistent Telegram bot via launchd.

Observed behavior:

• First message processes fine, reply is sent successfully
• Subsequent messages are received by the MCP server (visible in plugin logs) but never trigger a new conversation turn
• Process stays alive (not crashed), CPU drops to near zero — Claude Code is simply not picking up channel notifications
• Restarting the process temporarily fixes it (for one message)

Additional findings from our setup:

• KeepAlive: true in launchd auto-restarts the process, but since the process doesn't crash (just hangs), launchd doesn't intervene
• Running via script -q /dev/null (pseudo-TTY wrapper) was needed because without a TTY, Claude Code falls into --print mode and exits with Error: Input must be provided either through stdin or as a prompt argument when using --print
• The PreToolUse hook on mcp__plugin_telegram_telegram__reply throws errors in this environment but doesn't seem to be the root cause of the hang

Workaround we're using: Falling back to a separate grammy-based Telegram bot that calls Claude CLI as a subprocess, which is stable but loses the native channel integration benefits (MCP tools, persistent session, etc.).

This is a blocking issue for using Claude Code as a persistent channel-based bot. Would appreciate any timeline on a fix.

If anyone's looking for an alternative while the built-in channels mode is being fixed — I built telegram-ai-bridge, a standalone Telegram ↔ Claude Code bridge.

Different approach from --channels: it runs as an independent service that forwards Telegram messages to Claude Code CLI sessions, with multi-bot support and A2A (Agent-to-Agent) group chat relay.

• Works with multiple bots in one group chat (A2A message passing via Redis)
• Shared context storage across bots
• No dependency on the built-in channels plugin
• Docker Compose one-click deploy

Repo: https://github.com/AliceLJY/telegram-ai-bridge

I'm running Claude Code (v2.1.87, macOS) as the backbone of a personal AI assistant that communicates via Telegram. Bidirectional messaging is the core use case — it's how I interact with Claude throughout the day.

Outbound works fine. Inbound has been completely dead since at least v2.1.81.

This isn't a minor inconvenience — it makes the entire --channels feature non-functional. I've had to build a custom workaround (PocketBase polling + a watcher script that spawns claude -p) just to get incoming messages processed. That works, but it shouldn't be necessary for what is an officially supported plugin.

What makes this more urgent: this is not a Telegram-specific bug. Discord users report the exact same behavior (#38259). The root cause analysis in this thread (by @salty-flower) identifies 4 separate bugs in Claude Code core — channel name mismatch, stale connection handlers, no reconnection, and duplicate MCP clients. None of these are fixable at the plugin level.

There are now 10+ open issues about this, all describing the same symptoms, with zero response from the Anthropic team. I'd really appreciate some acknowledgment — even just "we're aware and it's on the roadmap" would help those of us who have built workflows around this feature.

Related issues: #36429, #36431, #36472, #36802, #37498, #37633, #37933, #38259

Thank you I will give it a try

On Tue, 31 Mar 2026 at 18:22, basdumoulin @.***> wrote:

basdumoulin left a comment (anthropics/claude-code#36477) <https://github.com/anthropics/claude-code/issues/36477#issuecomment-4162610888> I'm running Claude Code (v2.1.87, macOS) as the backbone of a personal AI assistant that communicates via Telegram. Bidirectional messaging is the core use case — it's how I interact with Claude throughout the day. Outbound works fine. Inbound has been completely dead since at least v2.1.81. This isn't a minor inconvenience — it makes the entire --channels feature non-functional. I've had to build a custom workaround (PocketBase polling + a watcher script that spawns claude -p) just to get incoming messages processed. That works, but it shouldn't be necessary for what is an officially supported plugin. What makes this more urgent: this is not a Telegram-specific bug. Discord users report the exact same behavior (#38259 <https://github.com/anthropics/claude-code/issues/38259>). The root cause analysis in this thread (by @salty-flower <https://github.com/salty-flower>) identifies 4 separate bugs in Claude Code core — channel name mismatch, stale connection handlers, no reconnection, and duplicate MCP clients. None of these are fixable at the plugin level. There are now 10+ open issues about this, all describing the same symptoms, with zero response from the Anthropic team. I'd really appreciate some acknowledgment — even just "we're aware and it's on the roadmap" would help those of us who have built workflows around this feature. Related issues: #36429 <https://github.com/anthropics/claude-code/issues/36429>, #36431 <https://github.com/anthropics/claude-code/issues/36431>, #36472 <https://github.com/anthropics/claude-code/issues/36472>, #36802 <https://github.com/anthropics/claude-code/issues/36802>, #37498 <https://github.com/anthropics/claude-code/issues/37498>, #37633 <https://github.com/anthropics/claude-code/issues/37633>, #37933 <https://github.com/anthropics/claude-code/issues/37933>, #38259 <https://github.com/anthropics/claude-code/issues/38259> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/36477?email_source=notifications&email_token=B5JUCG2H2FBUWAKJNUQ2IBL4TPBATA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJWGI3DCMBYHA4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4162610888>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5JUCG7J4NN3PLRYMEESP3L4TPBATAVCNFSM6AAAAACWYW2OIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNRSGYYTAOBYHA> . You are receiving this because you commented.Message ID: @.***>

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?

Upvoting this as still a big issue. I manage a lot of my day-to-day through Telegram. I have Claude Code running in tmux on a Raspberry Pi and have followed the setup fully. It appears to be a complete conflip as to when my replies via Telegram are actually acknowledged and received by Claude. Claude can tell messages are dropping, as when one finally goes through after a period of drops, there will be a big gap in the message IDs that it's receiving. I've tried a bunch of workarounds, but really all that "works" is having this session also be always on with remote control, and just using that to nudge. Then the replies go back to Telegram and I can get a little further until it breaks again. So, in actuality, I should just fully use Remote Control instead and ditch Telegram.

Please fix!!!

Found a working patch for v2.1.92.

Root cause: the queue subscriber in zqO short-circuits when idle — Z (AbortController) is undefined, so the if(Z && ...) check fails immediately. Additionally, bE8("now") filters for priority ≤ 0 but channel items use priority 1 ("next"). So channel notifications get pushed to the queue via Fj() but are never consumed.

Fix (27 chars added):

// Before:
hN6(()=>{if(Z&&bE8("now").length>0)Z.abort("interrupt")})

// After:
hN6(()=>{if(Z&&bE8("now").length>0)Z.abort("interrupt");else if(!Z&&!X&&sa6())W6()})

When queue changes and idle (Z undefined, X false) and items exist (sa6()), start processing (W6()). The if(X) return guard inside W6 prevents double-entry.

Apply (Node.js):

node -e "
const fs = require('fs');
const f = '/path/to/node_modules/@anthropic-ai/claude-code/cli.js';
const old = 'hN6(()=>{if(Z&&bE8(\"now\").length>0)Z.abort(\"interrupt\")})';
const rep = 'hN6(()=>{if(Z&&bE8(\"now\").length>0)Z.abort(\"interrupt\");else if(!Z&&!X&&sa6())W6()})';
let code = fs.readFileSync(f, 'utf8');
if (!code.includes(old)) { console.error('NOT FOUND'); process.exit(1); }
fs.writeFileSync(f, code.replace(old, rep));
console.log('Patched');
"

To find in other versions: function names are minified per version. Search for bE8("now").length>0 (or equivalent pattern matching a queue filter check inside a subscriber callback).

Tested 1+ hour with continuous Telegram back-and-forth. Zero deaf incidents. Previously went deaf within 1-5 minutes.

Environment: Claude Code v2.1.92, --channels plugin:telegram@claude-plugins-official, headless Linux LXC, --dangerously-skip-permissions.

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.

Not reproducing on Claude Code v2.1.195 (Opus 4.8), tested 2026-06-28.

Setup: claude --channels plugin:fakechat@claude-plugins-official (the official localhost test channel), cwd = a normal git repo.

What I did — sent several messages with deliberate idle gaps and watched whether the session keeps waking up after the first reply:

| # | message | gap since previous reply | replied? |
|---|---------|--------------------------|----------|
| 1 | test1 → тест 1 → тест 2 (initial burst) | — | ✅ (two separate bot replies) |
| 2 | тист 3 | ~37s, session fully idle | ✅ |
| 3 | image attachment (.webp) | idle | ✅ (read + described it) |
| 4 | a URL | idle | ✅ |

Every message after the first got a response, including 3 cold wake-ups after the session had gone fully idle (30s+ gaps), plus an image attachment and a URL. I could not reproduce the "stops processing after the first response" behaviour at all.

So on v2.1.195 + the fakechat channel this looks fixed (or at least not reproducing). Caveat: only ~5 messages over ~2 min on localhost — I didn't stress-test long-running stability or other channel plugins (Telegram / custom server).