Channel plugin MCP (plugin:telegram) fails to spawn at session start after official-marketplace refresh; /mcp Reconnect fixes it

Status Open

Reported on v2.1.212

Maintainer reply ✓ Yes — bcherny

Activity 3 comments · opened Jul 18, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Summary

After the official plugin marketplace (claude-plugins-official) refreshes on disk, the channel plugin MCP server (plugin:telegram:telegram) fails to spawn at session start — or takes minutes to come up. A manual /mcp → select server → Reconnect revives it instantly every time. Observed twice in one day, each occurrence starting immediately after a marketplace refresh.

Environment

macOS (Apple Silicon), Claude Code 2.1.212 and 2.1.214 (native install, ~/.local/share/claude/versions/…)
Plugin: telegram@claude-plugins-official 0.0.6 (bun-based channel plugin)
Sessions started headless in tmux with --channels plugin:telegram@claude-plugins-official

Symptom

Session boots normally, banner shows "Channels (experimental) messages from plugin:telegram@claude-plugins-official inject directly in this session".
The plugin MCP process (bun run --cwd <plugin> … start) is never spawned — no child process, and notably no per-session log file is created under ~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-plugin-telegram-telegram/ (normally a file appears with "Starting connection…"). The failure appears to happen before the connection attempt is logged.
/mcp shows plugin:telegram:telegram · ✘ failed.
Model-independent (reproduced with two different --model values) and version-independent (reproduced on both 2.1.212 and 2.1.214).

Correlation

Two occurrences, both starting immediately after the marketplace metadata on disk changed:

First occurrence began ~17:04Z 2026-07-17; a refresh of claude-plugins-official landed 17:04:48Z. Sessions started 16:17–16:21Z the same morning connected fine ("Successfully connected in 195ms") on the same binary.
Second occurrence began ~01:26Z 2026-07-18, right after ~/.claude/plugins/marketplaces/claude-plugins-official was (re-)cloned at 01:26Z (officialMarketplaceAutoInstalled flipped true; the telegram plugin now lives under external_plugins/ in the new snapshot, still version 0.0.6, .mcp.json unchanged). The still-running sessions from before the refresh kept working; every session started after it came up with the failed plugin MCP.

Workarounds found

/mcp → select the failed server → Reconnect: works instantly, every time.
Waiting also (sometimes) works: one session spawned the plugin ~3 minutes after boot.
Restarting the CLI session does not help — fresh sessions come up in the same failed state, which is nasty for unattended/headless bots whose supervision reacts to a dead channel by restarting the session.

Impact

Headless channel-plugin sessions (Telegram bots) come up deaf after any marketplace refresh, and restart-based supervision makes it worse. A retry of the initial plugin MCP spawn (the same code path Reconnect uses) would fix it.

Aside

While debugging we also noticed the freshly installed 2.1.214 binary re-points the ~/.local/bin/claude symlink to itself when an older pinned version is launched — intentional self-repair presumably, but it makes version-pinning via the symlink impossible; mentioning in case it's not intended.

View original on GitHub ↗

3 Comments

bcherny collaborator · 1 month ago

Reproduced the core failure on the released 2.1.233 build (Linux, fresh config dir, telegram@claude-plugins-official 0.0.7).

First session after installing the plugin: the plugin MCP spawned normally — a per-session log file appeared with "Starting connection…".
Then I ran a marketplace update and started several more sessions with --channels plugin:telegram@claude-plugins-official: the plugin itself loads (skills/commands register), but its MCP server is never spawned — no per-session log file is created at all, exactly the signature you describe — while other plugin MCP servers in the same sessions connect fine.
The failure persisted across multiple fresh sessions and a reinstall attempt, matching your "restarting doesn't help" observation.

Debug output shows plugin resolution finishing after the point where plugin MCP servers are started in these sessions, which fits your observation that a manual Reconnect (which starts the server on demand) revives it instantly.

Marking as reproduced — a retry of the initial plugin-MCP spawn after plugin resolution settles looks like the right shape of fix.

🤖 Generated with Claude Code

oskarmodig · 1 month ago

Same failure on 2.1.239 (macOS, Apple Silicon), with one detail that may narrow the blast radius: the affected plugin does not come from the refreshed marketplace.

Our plugin (modig-mesh@modig) is installed from a local directory marketplace (source: directory, symlinked into a checkout) and its .mcp.json / manifest were untouched. What refreshed was claude-plugins-official — ~/.claude/plugins/marketplaces/claude-plugins-official mtime 04:02, .last_inuse_sweep 04:02:44 local. Three minutes later every new session lost our plugin's MCP server. So a refresh of marketplace A appears to break plugin MCP spawn for a plugin from marketplace B in the same session.

Fleet-scale repro with a sharp cutoff. 13 headless tmux sessions restarted sequentially, ~16 s apart, identical flags (--permission-mode=auto --chrome --add-dir … --channels plugin:modig-mesh@modig), all started --fresh:

| Session start (local) | Plugin MCP |
|---|---|
| 04:01:06 · 04:01:21 · 04:01:37 · 04:01:54 · 04:04:42 · 04:05:01 | spawned |
| 04:05:19 · 04:05:34 · 04:08:56 · 04:09:13 · 04:09:29 · 04:09:45 · 04:10:47 | never spawned |

Cutoff between 04:05:01 and 04:05:19. Nothing differs but start time.

Signature matches yours exactly: no per-session log file under mcp-logs-plugin-modig-mesh-mesh/, and in --debug output there is no MCP server "plugin:modig-mesh:mesh" line at all — no start, no timeout, no error — while claude-in-chrome, claude.ai Gmail and a project-level stdio MCP server connect normally in the same session. claude plugin list reports the plugin enabled, and claude mcp list reports the server ✔ Connected (same as #82557), i.e. the CLI-level check passes while the session registry never gets it.

Two additions to the "restarting doesn't help / waiting sometimes works" observations:

Recovery came on its own after ~70 minutes, not from restarts. Sessions restarted at 04:11, 04:12, 04:15–04:17 and ~04:25 all came up without the server (that's 3 attempts per session, 0 recoveries); sessions restarted 05:15–05:28 all got it.
In-session type matters at the same moment in time. At 08:19 a one-shot claude -p 'ok' --channels … in a scratch directory spawned the server (log file created); at 08:20 and 08:24 interactive sessions with the same flags in the same directory did not, and at 08:25 an interactive session in that same scratch directory did not either. So during a failure window, the one-shot path can still start the server while interactive sessions cannot — which fits your note that plugin resolution finishes after the point where plugin MCP servers are started, if the two paths order those steps differently. (This is an observation, not a rule: one -p run also failed at 04:33 during the night window.)

Operational impact worth flagging for the fix priority: for supervised headless bots the failure is invisible from the outside — tmux is alive, the session answers, the status line is normal — and the supervisor's remedy (restart) is exactly what does not work, so it burns session context every cycle while the fleet stays deaf. Our watchdog restarted 7 sessions three times each with restarted=7 logged as success. The only signal that anything was wrong was the agents messaging each other over a different channel.

k1p1l0 · 19 days ago

Worth checking ~/.claude/mcp-needs-auth-cache.json next time it happens. No per-session log file plus an instant fix from /mcp → Reconnect matches #80822: one failed start anywhere on the machine (plausibly a session that raced the marketplace refresh) is cached under plugin:telegram:telegram, and new sessions skip the server for 15 minutes without logging it. Deleting that entry right before launch fixed it for me.