[BUG] Telegram plugin v0.0.6 channel notifications stop reaching context after 2.1.150 update

Preflight Checklist

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

What's Wrong?

After Claude Code auto-updated from 2.1.146 → 2.1.150, inbound Telegram messages stopped surfacing in the session as <channel source="telegram" ...> blocks.

The telegram plugin's MCP server is fully healthy — it polls Telegram, consumes messages (getUpdates returns pending: 0 after a test message), and has its stdio Unix sockets connected to the parent claude
process. The plugin fires mcp.notification({ method: 'notifications/claude/channel', ... }) at server.ts:963 for every inbound DM. That notification used to land in my context as a <channel> block. On
2.1.150 it never does.

Confirmed working as recently as 2026-05-23 on 2.1.146. Broke on 2026-05-24 after the auto-update to 2.1.150.

Plugin is at marketplace HEAD (v0.0.6), no plugin update available — the regression is in Claude Code itself.

What Should Happen?

When a Telegram user on the bot's allowlist sends a DM, the message should arrive in the active Claude Code session as a <channel source="telegram" chat_id="..." message_id="..." user="..."
ts="...">…</channel> block — exactly as it did on 2.1.146.

Error Messages/Logs

No error output. The notification path is silent — the bot calls mcp.notification() (a fire-and-forget MCP call) without surfacing an error, and Claude Code's context never receives the channel block.

  Diagnostic evidence (collected during a working session):

  # bot process tree — bot is alive, parent is claude
  $ ps -axo pid,ppid,etime,command | grep "bun server.ts"
  8285  8282  bun server.ts
  8282  8272  bun run ...telegram/0.0.6 start
  8272  978   claude

  # stdio is wired up correctly (Unix sockets to parent)
  $ lsof -p 8285 -a -d 0,1,2
  bun  8285  0u  unix  ...
  bun  8285  1u  unix  ...
  bun  8285  2u  unix  ...

  # bot is connected to Telegram and fetching updates
  $ curl ".../getUpdates" → pending: 0 (after sending a test DM)

Steps to Reproduce

1. Install the telegram@claude-plugins-official plugin (v0.0.6, current marketplace HEAD).
2. Configure it: set TELEGRAM_BOT_TOKEN, add your Telegram user ID to access.json allowFrom, set dmPolicy to "allowlist".
3. Run claude on version 2.1.146 → send a DM to the bot → message arrives in the session as a <channel> block. ✅
4. Update to 2.1.150 (or fresh install) → restart claude → send a DM to the bot → bot consumes the message from Telegram (verifiable via curl ".../getUpdates" returning pending: 0) but no <channel> block

ever surfaces in the session. ❌

Restarting Claude Code does not fix it. A fresh bot is spawned, stdio sockets are connected, but notifications still don't surface.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.146

Claude Code Version

2.1.150

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The plugin code is unchanged — marketplace HEAD matches the installed v0.0.6 byte-for-byte. The regression is on the Claude Code side.

Plugin declares the experimental capability at server.ts:388:
capabilities: { experimental: { 'claude/channel': {}, 'claude/channel/permission': {} } }

And fires notifications at server.ts:963:
mcp.notification({ method: 'notifications/claude/channel', params: { content, meta } })

The permission-relay variant (notifications/claude/channel/permission) is likely affected too but I haven't tested it.

Workaround for affected users: downgrade by symlinking ~/.local/bin/claude → ~/.local/share/claude/versions/2.1.146 (older binaries are retained on disk).

Plugin source: https://github.com/anthropics/claude-plugins-official (telegram, v0.0.6)