Original URL: https://getagenttools.com/blog/claude-code-channels/ # Claude Code Channels: Incoming Events, Access and Session Limits 8 Oct 2026Marek. - claude-code-channels - claude-code - agent-security A build alert arriving in Claude Code sounds useful. A stranger in the same chat room being able to send the next instruction sounds less useful. Both travel through the same bridge unless someone decides who is allowed through. That is the question I would settle before connecting Claude Code Channels to work that matters. The plugin is only part of the setup. Someone also has to own the running session, the sender list and the decision about what an incoming message is allowed to cause. - **The entry point:** an MCP bridge puts external events into a local session. - **The process:** that session must still be running when the event arrives. - **The sender:** room membership is a poor substitute for individual authorization. - **The approval:** delivery and permission relay are separate paths to check. - **The missing result:** this article gives a test plan, not a completed native Channels trial. The [Slack Code channels article](https://getagenttools.com/blog/slack-code-channels/) covers a different product. Similar names make this easy to mix up, but the process that receives the work is what matters. ## What receives a Claude Code channel event? Native Channels push incoming events from an MCP server into a running Claude Code session. A bridge can send a one-way notification or provide a reply tool for a two-way conversation. The agent receives another input, with its source and metadata, alongside the conversation it already has. For a build alert, I would want a job ID, repository and run reference. Enough to find the failed job. Sending the entire confidential log because the bridge can carry it is a different decision, and usually an unnecessary one. Channels do not automatically make that redaction decision for you. Anthropic's [Channels reference](https://code.claude.com/docs/en/channels-reference) defines a local MCP subprocess using stdio, the `claude/channel` capability and `notifications/claude/channel` events. A generic webhook that tells an AI service something happened is not automatically a native channel. The bridge has to implement that contract. Availability matters before any of this works. The [official overview](https://code.claude.com/docs/en/channels) calls Channels a research preview and requires claude.ai authentication or a Console API key. It lists the feature as unavailable on Bedrock, Google Cloud's Agent Platform and Microsoft Foundry. Team and Enterprise organizations must enable it explicitly. Check those prerequisites against the account you actually use before troubleshooting a plugin. I have not run a native Channels delivery, sender-rejection or permission-relay test. The setup and checks below come from that documented contract. A Telegram bot working elsewhere would not fill those gaps. ## Does the Claude Code session need to stay running? Yes. Events arrive while the Claude Code session is open. Installing a plugin does not create a separate worker that will start itself whenever a message arrives. This changes how I would use the feature. A channel attached to an open development session can bring a build failure into the work already underway. Depending on the same session for unattended alerts also gives you a process to keep alive. The machine can restart. The session can be sitting at a prompt. Someone can close the terminal. So who starts it again? Where can you see that it is waiting? Who notices if it stops? Those questions belong in the setup notes, because the chat interface will not answer them. There is also a gap between "sent" and "received." A platform may accept a message while the local session is down. Retry and retention behavior depend on the source and bridge. The running-session requirement is not a promise of durable queuing, and a sent marker in chat is not proof that the agent saw anything. I would test that gap with a disposable event. Stop the session, send the event, restart, and record what happens at each end. Does the sender get an error? Does the bridge keep the event? Does it arrive later? Keep the result for that exact plugin and version. That is more useful than assuming every bridge handles downtime the same way. ## Start locally, before bringing a real account into it Anthropic supplies fakechat as a local demo without an external messaging account. Its documented setup is: ```text /plugin install fakechat@claude-plugins-official ``` Then start the session with the channel enabled: ```sh claude --channels plugin:fakechat@claude-plugins-official ``` The demo UI is at `http://localhost:8787`. The supplied plugin requires Bun. These are official setup instructions, not commands executed for this article. Check the plugin and installation scope before adding it to your environment. Use an empty project with synthetic files. Ask a harmless question about one file and look at both ends: the event in the terminal and the reply in the demo UI. Record the client and plugin versions. A screenshot of a reply tells you less than it seems if you cannot say which session produced it. That local test explains the path through the session. It does not establish Telegram or Discord pairing, webhook authentication or who can approve an action remotely. Those are additional boundaries. For a real platform, use a dedicated test account and its official plugin instructions. Keep tokens in the configured secret location, out of the repository and diagnostic logs. A shared room with unrelated people is a poor place to find out what the bridge forwards. ## How do I restrict who can send channel events? Gate the individual sender before forwarding the notification. Anthropic's reference recommends an allowlist for public or chat-backed bridges. Authorizing a room is not enough: two people in the same group can have very different authority over the repository behind it. The check I want is small. One trusted test identity, one untrusted test identity, the same harmless message. The trusted message should arrive. The untrusted message should be dropped before it enters the model's context. The positive case matters too. If neither arrives, the bridge may simply be broken. Keep the evidence at that gate. An agent replying "I cannot help" is not the same result as the bridge rejecting the sender. The reply may mean the message already reached the model. For a custom server, a safe record can hold the event ID, sender class and accepted or rejected status. It does not need the message body or credentials. I would also check removal while the test identity is still available. Remove it, repeat the message, inspect the gate. Group membership changes are not proof that the bridge's allowlist changed. The access control is whichever setting the bridge actually reads, and someone needs to own that list after installation too. ## Do channel events bypass normal permissions? No. An incoming event gives the agent input. It does not grant blanket permission to use tools. An action that needs approval can still pause the session. A two-way channel may opt into permission relay, sending a pending approval out for a remote decision. That is more authority than receiving a notification, so I would review it separately. Can this plugin relay decisions? Which sender can answer? Does the answer match the action that is still pending locally? The [permission relay reference](https://code.claude.com/docs/en/channels-reference#relay-permission-prompts) says the decision must match an open request ID. The local prompt stays active and the first applicable answer wins. Project trust and MCP server consent dialogs remain local. Those are documented rules, not results from a relay trial here. For the test, use a reversible action inside the disposable project that your ordinary settings require you to approve. Deny it. Then inspect the resulting file or other state. The useful answer is whether the action occurred. A refusal sentence in the chat interface does not settle that. I would not use a production deployment, a real secret or a message to another person as the probe. A dummy local change is enough to check the approval path without introducing another problem. ## Are Channels the same as Remote Control? No. Channels bring source events into the session through an MCP bridge. Remote Control gives you a web or mobile interface to a local session. Session scheduling runs a prompt on an interval. Pick the mechanism for the trigger you need, then check its process lifetime. | Need | Mechanism to inspect | Main acceptance question | | --- | --- | --- | | React to a build or chat event | Channels | Did an authorized event reach the intended session? | | Continue a local conversation from a phone | Remote Control | Is the remote interface connected to the correct local session? | | Check a status periodically | Session scheduling | Does the task fire at the intended time and stop correctly? | The [Remote Control documentation](https://code.claude.com/docs/en/remote-control) says code execution and filesystem access stay on the local machine. The [session scheduling documentation](https://code.claude.com/docs/en/scheduled-tasks) distinguishes session tasks from independent desktop or cloud schedules. An interface on your phone does not make the worker a hosted service. If the requirement is to start a worker for a job, finish and exit, I would inspect the [Claude Code headless workflow](https://getagenttools.com/blog/claude-p-headless/) instead. It needs a trigger and job management of its own. That may be exactly what you need, but it is a different process from feeding events into a session that is already running. ## What I would want on file before increasing scope The acceptance record can be short. Trusted sender delivered. Untrusted sender dropped at the gate. Stopped-session behavior observed. Denied action absent. Recovery after restart checked. Alongside those observations, keep the client and plugin versions and the expected result. Leave personal message content and credentials out. Then send the same disposable event twice. A source retry should not cause the same repair twice. Finally, stop the bridge and verify which process ended. A closed window is not a shutdown record if another process is still listening. Those are the checks still to run here. Until they exist, I would describe the setup as documented and proposed, not tested. The feature is useful precisely because it can bring outside events into ongoing work. That is also why the sender list and the life of the receiving session deserve as much attention as the install command. Put this into practice [See the tool list](https://getagenttools.com/tools/)[Train your team](https://getagenttools.com/#training)