# What Claude Code Notification Channels Are Actually For Most interactions with AI follow the same pattern: you write something, the AI responds. You ask, it answers. You type a command, it runs. That's **pull**. You initiate. You wait. You come back. Claude Code's **notification channels** break that pattern. They let the outside world push events into a running Claude session — without you typing anything. A build breaks. A customer files a ticket. A deploy finishes. Claude wakes up and acts. This isn't a small shift. It's the difference between an assistant you have to manage and a collaborator that stays on top of things while you're somewhere else. ## The Pull Problem When Claude only responds to what you type, there's an implicit assumption baked in: you're watching. You have to be present to move work forward. That's fine for focused sessions — pair programming, drafting, debugging with Claude live. But it creates a ceiling. The moment you step away, everything stops. Real workflows don't wait. CI runs at midnight. Alerts fire on weekends. Customers send messages during lunch. If your AI coding assistant can only act when you're actively typing, you're leaving most of its value on the table. ## What Channels Enable A channel is an event source that pushes notifications into Claude's context. Under the hood it's an MCP server that emits `notifications/claude/channel` messages — Claude receives them as `` tags in its conversation, understands what happened, and takes action. The key shift: **Claude can now react to your world, not just your prompts.** Some events that become actionable: **CI/CD pipelines.** A build fails on main. Claude gets the notification, reads the error, locates the relevant code, and drafts a fix — before you've even opened your laptop. By the time you check in, there's a PR waiting. **Monitoring alerts.** A service throws an error rate spike. Claude gets the alert, checks the logs, and either fixes the known issue or creates a task with its diagnosis for you to review. The on-call experience changes from "wake up and investigate" to "wake up and decide." **Customer support queues.** A new issue comes in. Claude reads it, checks the codebase for the relevant behavior, and drafts a response — or flags it as something that needs a code change, with the change already started. **Scheduled work.** Not every trigger is a fire. Channels can push routine events: "it's Monday, here's the week's open issues," or "deploy succeeded, run the post-deploy checklist." Claude acts on schedule without you setting up a cron job in your head. ## The Official Channels Anthropic ships three first-party channel implementations: **Telegram** — a bot you add to a Telegram group or DM. Claude can receive messages from you and reply back. Supports file attachments and permission relay (approving tool calls from your phone). Best for: async task briefs, quick replies from mobile. **Discord** — similar to Telegram but lives in your Discord server. Useful if you already use Discord for your team or project. Supports the same bidirectional flow. **iMessage** — for Apple users who want to interact with Claude through Messages. Same pattern: you send a message, Claude responds; or Claude initiates with a status update. All three support **permission relay** — when Claude wants to run a destructive tool (write to disk, execute a shell command, call an external API), the approval prompt can appear in your chat app. You type `yes ` or `no ` and Claude proceeds or stops. The first answer wins, whether it comes from the chat app or the local terminal. ## Two-Way Is Where It Gets Interesting One-way channels (push an event, Claude acts) are useful. Two-way channels — where Claude can also reply back through the same channel — are what make async workflows actually work. Without a reply path, you're flying blind. Claude took an action, but you don't know what it did, what it decided, or whether it got stuck. With a reply path, Claude narrates: "I saw the build failure, found the cause, here's the fix I'm proposing — let me know if you want me to commit." This is the human-in-the-loop pattern. Not "AI does things autonomously and you find out later." Not "you have to watch the terminal constantly." Something better: the AI works, keeps you informed, and waits for your judgment at the moments that actually need it. ## What's Worth Wiring Up Not every event is worth routing through Claude. Some things are better handled by simple automation. The useful filter: **is there reasoning involved?** A build failure with a consistent error pattern is worth routing — Claude can diagnose and fix. A build failure that's a flaky test in a known flaky suite probably isn't — Claude will waste effort on something a retry handles. Good candidates for channels: - Events that require reading code to understand (errors, alerts, issues) - Events that should trigger writing code (feature requests, bug reports) - Events where you'd normally have to interrupt what you're doing to triage Bad candidates: - Pure notifications (deploy succeeded, job finished) with no action needed - High-volume events that don't require individual attention - Anything where the right response is deterministic and doesn't need language reasoning ## Where AgentRQ Fits AgentRQ implements this pattern as a hosted service — you don't run a local webhook server or manage an allowlist. When Claude Code connects to AgentRQ via MCP, it gets a persistent task channel that any human in your workspace can send tasks to, from any device. The practical difference: AgentRQ is designed for the *task assignment* use case specifically. A human briefs a task from their phone. Claude works on it. If Claude needs a decision, it creates a task for the human and waits. The human replies. Claude continues. This is the same push-pull pattern that channels enable, but structured around the task lifecycle — not just raw event forwarding. And it runs on someone else's infrastructure, so you don't have to keep a server alive to stay connected. ## The Shift Worth Making Notification channels are small to set up and large in what they change. The old model: Claude Code is a tool you pick up and put down. You get value when you're using it; nothing happens when you're not. The new model: Claude Code is a collaborator that stays live. You define what events it should respond to, what it should do, and when it should check in with you. It works in the background; you stay in the loop without having to be present. The channel is just the wire. What matters is what you connect it to — and what you trust it to do autonomously, versus what you want to decide yourself. [Connect Claude Code to AgentRQ](/docs/getting-started) to get the task channel pattern running in 60 seconds, without running your own server.