Lesson 40: Channels & Remote Control
Day 40 of 50 · ~7 min read · Phase 5: Advanced Patterns
The Opening Question
Imagine this: You're in a meeting. You can't leave. A bug is being reported in Slack. Your CI pipeline failed. You need Claude Code to handle it — but you're away from your laptop.
You pull out your phone, open Telegram, and message your Claude Code bot:
@claude-code-bot: Check the latest CI failure and report back
Two minutes later, a summary appears in Telegram: "CI failure due to missing dependency in auth.js. Automatically fixed and tests passing."
Here's the question: how does an AI coding agent become a responsive, event-driven system you can reach from anywhere?
The answer is channels.
Discovery
Question 1: What is a channel?
You've been using Claude Code as a pull model: you open your terminal, you ask Claude Code to do something, it responds. You're the initiator.
A channel inverts this. It's a push model: external systems can push events into your Claude Code session, and Claude reacts.
A channel is an MCP server that connects Claude Code to:
- Telegram — Message your bot, get responses
- Discord — Commands in a server channel
- iMessage — Control Claude Code from your phone
- Webhooks — CI pipelines, monitoring alerts, external systems
- Custom sources — Anything with an API
When someone sends a message to your channel, the MCP server forwards it to Claude Code. Claude processes it, uses your files and tools, and sends a response back through the same channel.
Simple flow:
Telegram message: "Review this PR"
↓
MCP channel server receives it
↓
Claude Code session processes it
↓
Claude reads files, runs tools, analyzes PR
↓
Response goes back to Telegram
Pause and think: why would you want Claude Code to be responsive instead of on-demand?
Question 2: How do you set up a channel?
Channels are configured via MCP. You define which platforms Claude Code listens to, and which users can send messages.
Example: Telegram channel setup
# CHANNELS in CLAUDE.md
## Telegram
- Bot token: [your bot token from @BotFather]
- Allowed users: [your Telegram ID, team member IDs]
- Timeout: 5 minutes (how long Claude has to respond)
Claude Code comes with channel presets. You generate a bot token from Telegram, add it to your config, and Claude Code listens for messages.
Example: Webhook setup
## Webhook Channel
- Endpoint: /webhook/ci-events
- Allowed sources: [your GitHub Actions IP]
- Events: [push, pull_request, workflow_failure]
When your CI pipeline completes, it sends a webhook. Claude Code receives it, analyzes the results, and posts a summary back to your repo.
Question 3: When should you use channels?
Channels are powerful but not always necessary. Think about the use case:
Great for channels:
- Reactive tasks: "Something broke, react to it" (CI failure, production alert)
- Remote work: Control from phone/remote without SSH
- Collaborative: Team members can trigger tasks from Slack/Discord
- Event-driven: Continuous integration, monitoring alerts, scheduled webhooks
- Quick feedback: "Is this PR good?" without context-switching
Less useful for channels:
- Long-running tasks: File editing (you want to see proposed changes)
- High-stakes decisions: Production deployments (you want full control)
- Detailed work: Architecture design (you need back-and-forth conversation)
- Private work: Code review on secure codebases (channels add complexity)
Rule of thumb: Use channels for notifications and reactions. Use interactive Claude Code for decisions and complex work.
Question 4: What's the security model for channels?
Channels are powerful, which means security is critical.
Key principle: Sender allowlist
Every channel maintains a strict list of who can send messages:
- Telegram: Only specific Telegram user IDs can message your bot
- Discord: Only specific Discord users in a private channel
- Webhook: Only requests from whitelisted IP ranges
- iMessage: Only from your phone number
If someone not on the allowlist tries to use your channel, the message is silently dropped. No notification. No leak.
Additional safeguards:
- Scoped permissions: What can this channel trigger? Limited to read-only? Limited directories?
- Command whitelisting: Only specific tasks are allowed via channels
- Logging: Every channel message is logged so you can audit who did what
- Timeout protection: If Claude takes too long, the request fails safely
The Insight
Channels transform Claude Code from a pull-based tool (you invoke it) to a push-based system (it reacts to events). This unlocks remote control, automation, and responsive coding. But channels also introduce security complexity — you must use sender allowlists, scope permissions carefully, and understand that external access requires intentional setup.
The mental model: A channel is like giving trusted colleagues a button to trigger specific tasks. You've decided what buttons exist, who can push them, and what happens when they do. You're not giving them your terminal — you're giving them a curated set of actions.
Try It
Let's set up a simple channel.
-
Choose a platform (Telegram is easiest):
- Create a Telegram bot by messaging @BotFather
- Get your bot token and Telegram user ID
-
Configure the channel in CLAUDE.md:
# Channels ## Telegram bot_token: [paste your token] allowed_users: - [your Telegram ID] allowed_tasks: - "status" — report current session status - "review-pr" — quick PR analysis - "test" — run tests and report results timeout: 300 # 5 minutes -
Test it:
- Open Telegram and message your bot: "@your-bot status"
- Claude Code should respond with session information
- Try: "@your-bot test" (if tests are configured)
-
Add another user (if you have a team member):
- Get their Telegram ID
- Add to
allowed_users - They can now trigger tasks (but only the ones you've whitelisted)
-
Monitor usage:
- Check
.claude-logs/channels.logto see who triggered what and when
- Check
Key Concepts Introduced
| Concept | Definition |
|---|---|
| Push model | External systems initiate actions (opposite of pull) |
| Channel | An MCP server that connects Claude Code to messaging platforms |
| Sender allowlist | Strict list of who's allowed to send messages to a channel |
| Event-driven | Claude Code reacts to events (CI failure, monitoring alert) instead of being invoked |
| Scoped permissions | Channels have limited permissions (read-only, specific directories, whitelisted tasks) |
| Remote control | Ability to trigger Claude Code from anywhere (phone, Slack, Discord) |
Bridge to Lesson 41
You've learned to scale Claude Code locally (subagents), automate it (headless), optimize it (cost), navigate large codebases (strategic reading), secure it (permissions), and extend it beyond your machine (channels).
But there's one more dimension: cloud infrastructure.
What if you didn't run Claude Code on your laptop? What if you ran it on AWS, Google Cloud, or Microsoft Azure? What if your enterprise required code to stay within their cloud boundaries?
Tomorrow's question: How do you integrate Claude Code with cloud providers?