AI
Claude Code Channels: Push Events Into a Live Session
August 202612 min read
An MCP server that pushes events into your running Claude Code session rather than waiting to be queried. Claude reacts to things that happen while you are away, and channels can be two-way so Claude replies through the same channel. Telegram, Discord and iMessage are included in the research preview.
Direction. A standard MCP server waits to be asked — Claude queries it during a task and nothing arrives unless Claude goes looking. A channel pushes an event into the session, so Claude reacts to something it never asked about, in the session that already has your files open and your context loaded.
Three independent gates must all open. Your organisation must have channelsEnabled set, and the plugin must be on the effective allowlist. The server must be named in --channels for that session — being in .mcp.json is not enough. And the sender ID must be on the channel's allowlist, or the message is silently dropped.
It depends on how you authenticate. On claude.ai Team and Enterprise, channels are blocked until an Owner enables them. With Anthropic Console API key authentication they are permitted by default unless your organisation deploys managed settings. Pro and Max users without an organisation skip these checks entirely.
Yes, if the channel declares the permission relay capability. It forwards permission prompts so you can approve or deny remotely — which means anyone on the sender allowlist can approve tool use in your session. Only allowlist senders you would trust with that authority, not merely with sending a message.
Key Takeaway
A Claude Code channel is an MCP server that pushes events into your running session, so Claude can react to things that happen while you are away from the terminal. Channels can be two-way: Claude reads the event and replies through the same channel. Events only arrive while the session is open, so an always-on setup needs a background process.
The thing that made channels click for me was a small one. A build failed while I was making coffee, the failure arrived in the session I had been debugging in for the last hour, and Claude started on it with all of that context already loaded — the files open, the theory we had been testing, the two things we had already ruled out. A fresh cloud session would have started from nothing.
That is the gap channels fill, and it is narrower and more specific than the marketing shape of push notifications suggests. This post covers what separates a channel from an ordinary MCP server, how it compares to the other four ways Claude Code reaches outside the terminal, the setup pattern all channels share, the three independent gates that must open before a message lands, and the authority the sender allowlist is really granting.
An ordinary MCP server waits to be asked. Claude queries it during a task, gets an answer, and moves on — nothing arrives unless Claude goes looking. A channel inverts that: the server pushes an event into the session, and Claude reacts to something it never asked about. Same protocol, opposite direction, and it is the whole feature.
The second property that matters is where the event lands. It arrives in the session you already have open, with whatever context that session has accumulated, rather than spawning a fresh one. That is the difference between an alert that says a test failed and an alert that reaches an agent already three files deep in why.
Claude Code has several ways of reaching outside the terminal and they are genuinely different tools. Channels fill exactly one gap in that list, and knowing which one saves you building the wrong thing.
Five ways out of the terminal:
| Feature | What it does |
|---|---|
| Claude Code on the web | Runs a task in a fresh cloud sandbox cloned from GitHub — good for self-contained async work |
| Claude in Slack | Spawns a web session from a mention, so a task starts from team conversation context |
| A standard MCP server | Claude queries it during a task; nothing is pushed to the session |
| Remote Control | You drive your local session from a phone or browser — steering, not events |
Telegram, Discord and iMessage are the channels in the research preview, and all of them are plugins requiring Bun. The steps are identical apart from where the credential comes from, and iMessage differs by needing no token at all — it reads the Messages database directly and replies through AppleScript, which means macOS and full disk access rather than a bot.
# The shape is the same for every channel: install, configure
# a credential, restart with the flag, then pair and lock down.
/plugin install telegram@claude-plugins-official
# Marketplace not found? add it first:
# /plugin marketplace add anthropics/claude-plugins-official
# Install summary says "Run /reload-plugins to activate."? Do that.
/telegram:configure <token>
# saved to ~/.claude/channels/telegram/.env
# or set TELEGRAM_BOT_TOKEN before launching
claude --channels plugin:telegram@claude-plugins-official
# Several plugins can be passed, space-separated.
# The flag does NOT appear in claude --help during the
# research preview. It works anyway.
# Then message the bot, and it replies with a pairing code:
/telegram:access pair <code>
/telegram:access policy allowlist # lock it to you only
# Try the mechanics with no credentials at all:
/plugin install fakechat@claude-plugins-official
claude --channels plugin:fakechat@claude-plugins-official
# then type into the UI at localhost:8787Start with the demo channel rather than a real platform. It runs a chat interface on localhost with nothing to authenticate, so you can watch a message arrive in your session and a reply appear in the browser before you have created a single bot. Fifteen minutes there teaches you the mechanics, and everything you learn transfers directly to the platform you actually want.
This is the part worth reading carefully, because the failure mode is silence rather than an error. A message that does not arrive could be blocked at any of three independent layers, and each one is owned by a different party — your administrator, your session, and the allowlist.
# Three independent gates, and all three must open.
# 1. Your organisation
{
"channelsEnabled": true,
"allowedChannelPlugins": [
{ "marketplace": "claude-plugins-official", "plugin": "telegram" },
{ "marketplace": "acme-corp-plugins", "plugin": "internal-alerts" }
]
}
# claude.ai Team and Enterprise: BLOCKED until an Owner
# enables it. Console with an API key: allowed by default,
# unless your org deploys managed settings.
# Pro and Max users without an organisation skip this entirely.
# 2. The session
# Being in .mcp.json is NOT enough. A server must also be
# NAMED in --channels for that session.
# 3. The sender
# Every approved channel keeps a sender allowlist. IDs you
# have not added are SILENTLY DROPPED.
# An empty allowedChannelPlugins array blocks the allowlist but
# NOT --dangerously-load-development-channels. To block channels
# entirely including that flag, leave channelsEnabled unset.The sender allowlist is granting more authority than it looks like. If a channel declares the permission-relay capability, it can forward permission prompts to you so you can approve or deny while away from the terminal — which means anyone who can reply through the channel can approve tool use in your session. Only allowlist senders you would trust with that, not merely senders you would trust with a message.
The asymmetry in what is visible catches people out, so it is worth stating:
Events only arrive while the session is open, so an always-on setup means a background process or a persistent terminal. That is a real constraint rather than a detail: a channel is not a service you deploy, it is a capability you attach to a session that has to already be running.
For genuinely unattended use, the bypass-permissions flag exists and the documentation is appropriately blunt about it: use it only in environments you trust, and note that the actions no mode auto-approves still apply. In non-interactive mode, tools needing terminal input — multiple-choice questions, plan-mode approval — are disabled so the session cannot stall waiting for something nobody is there to give.
Channels are a research preview, and two things follow from that which will otherwise waste your time. Neither the channels flag nor the development-channels flag appears in the help output, and they work anyway. And during the preview the flag accepts only plugins from an Anthropic-maintained allowlist, or your organisation's if an administrator set one — pass something outside it and Claude Code starts normally while the channel silently does not register, with a startup notice explaining why.
The first is a chat bridge. Ask Claude something from your phone through Telegram, Discord or iMessage, and the answer comes back in the same chat while the work runs on your machine against your real files. That is meaningfully different from a cloud session, which would be working from a clone with none of your local state.
The second is a webhook receiver, and it is the one with the highest value per line of setup. A webhook from CI, an error tracker or a deploy pipeline arrives where Claude already has your files open and remembers what you were debugging. Everything else in the outside-the-terminal list either starts fresh or waits to be asked; this is the only one that brings the event to the context.
Channels are narrow on purpose and the narrowness is the point: they exist for events that matter more because of where they land. Set up the demo channel first, understand the three gates before you debug a message that never arrived, and be deliberate about the allowlist — because on a channel that relays permissions, adding a sender is closer to granting an account than adding a contact.
Sources & further reading