There is a kind of frustration that anyone who has used Claude Code for a long project will face. You kick off a task, and Claude starts working.

You step away, maybe to make a coffee or open another tab. Say you came back 20 minutes later, only to find that it needed something from you, so it just sat there waiting.

The AI was doing real work. But the moment you left the terminal, you lost the thread. That is the problem Claude Channels is designed to fix.

Let’s dig in!

Channels is a new feature in Claude Code.

It is now available in research preview, which allows external systems to push events directly into a running Claude Code session. Not a new session or a fresh API call.

Your existing session, with all the context it already has. The simplest way to understand it is to imagine you are deep in a coding session with Claude.

You have files open, context loaded, a conversation in flight.

Now imagine you could send a message from your phone, and Claude would respond there, while continuing to work on your laptop. That is exactly what Channels does.

You connect Claude Code to Telegram or Discord, pair your account, and from that moment forward, you can message Claude from anywhere.

Claude reads the message, does the work, and replies to your chat. The work happens on your laptop. The conversation happens on your phone.

Claude Code already had many ways to connect to external systems, but Channels fills a specific gap that the others could not. For example:

Claude Code on the web runs tasks in a fresh cloud sandbox. It is cloned from a GitHub repo. You give it a job, it does it, and you check back later.

It is good for self-contained async work, but is not so good for anything that needs the context already sitting in your local session.

Claude in Slack starts a web session when you mention @Claude. It starts a completely new session and does not enter the one you already have open.

Standard MCP servers allow Claude tools to query on demand. They are pull-based: Claude asks, the server answers. Nothing gets pushed into the session unprompted.

Remote Control lets you monitor your local session from the Claude mobile app or claude.ai. This is the closest relative.

You can guide an in-progress session while away from your desk. But it is still you driving. There is no mechanism for an external system to give a signal.

Channels fill the gap. They are push-based.

External systems send events to your session without you doing anything.

When a CI pipeline fails, a webhook fires, a Telegram message comes, Claude sees it, and responds, right there in the session that already knows your codebase.

Also read: WTF is the Difference Between Claude, Claude Code, Claude Cowork?

Under the hood, a channel is an MCP server.

Especially, one that has a special capability: claude/channel.

It tells Claude Code to register a listener for incoming events from this server. When an event comes, it gets wrapped in a <channel> tag and delivered into Claude's context:

Claude reads it and follows the instructions. If the channel is two-way, it calls a reply tool to send the answer back. The event only comes while the session is open.

This is an intentional design decision. Claude Channels isn't a background service. It is not watching your repo while your laptop is closed.

It is a bridge into a session that is already running.

For always-on setups, such as a CI webhook receiver or a monitoring alert pipeline, you would run Claude in the background process or a persistent terminal.

For personal use, you leave your session open while you work, and reach it from Telegram when you step away.

The two platforms supported in the research preview are Telegram and Discord.

Setup follows the same pattern for both: create a bot, install the plugin in Claude Code, configure your token, restart with --channels, send a message to your bot to get a pairing code, then lock down the allowlist so only your account can push messages in.

That allowlist is not optional. An ungated channel is a prompt injection vector.

Anyone who can reach your endpoint can put text in front of Claude. Anthropic's design makes the security step part of the setup flow rather than an afterthought.

Also read: What is the Point of Model Context Protocol (MCP)?

Messaging Claude from Telegram while it works on your desktop is the obvious consumer use case.

But the more interesting implication for product teams is the webhook receiver.

A channel can listen on a local HTTP port.

Anything that can send an HTTP POST can push an event into your Claude session, such as a CI pipeline, an error tracker, a deployment system, or a monitoring alert.

The practical shape of this is something like: your build fails on main, GitHub Actions fires a webhook, Claude receives <channel source="webhook">build failed on main:

And because Claude already has your codebase open, it can immediately look at what changed, identify the likely cause, and either fix it or tell you what it found.

It's the same session that was already watching the work.

It sounds like a small quality-of-life improvement until you think about how much of a developer's day is spent context-switching: checking a build status, opening a new terminal, or figuring out where you were.

Channels is a bet that the right model is to bring the events to the existing context, rather than spinning up a new context for every event.

Channels launched as a research preview, and a few things are worth knowing. The --channels flag syntax may change. It currently takes plugin names explicitly.

For instance:

That interface is not locked. Custom channels, the ones you build yourself, are not on the approved allowlist during the preview.

You can test them locally with --dangerously-load-development-channels, but to share a channel publicly, it must go through Anthropic's security review.

That is intentional because a channel that can push arbitrary text into a Claude session with file system access is exactly the kind of surface that warrants careful review.

On Team and Enterprise plans, channels are disabled by default. An admin must explicitly enable them. Individual Pro and Max users can opt in per session.

The feature requires Claude Code v2.1.80 or later, and a claude.ai login. API key authentication is not supported in the research preview.

AI tooling has evolved in patterns over the past two years:

The first wave was about making AI available: put it in a chat interface and let people ask it questions. The second was about giving it capabilities: tools, memory, context.

Channels represent something slightly different. It is making the AI reachable. Not just a thing you go to, but a thing that can be reached.

A Claude session with Channels enabled is not just waiting for your next prompt.

It is listening to the systems around it. When something happens, such as a person sending a message, Claude is already there, with context loaded, ready to respond.

That shift from pull to push is subtle, but it changes what the AI is.

It is less like an assistant you consult and more like a collaborator who is actively part of your workflow, even when you are not at your desk.

Whether that is what you want from an AI coding tool is an open question.

Some people will find it right. Some will want a harder boundary between when AI is active and when it is not. But the direction of travel is clear.

The terminal is no longer the only way in.