Feature request: opt desktop sessions into channels without argv access

Problem

Channels currently require a per-session opt-in through --channels:

"In all cases, no channel runs until a user opts it in for the session with --channels." — channels.md

The Claude Code desktop app controls session argv. Its flag table says that flags not listed have no desktop equivalent, and --channels is not listed. There is therefore no supported way to opt a desktop session into a channel.

This leaves desktop channels in a half-open state: a plugin with a channels declaration loads, its MCP server starts and completes the handshake, and the server can receive frames and write notifications/claude/channel to the transport. The notification still never reaches the session.

Verification

• We tested the same binary and stream-json transport with and without --channels. With the flag, the notification reaches the model verbatim. Without it, the server flushes the write and records its delivery receipt, but the session receives nothing.
• We found no settings key, environment variable, or plugin-manifest field that enables channels for a session. We checked the documentation, the settings.json schema, and the changelog through 2.1.228.
• Managed policy is already configured with channelsEnabled: true and allowedChannelPlugins. As documented, those settings control which channels may run; they do not opt a session in.

Request

Please add a supported equivalent to --channels for sessions whose argv the user cannot control. In order of preference:

1. Add a channels key to settings.json at user or project scope, accepting the same values as the flag:

``json
{
"channels": ["plugin:hive-channel@hive"]
}
``

Project scope would keep the opt-in explicit and reviewable.

1. Add a desktop control, scoped per project or per session, that lists installed channel-capable plugins allowed by policy.

1. Document an environment variable read at session start. The desktop app already provides a local environment editor.

Any of these mechanisms should remain subject to channelsEnabled and allowedChannelPlugins, preserving organization policy. The settings and UI options also preserve explicit user consent while making it available on a surface that does not expose argv.

Use case

We maintain hive, a multi-agent runtime whose agents send messages through a channel plugin. Terminal sessions work well with channels and no longer need fragile tmux send-keys injection.

Desktop-led sessions still need a Stop/PostToolUse hook that polls the message bus and injects messages through blocked-stop feedback. It works, but lacks push wake-up while idle and adds polling to tool calls. The channel permission relay introduced in 2.1.81 is unavailable on desktop for the same reason.

Environment

• Claude Code desktop app with CLI 2.1.222; behavior matches the documentation through 2.1.228
• macOS 25.5.0
• Published marketplace plugin with a channels declaration backed by a stdio MCP server