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

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.