--channels: inbound notifications silently dropped from the very first message (Team plan) — looks like a regression of the 2.1.105 fix

Claude Code version: 2.1.232
OS: Windows 11
Install method: global npm install
Plan: Claude Team
Command: claude --dangerously-skip-permissions --channels plugin:discord@claude-plugins-official

Symptom

Inbound messages from the Discord channel plugin never turn into a visible <channel source="discord" ...> conversation turn — not even the very first message of a completely fresh session.

Everything checkable locally is healthy:

• /mcp shows the discord server as connected.
• The plugin's own MCP server subprocess (bun run server.ts) has a live, established TCP connection to Discord's gateway (verified via Get-NetTCPConnection).
• The plugin's own access-control gate is passing the message (Discord shows the bot's "typing..." indicator, which in the plugin's source only fires after gate() returns deliver — i.e. the message is being received and accepted by the MCP server).
• Despite all of the above, the session's own transcript file (~/.claude/projects/<cwd>/<session-id>.jsonl) never receives a new entry for the notification — confirmed by reading the raw JSONL directly, not just visually checking the terminal.

This matches the changelog entry for 2.1.105:

Fixed inbound channel notifications being silently dropped after the first message for Team/Enterprise users

...except in 2.1.232 it appears to drop every message, including the first one, not just messages after the first.

Repro steps

1. On a Claude Team (or Enterprise) account, launch claude --dangerously-skip-permissions --channels plugin:discord@claude-plugins-official.
2. Run /mcp and confirm the discord server shows connected.
3. From an allowlisted Discord account, send a message into a channel configured with requireMention: false (or a paired DM).
4. Observe: the bot shows Discord's typing indicator (proof the message reached the plugin and passed its gate), but no <channel source="discord"...> turn ever appears in the CLI, and the session transcript JSONL is never appended to.

This reproduced identically across multiple fresh session restarts over several hours (spanning an unrelated PC reboot in between), so it isn't a one-off hang.

Current workaround

Polling the same plugin's own fetch_messages / reply MCP tools on an interval instead of relying on the push notification path.