Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Channel plugins (Telegram/iMessage) disconnect on .claude.json hot-reload in multi-session setups [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49151•Fetched 2026-04-17 08:49:26
View on GitHub
Comments
2
Participants
2
Timeline
6
Reactions
0
Author
franckroccafranckrocca
Participants
franckroccafranckroccagithub-actions[bot]github-actions[bot]
Timeline (top)
labeled ×3commented ×2cross-referenced ×1

Error Message

Error Messages/Logs

Fix Action

Fix / Workaround

Workaround: fswatch daemon that detects changes and injects /mcp via tmux — unreliable when session is busy processing. Environment: CC v2.1.110, macOS 15.4, M4, plugin telegram v0.0.6 Related: #36308 (MCP auto-reconnect), #36802 (Telegram notifications not delivered)

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Channel plugins loaded via --channels disconnect every time ~/.claude.json is modified. Regular MCP servers survive the hot-reload, but channel plugins don't reconnect automatically.

Impact: With 8+ concurrent CC sessions (common for power users using Telegram as mobile interface), .claude.json is updated frequently (session metrics: lastCost, lastSessionMetrics, etc.). This causes channel plugins to disconnect every ~10 minutes across ALL sessions simultaneously.

What Should Happen?

Expected: Channel plugins should survive .claude.json hot-reload (like regular MCP servers do), OR .claude.json metric writes should not trigger hot-reload.

Error Messages/Logs

Steps to Reproduce

  1. Start 2+ CC sessions with --channels plugin:telegram@claude-plugins-official
  2. Both sessions share ~/.claude.json
  3. Session A completes a turn → CC writes metrics to .claude.json
  4. Session B's Telegram plugin disconnects silently
  5. /mcp or /reload-plugins reconnects it, but next .claude.json write kills it again

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.110

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workaround: fswatch daemon that detects changes and injects /mcp via tmux — unreliable when session is busy processing. Environment: CC v2.1.110, macOS 15.4, M4, plugin telegram v0.0.6 Related: #36308 (MCP auto-reconnect), #36802 (Telegram notifications not delivered)

extent analysis

TL;DR

The channel plugins can be kept connected by implementing a reliable reconnect mechanism, potentially using the /mcp or /reload-plugins command after detecting changes to ~/.claude.json.

Guidance

  • Investigate the fswatch daemon approach further to make it more reliable, possibly by adding a delay or retry mechanism to handle busy sessions.
  • Consider modifying the Claude Code to ignore metric writes to .claude.json or to not trigger hot-reload on these changes, similar to how regular MCP servers behave.
  • Review related issues #36308 and #36802 for potential insights or solutions that could be applied to this problem.
  • Test the behavior with different numbers of concurrent CC sessions to understand the impact of session metrics updates on channel plugin disconnections.

Example

No specific code example is provided due to the lack of detailed implementation details in the issue.

Notes

The provided workaround using fswatch and injecting /mcp via tmux is unreliable, especially when a session is busy. A more robust solution is needed to ensure channel plugins remain connected across all sessions.

Recommendation

Apply a workaround, such as enhancing the fswatch daemon approach, because a direct fix to the underlying issue is not immediately clear and may require further investigation into the Claude Code's handling of ~/.claude.json updates and hot-reload behavior.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#retrieval issue#search optimization#API routing#API middleware

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING