MCP channel flags require plugin:/server: tagging

--channels and its development-channels flag now require explicit plugin: or server: tags

Use it now Notable Improvements

JSON All of v2.1.265

Use it nowTier: how much it should matter to you

3Useful: my rating, 1 to 5

2Signal: worth watching, 1 to 5

MCPArea: what it touches

ImprovementsKind: in v2.1.265, 08 Sep 26

What probably matters to youSection of the release

What

Values passed to the --channels flag and to --dangerously-load-development-channels must now be tagged, in the form plugin:<name>@<marketplace> or server:<name>. An entry without one of these tags is now rejected with an explicit error explaining the required formats.

Why

Requiring the tag removes ambiguity about whether a channel entry refers to a plugin or an MCP server, catching malformed flag values immediately instead of letting them silently fail or resolve incorrectly.

See this entry in the whole of v2.1.265 →

The build it came inv2.1.265

8 Sep 2026 · 371 entries, this one is #37.

Use it now40
You'll notice132
Nothing to try yet30
Under the hood169

Either side of it

v2.1.263Older
v2.1.266Newer

Open the release →

Names in this entry

cli--channels
(Research preview) MCP servers whose channel notifications Claude should listen for in this session. Space-separated list of plugin:<name>@<marketplace> entries. Requires Anthropic authentication through claude.ai or a Console API key
cliplugin
Telemetry values now pass through marker helpers that declare them safe; nothing sent actually changed.
settingname
The SDK now rejects malformed skill names with a clear reason instead of creating a rule that never matches.
settingserver
Some MCP server discovery calls are answered from cache, avoiding an extra round trip.

Part of a story

This entry is one step of a feature followed across several releases. The story links it; it does not replace it.

Plugins, from an install command to a governed marketplace

Is this right?