There is a particular kind of frustration that anyone who has used Claude Code for a long project will recognise. You kick off a task. Claude is working.
You step away: make a coffee, take a call, open another tab.
You come back twenty minutes later, and either it finished fine, it hit a wall and stopped, or it needed something from you and 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.
What Claude Channels Actually Is
Channels is a new feature in Claude Code (currently in research preview) that lets external systems push events directly into a running Claude Code session.
Not a new session. Not a fresh API call.
Your existing session, with all the context it already has.
The simplest way to understand it: 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 Claude a message from your phone, and it would respond there, while continuing to work on your machine.
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 back to your chat.
The work happens on your machine. The conversation happens on your phone.
Why This Is Different From What Existed
Claude Code already had several ways to connect to external systems.
It is worth being precise about what each one does, because Channels fills a specific gap that the others could not.
Claude Code on the web runs tasks in a fresh cloud sandbox, cloned from a GitHub repo. You give it a job, it goes away and does it, and you check back later.
It is good for self-contained async work. Bad for anything that needs the context already sitting in your local session.
Claude in Slack spawns a web session from @Claude mention. Same idea. It spins up something new. It does not reach into the session you already have open.
Standard MCP servers give Claude tools that
it can query on demand. They are pull-based: Claude asks, the server answers. Nothing gets pushed into the session unprompted.
Remote Control lets you drive your local session from the mobile app or claude.ai.
This is the closest relative: you can steer an in-progress session while away from your desk. There is no mechanism for an external system to push a signal in.
Channels fill the gap. They are push-based.
External systems send events to your session without you doing anything.
A CI pipeline fails, a webhook fires, a Telegram message arrives, and Claude sees it and responds, right there in the session that already knows your codebase.
How Claude Channels Actually Work
Under the hood, a channel is an MCP server.
Specifically, one that has declared a special capability: claude/channel. It tells Claude Code to register a listener for incoming events from this server.
When an event arrives, it gets wrapped in a <channel> tag and delivered into Claude’s context:
<channel source="telegram" chat_id="12345">
hey, did the tests pass yet?
</channel>Claude reads it, does whatever it needs to do (checks the test output, runs a command, reads a file), and if the channel is two-way, calls a reply tool to send the answer back.
The event only arrives while the session is open. This is a deliberate design decision, not a limitation. Claude Channels is not 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, a CI webhook receiver, a monitoring alert pipeline, you would run Claude in a 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.
The 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.
Webhook Use Case Changes Things for Teams
Messaging Claude from Telegram while it works on your machine 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: a CI pipeline, an error tracker, a deployment system, a monitoring alert.
The practical shape of this is something like: your build fails on main, GitHub Actions fires a webhook, and Claude receives:
<channel source="webhook">build failed on main: https://ci.example.com/run/1234</channel>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.
Not a new context. Not a cold start.
The same session that was already watching the work.
This is the kind of thing that 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, loading the context again, and figuring out where you were.
Channels is a bet that the right model is to bring the events to the existing context, rather than spin up a new context for every event.
Liking this post? Get the next one in your inbox!
What Is Still Early
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: claude --channels plugin:telegram@claude-plugins-official.
That interface is not locked. Custom channels, 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 needs to go through Anthropic’s security review.
This is conservative and intentional: 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 and require an admin to 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.
The Bigger Idea Behind It
There is a pattern in how AI tooling has evolved over the past two years. The first wave was about making AI available, putting it in a chat interface, and letting people ask it questions.
The second wave was about giving it capabilities, tools, memory, and context.
Channels represent something slightly different: 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, a build fails, an alert fires, someone sends a message, Claude is already there, with context already 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 that 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 a genuinely open question. Some people will find it exactly right.
Others 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.
More from
Industry Trends
