Claude Code Channels: The Away Problem, Solved

This post covers a feature in active development. Details are based on the research preview launched March 2026, requiring Claude Code v2.1.80+ and a claude.ai account.

What’s New This Week

Anthropic shipped Claude Code Channels this week – a feature that lets external systems push events directly into a running Claude Code session via MCP. CI results, monitoring alerts, Telegram messages. Claude reads the event and can act on it, even if you’ve walked away from the terminal. Currently in research preview; Discord and Telegram are the two official channels, with a reference API for building your own.

Changelog

Anthropic shipped Claude Code Channels this week. It’s a feature that lets external systems push events into a running Claude Code session from an MCP server – CI results, monitoring alerts, Telegram messages. Claude reads the event and can act on it, even if you’ve walked away from the terminal.

The feature announcement is modest. The architectural implication is not.

The Away Problem

Current agentic coding workflows have a structural problem: Claude Code runs in your terminal session. You watch it work. You intervene when needed. The human is in the loop because the human has to be – there’s no other way to get new information into the session once it’s running.

That’s fine when you’re sitting there. It breaks completely when production happens while you’re not.

CI runs overnight. Build pipelines fire after you’ve closed your laptop. A test suite fails at 2am. A monitoring threshold breaches on Saturday morning. The agent can’t react to any of it unless you’re at the terminal to read the output and type the next instruction. The loop requires a human in it.

This is the away problem. It’s not a Claude problem specifically – it’s the fundamental limitation of synchronous, terminal-bound agent workflows. The agent is only as available as the engineer running it.

Channels is Anthropic’s answer. Events can now reach Claude and prompt a reaction regardless of whether you’re watching. The session stays open; the outside world can push into it.

What the Mechanism Looks Like

The Telegram integration is the clearest illustration of how this works.

You create a Telegram bot via BotFather, install the plugin (/plugin install telegram@claude-plugins-official), configure the token, and restart Claude Code with --channels plugin:telegram@claude-plugins-official. Claude sends a pairing code; you confirm it in the terminal. You lock it down with an allowlist so only your account can push events.

From that point, anything you send to the bot lands in Claude’s active session as an event. Claude reads it, decides what to do, and acts – inside the terminal, with access to your file system and shell, the same as if you’d typed the instruction yourself.

The terminal shows the tool call and confirmation. The activity is visible. But you’re not there to initiate it. The trigger came from outside.

Discord works the same way. Both are official Anthropic plugins in the research preview.

The Two-Way Reply Changes Everything

Channels aren’t just incoming webhooks. Claude can reply back through the same channel.

You push a monitoring alert via Telegram – say, a failed deployment. Claude investigates the failing service, reads the logs, identifies the issue, deploys a fix, and responds to you on Telegram with the outcome. You receive one message: “Rollback complete, root cause was X, fix is on branch Y.”

You weren’t at the terminal. You didn’t watch the steps. You got the result.

The human interaction layer is now Telegram or Discord, not the terminal. For engineers who aren’t always at the machine – which is most engineers, most of the time – this makes Claude Code a genuine asynchronous collaborator rather than a synchronous assistant.

The shift is from “AI that helps you write code while you watch” to “AI that handles incidents and reports back.” That’s a qualitatively different category of tool. The two-way reply is what makes it practical rather than just interesting.

For more on the broader trajectory here – agents moving from assistants to autonomous operators – I wrote about the agentic turn earlier this year.

The Security Model Is Deliberately Constrained

The research preview requires a claude.ai account. Not an API key. Not Claude Console auth. A claude.ai login specifically.

That’s deliberate. Anthropic is keeping Channels in a managed, identity-verified context. Team and Enterprise organisations must explicitly enable the feature – it doesn’t light up by default. The allowlist mechanism (pair your account, restrict to your identity) is the security model.

This makes sense. A system that can push arbitrary events into an active Claude Code session with file system and terminal access is a significant attack surface. If you can push an event, you can trigger code execution. The identity constraint and the allowlist requirement are reasonable guardrails for an early-stage feature with high privilege.

It’s worth being clear about what this means operationally: anyone who can send a message to your paired Telegram bot can instruct your Claude session to run commands on your machine – unless you’ve configured the allowlist correctly. The allowlist isn’t optional. It’s load-bearing.

If you’re thinking about agent security more broadly, my post on agent pipeline hardening covers least-privilege patterns that apply directly here. And the NemoClaw security framework is worth reading for the guardrail layer above this.

Custom Channels via MCP

The official Telegram and Discord integrations are examples. The architecture is the point.

Any MCP server can be a channel. The Channels reference API lets you build your own – which means any external system that can emit a webhook can become an event source for Claude Code. The extension surface is everything that can speak HTTP.

GitHub webhook events: new PR, failed CI check, security advisory. PagerDuty alerts. Datadog threshold breaches. Jenkins build results. Sentry error spikes. Any of these can trigger a Claude Code reaction if you wire up the MCP server.

The pattern is: external system emits event, MCP server receives it, Claude Code session gets notified, Claude acts and optionally replies back through the channel. The whole loop is automated except for the actions Claude takes – and those are visible in the terminal, auditable, and configurable.

For teams building autonomous payment-capable agents, this is the missing event layer. You now have a way to get real-world triggers into a running session without polling or human relay.

The Always-On Agent Pattern

Channels enables a specific deployment pattern that wasn’t practical before: the always-on agent.

Run Claude Code in a persistent terminal – tmux, screen, whatever your preference. Keep the session open. Connect channels. Configure event sources to push to those channels. Define – through system prompt or initial instructions – what Claude should do for each event type.

CI fails: investigate and attempt a fix. Monitoring threshold breaches: diagnose and either remediate or escalate. New PR opened: review and leave comments. Dependency security advisory: assess and open a patching ticket.

None of this requires you to be present. The agent runs in your terminal, reacting to events, reporting outcomes back via Telegram or Discord. You check your messages in the morning and see what happened overnight.

This is the gap that’s existed since agentic workflows became practical. The tooling to write code autonomously has been there – Claude Code, solid MCP servers, shell access, file system access. What’s been missing is the event loop. The way to get things into a running session when no human is watching.

Channels is that event loop.

What This Actually Is

Channels isn’t the finished product for autonomous agent infrastructure. It’s a research preview with real constraints: claude.ai login required, enterprise opt-in, Telegram and Discord as the only official integrations, custom channels requiring you to build and host an MCP server.

But the primitive is right. An agent that can only act on what you type into it is a tool. An agent that can react to events happening in the world – CI failures, monitoring alerts, external triggers – is something closer to infrastructure.

The infrastructure for this has been missing. Channels is the first piece that makes it genuinely practical. That’s worth paying attention to, even if the finished version of this is still a year or two away.

The away problem has a solution now. It’s in research preview. It will get better.