Inbound channel notifications silently dropped — notifications/claude/channel never injected as user turns (CLI, regression 2.1.119–2.1.142)

Summary

Inbound messages from a channel MCP server (notifications/claude/channel) are silently dropped by the runtime — they are never injected into the session as <channel ...> user turns. The channel server emits the notification correctly; the runtime never acts on it.

This is a regression: it worked on 2.1.114 and is broken on every version I've tested from 2.1.119 through the current 2.1.142.

Reproduced with the official imessage channel plugin (imessage@claude-plugins-official v0.1.0) on the standalone CLI (CLAUDE_CODE_ENTRYPOINT=cli, iTerm2 — not the VS Code extension). The failure is on the runtime side, not the plugin. The plugin runs as a normal plugin-configured MCP server via .mcp.json — not via claude --channels.

Environment

• Claude Code: 2.1.142 (standalone CLI, iTerm2). Also confirmed broken on 2.1.119. Last known good: 2.1.114.
• OS: macOS, Darwin 24.5.0
• Plugin: imessage@claude-plugins-official v0.1.0 (commit b10b583), unchanged upstream since 2026-03-30
• MCP server runtime: bun

Steps to reproduce

1. Install the official imessage channel plugin and configure access (Full Disk Access granted, sender on the allowlist).
2. Start a Claude Code CLI session — the plugin's MCP server starts and polls ~/Library/Messages/chat.db.
3. Send an iMessage from an allowlisted sender (or self-chat).

Expected

The runtime injects a <channel source="...imessage..." chat_id="..." ...> user turn into the session, and the assistant can respond via the plugin's reply tool.

Actual

The message lands in chat.db, the MCP server emits notifications/claude/channel, but no <channel ...> turn is ever injected. The session sees nothing; the sender gets silence.

Evidence the server side is correct

From the plugin's server.ts (v0.1.0):

• Polls chat.db every 1s — setInterval(poll, 1000) (server.ts:771).
• On a new inbound row, emits mcp.notification({ method: 'notifications/claude/channel', params: { content, meta } }) (server.ts:862).
• Declares the capability experimental: { 'claude/channel': {} } (server.ts:549).

In an earlier investigation the emitted JSON-RPC was captured from a sibling server instance's stdout and confirmed well-formed.

Evidence the runtime drops it

• 2026-05-14, CC 2.1.142 (CLI): a test message landed in chat.db at 15:24 while the plugin's MCP server (confirmed running, polling) was up. No <channel ...> turn was injected into the live session.
• Same plugin, same allowlist, same chat produced 46 working inbound turns on CC 2.1.114.

Suspected cause

An MCP-startup / handshake-timing change in the 2.1.116–2.1.119 range. Relevant changelog entries:

• 2.1.116: "Faster MCP startup when multiple stdio servers are configured"
• 2.1.117: "Fixed MCP elicitation/create requests auto-cancelling in print/SDK mode when the server finishes connecting mid-turn"

The channel server begins polling and may emit its first notifications/claude/channel before the runtime has registered its channel-notification handler, so early (and possibly all) notifications are dropped silently.

Related issues

• #58018 — same notifications/claude/channel drop, reported as a regression on the VS Code extension 2.1.138 (Telegram, Windows). That report states claude --channels from the CLI still works — this report shows the standalone CLI on 2.1.142 is also affected, so the regression is not VS-Code-only.
• #36975 — general "channel notifications not surfaced to conversation" (Telegram). Confirms it's not plugin-specific.
• #45563 — same mechanism on Windows; marked duplicate/stale.

This report adds: a non-Telegram plugin (iMessage), macOS, the standalone CLI host, and a bisected version range (good on 2.1.114, broken 2.1.119 → 2.1.142).

This also looks distinct from the 2.1.105 fix "Fixed inbound channel notifications being silently dropped after the first message for Team/Enterprise users" — that was scoped to Team/Enterprise and to messages after the first. Here every inbound message is dropped, for a non-enterprise user.

Workaround

Downgrade to 2.1.114 (last confirmed-good).

Suggested next step

Running with --debug=mcp,channel should show whether the runtime receives the notifications/claude/channel JSON-RPC at all, and if so why it isn't dispatched.