### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement I use the iMessage channel plugin to talk to Claude Code while I'm driving. Siri can dictate and send an iMessage hands-free, so it's the one input method that works in the car. It only runs in the terminal: ``` clau

Data point from binary inspection of the current Windows desktop build (Claude 1.32885, bundling claude-code 2.1.234): the plumbing for this appears to exist end-to-end except for the final call. - The SDK client class in both the desktop renderer bundle and `app.asar` defines `enableChannel(serverName)`, which issues a `channel_enable` control request (telemetry name `sdk_mcp_enable_channel`). - The CLI side handles `channel_enable` fully — it validates the server is plugin-sourced, checks the

[FEATURE] Let the Claude desktop app attach channel plugins (--channels)

Status Open

Reported on v2.1.229

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 3 comments · opened Aug 14, 2026

Preflight Checklist

[x] I have searched existing requests and this feature hasn't been requested yet
[x] This is a single feature request (not multiple features)

Problem Statement

I use the iMessage channel plugin to talk to Claude Code while I'm driving. Siri can dictate and send an iMessage hands-free, so it's the one input method that works in the car.

It only runs in the terminal:

claude --channels plugin:imessage@claude-plugins-official

I'd rather run that session in the desktop app. The transcript is a lot easier to read there when I get back to my desk. Right now I have to pick one or the other. Terminal gets me the channel, desktop gets me the readable UI.

Proposed Solution

Let a desktop session register channel plugins, the same way --channels does in the CLI.

A per-session picker would be ideal, since I don't want every session listening to my texts. A setting would work too.

Alternative Solutions

Run it in the terminal. Works today, but the TUI is harder to read.
Remote Control from the phone. Good for reading, but Siri can't drive it hands-free, so it doesn't solve the driving case.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Start a session in the desktop app, in whatever folder I'm working in.
Turn on the iMessage channel for that session.
Drive somewhere, ask Siri to text myself, get replies back over iMessage.
Get home, open the desktop app, read the whole conversation in the UI.

Additional Context

The desktop app already loads the channel plugins. It just never registers them as channels.

These are the args the desktop app spawns Claude Code with on my machine:

--output-format stream-json --verbose --input-format stream-json
--effort xhigh --model claude-opus-5
--permission-prompt-tool stdio
--setting-sources=user,project,local --permission-mode auto
--plugin-dir .../claude-plugins-official/imessage/0.1.0
--plugin-dir .../claude-plugins-official/telegram/0.0.6

So the plugin MCP servers start and their tools show up in the session. But there's no --channels, so inbound messages hit the session gate:

server imessage not in --channels list for this session

There doesn't seem to be a settings key for it either. channelsEnabled and allowedChannelPlugins are managed-org policy settings, and the schema description says users select servers via --channels.

Possibly related: #37624 (desktop app processes conflicting with the CLI channel plugin).

Versions:

Claude desktop 1.30096.1 (bundles Claude Code 2.1.229)
Claude Code CLI 2.1.228
macOS 26.6.1

View original on GitHub ↗

3 Comments

jacobmalm-asi · 1 month ago

Data point from binary inspection of the current Windows desktop build (Claude 1.32885, bundling claude-code 2.1.234): the plumbing for this appears to exist end-to-end except for the final call.

The SDK client class in both the desktop renderer bundle and app.asar defines enableChannel(serverName), which issues a channel_enable control request (telemetry name sdk_mcp_enable_channel).
The CLI side handles channel_enable fully — it validates the server is plugin-sourced, checks the allowlist, registers the notification handler, and logs "Channel notifications registered".
But enableChannel has exactly one occurrence in each bundle: the method definition. Nothing in the desktop app ever calls it, and the desktop offers no UI for it.

So a desktop session today loads the channel plugin, completes the MCP handshake, and the server can push notifications/claude/channel — which the session silently drops, exactly the half-open state described above. A per-session picker (or settings key) wired to the already-shipped enableChannel looks like all that's missing.

Additional use case beyond iMessage: internal agent-to-agent coordination plugins (a session gets woken by directed posts from other agents), where the desktop app is the primary surface and the terminal workaround means giving up the readable transcript UI.

hf75 · 23 days ago

+1, with a Windows data point. My app generator's MCP server (a custom stdio server) pushes notifications/claude/channel when a generated app calls back into Claude (user-triggered prompts, runtime errors). It works in the interactive CLI with claude --dangerously-load-development-channels server:neo-preview (v2.1.111). In the Code tab of the Claude desktop app on Windows the notifications never arrive, although the server does send them (checked with a stdio probe). claude -p --input-format stream-json with the same flag doesn't deliver them either. A per-session toggle in the desktop app for development channels from a project's MCP servers would cover this.

marcobelini · 21 days ago

Same need from a different direction: a companion device. (Disclosure: I make Tapproval, an Apple Watch app for Claude Code.) A message sent from the watch to a session that's open in the desktop app can today only go in through claude --resume <id> -p, which forks it: the open session never sees the message.

Channels are exactly the missing piece. Tested on 2.1.280: a small stdlib MCP server declaring experimental: {"claude/channel": {}}, loaded with --dangerously-load-development-channels, pushed a message from the watch into a running terminal session, and Claude answered it in place.

Two things keep it from shipping:

Desktop sessions can't take channels (this issue). A per-session toggle, as proposed above, would cover it.
For terminal sessions the only route without a warning is --channels with an allowlisted plugin. The development flag asks for confirmation at every start, so a session started remotely stalls on it. Is there, or will there be, a way to submit a third-party channel plugin for the allowlist?