`--channels plugin:<name>@<marketplace>` never connects the plugin's MCP server (silent, no error)

Status Fixed / completed

Reported on v2.1.218

Maintainer reply None cached

Activity 4 comments · opened Aug 5, 2026 · closed Aug 22, 2026

Environment

Claude Code version: 2.1.218 (Claude Code)
OS: macOS 26.5.2 (BuildVersion 25F84)
Plugin: telegram@claude-plugins-official v0.0.6 (official marketplace plugin)

Summary

When starting a long-running --channels plugin:telegram@claude-plugins-official session, the plugin's MCP server is never connected — no error, no timeout message, nothing. Every other configured MCP server in the same session (both plugin-independent servers like a locally-configured obsidian/firecrawl, and claude.ai-proxy servers like Gmail/Calendar/Drive) connects successfully in the same session. Only the plugin-scoped channel MCP server is silently skipped.

This previously worked correctly on this exact machine/plugin version as recently as 2026-07-28 (confirmed via saved debug logs showing MCP server "plugin:telegram:telegram": Successfully connected (transport: stdio) in 981ms). It stopped working sometime between then and 2026-08-05, with no config change on our end that we can identify.

Reproduction

claude --no-chrome --dangerously-skip-permissions \
  --session-id "$(uuidgen)" \
  --debug-file /tmp/debug.log \
  --channels plugin:telegram@claude-plugins-official

Expected: debug log shows

MCP server "plugin:telegram:telegram": Starting connection with timeout of 30000ms
MCP server "plugin:telegram:telegram": Successfully connected (transport: stdio) in ...ms

Actual: that log line never appears at all, even after 4+ minutes of the session sitting idle. Meanwhile in the same debug log, every other server logs its own "Starting connection" / "Successfully connected" pair normally:

MCP server "obsidian": Starting connection with timeout of 30000ms
MCP server "obsidian": Successfully connected (transport: stdio) in 2433ms
MCP server "firecrawl": Starting connection with timeout of 30000ms
MCP server "firecrawl": Successfully connected (transport: stdio) in 2421ms
MCP server "claude.ai Gmail": Successfully connected (transport: claudeai-proxy) in 2ms
...

telegram simply never appears in this sequence.

What we ruled out

Not plugin cache corruption — fully ran claude plugin uninstall telegram@claude-plugins-official followed by claude plugin install telegram@claude-plugins-official (clean re-fetch from the marketplace, verified installed_plugins.json/cache dir were freshly regenerated). No change — same silent skip.
Not a project-trust gate — hasTrustDialogAccepted for the working directory's .claude.json project entry was false (differs from every other of ~48 project entries on this machine, which are all true); flipped it to true and restarted. No change.
Not a broken server itself — manually drove the plugin's server.ts over stdio with a raw MCP initialize JSON-RPC request (bypassing the CLI entirely) and got a fully valid initialize response with correct capabilities/instructions back in well under a second. The MCP server implementation is fine in isolation.
Not fundamentally un-connectable by the CLI — claude mcp list (a different code path from --channels) run from the same working directory can successfully connect to plugin:telegram:telegram and report ✔ Connected (particularly reliably when --debug-file is also passed to that invocation). So the CLI's general MCP-connection machinery for this exact server works — it's specifically the --channels flag's resolution/spawn path for a plugin-scoped channel name that never initiates the connection.
Not a stale/competing process — verified no other claude --channels or bun run ... telegram/0.0.6 process was running anywhere on the machine at the time of any of the above tests.

Workaround attempted (partially works, but has its own blocker)

Registering the same server as a plain user-scope MCP server (claude mcp add-json telegram '{"type":"stdio","command":"bun","args":["run","--cwd",".../telegram/0.0.6","--shell=bun","--silent","start"]}' -s user) and invoking --channels server:telegram does trigger "telegram": Starting connection... in the debug log — confirming again that the issue is specific to plugin-scoped channel resolution, not the server itself.

However, --channels server:telegram requires the (apparently undocumented) --dangerously-load-development-channels server:telegram flag, which shows an interactive confirmation dialog ("1. I am using this for local development / 2. Exit") on process start with no way to pre-approve it for unattended/headless use — this makes it unusable as a workaround for a long-running unattended daemon (confirmed live: the process hangs indefinitely on this prompt in a headless launchd-managed session).

Impact

This breaks unattended use of any official marketplace plugin that provides a --channels integration (in our case, the telegram plugin) for anyone running Claude Code as a headless daemon. There's no error surfaced anywhere — the session just runs normally with every other MCP server connected, silently missing the one channel-relevant server, which makes this very easy to miss without deliberately grepping --debug-file output line-by-line as we did here.

Ask

Is there a known regression in --channels plugin:<name>@<marketplace> resolution in 2.1.218 (or has something changed server-side, e.g. in marketplace metadata, that this version now mishandles)?
Failing that, is there a supported, non-interactive way to pre-approve --dangerously-load-development-channels for a specific server name, so the server:telegram workaround becomes viable for headless daemons?

Happy to provide the full --debug-file output or any other diagnostics on request.

View original on GitHub ↗

3 Comments

christopherpconway · 2 months ago

Adding a reproduction with a root-cause finding and a working workaround, on macOS (Darwin 25.6.0), telegram@claude-plugins-official 0.0.6.

