VS Code extension 2.1.138 drops notifications/claude/channel — Telegram plugin polls but messages never inject into chat

Summary

anthropic.claude-code-2.1.138-win32-x64 no longer surfaces notifications/claude/channel events from stdio MCP servers into the chat UI. The official Telegram plugin (claude-plugins-official/telegram@0.0.6) polls Telegram via grammy and successfully consumes Update messages from getUpdates, but the resulting mcp.notification({ method: 'notifications/claude/channel', params: ... }) call does not produce a <channel source="telegram"> block in the active VS Code conversation.

The plugin source is unchanged since 2026-04-15; the regression coincides with the extension dir mtime jumping to 2026-05-09 11:26 local time on this machine (auto-update). Reproducible across two clean VS Code restarts on 2026-05-11. The same plugin works correctly when launched via claude --channels from the CLI in PowerShell — the bug is host-side, in the VS Code Claude Code extension, not in the plugin.

Environment

• OS: Windows 11 Home 10.0.26100
• VS Code Claude Code extension: anthropic.claude-code-2.1.138-win32-x64
• Plugin: telegram@0.0.6 from the claude-plugins-official marketplace (installed_plugins.json gitCommitSha: b10b583de281385442474e836644534b938b2678, last updated 2026-04-15)
• Bun runtime: v1.3.14-canary (whichever VS Code's plugin host shells out to)

Steps to reproduce

1. Install claude-plugins-official/telegram at user scope.
2. Configure ~/.claude/channels/telegram/.env with a valid TELEGRAM_BOT_TOKEN.
3. Pair a Telegram account via the bundled /telegram:access skill so access.json has dmPolicy: "allowlist" and allowFrom: ["<user-id>"].
4. Open a fresh Claude Code conversation in VS Code (extension 2.1.138).
5. Verify the plugin's bun child is alive and polling — plugin stderr emits telegram channel: polling as @<bot>.
6. From the paired Telegram account, DM the bot any text message.

Expected

A <channel source="telegram" chat_id="..." message_id="..." user="..." ts="...">...message text...</channel> block surfaces as the next user turn in the active conversation, per the plugin's own MCP instructions payload.

Actual

Nothing surfaces in chat. The message is genuinely consumed by the plugin (not stuck at Telegram):

• Direct GET /bot<token>/getUpdates?timeout=0&offset=-1 after the DM returns {"ok":true,"result":[]} — empty queue, offset advanced.
• No 409 Conflict reported by the plugin (single poller).
• gate() in plugin source returns deliver (allowlist match confirmed via access.json).
• handleInbound() reaches mcp.notification({ method: 'notifications/claude/channel', ... }) (server.ts lines 957–979 of v0.0.6).
• No error appears in plugin stderr (process.stderr.write paths checked).

The notification appears to reach the MCP host over stdio but is silently dropped — no chat block, no error toast, no Output-panel entry.

Plugin capability declaration

The plugin advertises the experimental channel capability:

experimental: {
  'claude/channel': {},
  'claude/channel/permission': {},
}

at server.ts:374-381. Permission-relay (the /permission sub-capability) still works — inline buttons sent from the plugin via bot.api.sendMessage(..., { reply_markup: keyboard }) reach Telegram, and outbound reply/react/edit_message tools continue to function from VS Code until the bun child is killed. Only the inbound channel-injection path is broken.

Workaround

Use claude --channels "plugin:telegram@claude-plugins-official" in a separate PowerShell window for inbound. The CLI's --channels handler still injects the notification correctly into its own conversation. VS Code Claude Code is currently inbound-blind for any plugin using the notifications/claude/channel mechanism.

Impact

Any plugin relying on notifications/claude/channel (the experimental channel-message injection mechanism) is broken in VS Code Claude Code 2.1.138+. The official telegram plugin is the most visible victim; any third-party channel-bridge plugin (Slack, Discord, SMS, custom queue) using the same MCP notification method would hit the same issue.