--dangerously-load-development-channels does not register bare server: channels (inbound notifications silently dropped)

Independent confirmation on Linux (not macOS-only) — still present in v2.1.197

Confirming this exact bug from a second, unrelated MCP server. The root-cause decomposition above matches what we see; adding two data points that may help triage:

1. It's not macOS-specific. This issue is labeled platform:macos, but we reproduce the identical failure on Linux x86_64 (Arch, kernel 7.0.9), Claude Code v2.1.197 (two patch releases after the reported v2.1.195), same claude.ai OAuth auth mode. The --dangerously-load-development-channels server:<name> registration gap is platform-independent — suggest widening the label.

2. Different consumer class, same failure. Our server (mcp-agent-relay) isn't a chat bridge — it's a job relay: one Claude session dispatches async work to another agent and expects a push (notifications/claude/channel) when the job reaches a terminal state. Outbound tools (dispatch/poll) work perfectly; the inbound channel push is silently dropped with the same debug line:

MCP server "agentrelay": Channel notifications skipped: server agentrelay not in --channels list for this session

Launched via claude --dangerously-load-development-channels server:agentrelay. Server declares capabilities.experimental["claude/channel"] and emits notifications/claude/channel on terminal transitions — never delivered.

3. Workaround for anyone blocked today. Since the push path is dead, we moved wake-up to a pull-side Stop hook: SessionStart seeds a baseline of already-seen jobs, and Stop/SubagentStop surface any new terminal transitions (with an optional bounded long-poll so the session waits for an in-flight job instead of settling early). No dev flag, no per-session dialog, works with both claude mcp add and plugin installs. Not as clean as a real push, but it's a functional substitute until the registration gap is fixed.

Happy to share a minimal relay repro if useful.

Confirming for 2.1.205

Channel notifications never registered for server: entries, even with the documented flag combination

Summary

A channel MCP server (declared via .mcp.json, connected via --dangerously-load-development-channels server:<name> and --channels server:<name>) connects successfully, but notifications/claude/channel sent by that server are silently dropped. --debug mcp shows:

Channel notifications skipped: server <name> is not on the approved channels allowlist (use --dangerously-load-development-channels for local dev)

— even though --dangerously-load-development-channels was passed with that exact server name. This makes the channels feature (research preview) completely non-functional for any locally-developed server:-kind channel, as documented in https://code.claude.com/docs/en/channels-reference.

Environment

• Claude Code: 2.1.205 (also reproduced on 2.1.204 before an auto-update)
• Node: v20.20.2
• OS: Linux, 6.17.0-35-generic (Ubuntu 24.04)
• @modelcontextprotocol/sdk: 1.29.0

Minimal repro

This is Anthropic's own "webhook receiver" example from the channels reference docs, trimmed to the minimum needed:

// repro.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const mcp = new Server(
  { name: "repro", version: "0.0.1" },
  {
    capabilities: { experimental: { "claude/channel": {} } },
    instructions: "Events from this channel arrive as <channel source=\"repro\" ...>.",
  },
);

await mcp.connect(new StdioServerTransport());
console.error("[repro] connected over stdio");

setTimeout(() => {
  mcp.notification({
    method: "notifications/claude/channel",
    params: { content: "hello from the repro channel" },
  });
  console.error("[repro] pushed a channel notification");
}, 3000);

// .mcp.json, in the same directory
{
  "mcpServers": {
    "repro": { "command": "npx", "args": ["tsx", "repro.ts"] }
  }
}

Run:

claude --channels server:repro --dangerously-load-development-channels server:repro --debug mcp --debug-file /tmp/repro-debug.txt

Accept the "New MCP server found" prompt if shown. Wait a few seconds, then check the debug log:

grep "repro" /tmp/repro-debug.txt

Actual result

[DEBUG] MCP server "repro": Successfully connected (transport: stdio) in 348ms
[DEBUG] MCP server "repro": Connection established with capabilities: {"hasTools":false,...}
[DEBUG] MCP server "repro": Channel notifications skipped: server repro is not on the approved channels allowlist (use --dangerously-load-development-channels for local dev)

The <channel source="repro" ...> tag never appears in the session — Claude never sees the pushed notification.

Expected result

Per the channels reference:

claude --dangerously-load-development-channels plugin:yourplugin@yourmarketplace / claude --dangerously-load-development-channels server:webhook

should be sufficient to load a local development channel and have its notifications delivered. Instead, the server-kind entry is treated as not dev-approved even when explicitly passed to --dangerously-load-development-channels.

Notes from investigating further

• Passing --dangerously-load-development-channels server:repro alone (no --channels) produces a different skip reason: server repro not in --channels list for this session — meaning the dev flag alone never adds the entry to the session's effective allowed-channels list at all.
• Passing both flags with the same server:repro value (the combination the docs suggest) produces the "not on the approved channels allowlist" skip shown above — i.e. an entry is found, but it's not marked as dev-approved.
• This is not caused by an unanswered confirmation dialog: reproduced identically in (a) a fully interactive session with every prompt manually approved by a human, and (b) a non-interactive session with the project pre-trusted and the MCP server pre-approved via enabledMcpjsonServers in ~/.claude.json (no prompts pending at all). Same skip message in both.
• Reading the bundled CLI source (minified, node_modules-style build), the relevant lookup is roughly list.find(entry => matches(name, entry)), and entries appear to be appended to the effective list separately for --channels and --dangerously-load-development-channels. If both flags produce a separate entry for the same server name, and the non-dev entry happens to be checked/found first, the dev flag's entry is effectively never consulted. This is a guess based on reading obfuscated output, not confirmed against source — but it would fully explain the observed behavior.
• Everything downstream of channel-notification delivery works correctly — this isn't a broader MCP or connection problem. A real HTTP-triggered agent workflow built against this channel correctly reaches its own request-handling code, and the only missing link is Claude Code delivering the notification in the first place.

Impact

The channels research-preview feature is unusable for any server:-kind (i.e. non-plugin, locally developed) channel on this build, despite following the documented setup exactly. This blocks building and testing custom channel integrations entirely, since even the canonical docs example doesn't work as written.

Same behavior with the plugin: form on 2.1.220 (Windows 11). A marketplace-installed channel plugin launched with --dangerously-load-development-channels plugin:<name>@<marketplace> connects, its tools work, outbound reply works, but inbound notifications are dropped with "Channel notifications skipped: server plugin:<name>:<server> not in --channels list for this session". The plain --channels flag warns the plugin is not on the approved allowlist and points at this dev flag, and allowedChannelPlugins in managed settings changes nothing. So the flag currently isn't an escape hatch for either the server: or the plugin: form. Filed #82571 for the broader allowlist question.