Same fingerprint as reported: sessions launched with --channels plugin:telegram@claude-plugins-official never spawn the plugin's backing MCP server — no spawn attempt (a diagnostic shim wrapping the server command is never invoked), no mcp-logs-plugin-telegram-telegram/*.jsonl created — while other plugin MCPs (github) spawn normally in the same session. 6/6 consecutive launches failed for us on 2026-08-11.

Eliminated:

CLI version — 2.1.226 and 2.1.227 fail identically (same-day A/B, same flags, same machine). Whatever gates this is not in the binary diff between those builds; notably the same launcher worked for us on 2.1.226 two days earlier.
Model (re #73292) — fails identically under claude-fable-5 and opus, both as --model flag and as the settings.json default. We don't reproduce the model correlation.
Launch mode — fresh session and --resume both fail; terminal wrapper vs direct binary both fail.
Local config — no channel keys anywhere in ~/.claude.json or settings; plugin enabled; flag verified present in argv via ps.

Root cause (for us): the channelsEnabled policy gate, resolved remotely when unset. With no explicit channelsEnabled in any settings file, the effective value comes from the server side — and it evidently flipped off for this (personal Max) account between 2026-08-09 (working) and 2026-08-11 (0/6). Setting it explicitly fixed it deterministically:

{
  "channelsEnabled": true,
  "allowedChannelPlugins": [
    { "marketplace": "claude-plugins-official", "plugin": "telegram" }
  ]
}

First launch after adding this: server spawns, polls, inbound works. Reverting nothing else.

The actionable bug, regardless of the gate's intended default: the denial is completely silent. No error, no log line, no hint in --debug output — the channel just never spawns while the TUI otherwise behaves normally (#81209 notes the status banner even shows it active). One log line — "channel plugin X skipped: channelsEnabled resolved false (source: remote default)" — would have turned a multi-hour elimination hunt into a one-line fix. Related asymmetry: when the plugin runs without --channels, the harness does log its decision ("Channel notifications skipped: server plugin:telegram:telegram not in --channels list for this session"), so the precedent exists.

Happy to provide shim logs, mcp-log jsonl, or account details privately if useful for tracing the remote-default flip.

rahul-kau · 2 months ago

Reproducing on macOS (Darwin 25.5.0) with a slightly different data point that may narrow this down further: the bug persists even after a fresh reinstall of a CLI build that previously worked correctly, which rules out a binary-level regression on this machine and points more strongly at @TheAccidentalCIO's server-side channelsEnabled gate theory.

Setup: headless launchd-managed daemon (telegram@claude-plugins-official v0.0.6), long-running --channels plugin:telegram@claude-plugins-official session.

What I tested today (2026-08-12), each via a full daemon restart against a live --debug-file:

Added the exact channelsEnabled/allowedChannelPlugins block from the comment above to ~/.claude/settings.json. Did not fix it here.
Tested 5 CLI builds with that setting in place: 2.1.218, 2.1.220, 2.1.222, 2.1.224, 2.1.228. All five silently skip plugin:telegram:telegram — zero "Starting connection" log line — while every other MCP server (obsidian, firecrawl, computer-use, all claude.ai-proxy servers) connects normally in the same session, every time.
Most notable: 2.1.218 on this machine logged a clean Successfully connected (transport: stdio) in 964ms for this exact server as recently as 2026-08-05. I ran claude install 2.1.218 to pull a byte-identical fresh copy of that same build today and re-tested — it now fails identically to the others. Nothing local changed between the two tests (same machine, same plugin cache, same settings). This is hard to explain as anything other than a server-side value that changed for this account sometime after 08-05, independent of CLI version.

No channelsEnabled-related log line appears anywhere in --debug-file output on any of the 5 builds, for what it's worth — can't tell from client logs alone whether older builds simply don't read that setting yet, or whether they read it and the server-resolved value still wins.

One incidental finding for anyone else testing across versions: launching a newer build can trigger the CLI's own version-cleanup routine and delete an older pinned binary out from under a script that references it by path (only the "locked" version is protected from that cleanup) — claude install <version> will pull a specific old version back down if that happens.

Happy to share the full --debug-file output if useful.

rahul-kau · 1 month ago

---Update: this is fixed as of 2.1.239.

Re-tested today with the same methodology as my earlier comments (live PTY session, --debug-file, grepping for the plugin:telegram:telegram connection line) on two separate machines under this account:

macOS (Darwin 25.5.0): clean connect, Successfully connected (transport: stdio) in 611ms, channel notifications registered.
Ubuntu 24.04 VPS, systemd-managed daemon, non-root user: same clean connect (262ms), confirmed stable over a real restart cycle with an established TCP connection to Telegram's API afterward — not just a one-off interactive test.

Both had previously failed on every version I tried between 2.1.218 and 2.1.229 (5 separate builds tested on 08-12/08-13, all silent no-connect). Whatever changed between 2.1.228 and 2.1.239 — CLI-side fix or the channelsEnabled server-side gate un-flipping for this account, per @TheAccidentalCIO's theory above — I can't tell from the client side, but the practical result is the bug is gone on current.

If anyone's still hitting this: check npm view @anthropic-ai/claude-code version and confirm you're actually on the latest before assuming it's still this bug — this class of issue can resolve without an update here.

Showing cached comments. Read the full discussion on GitHub ↗