Skip to content
Datfx Labs Claude Guide

Channels (Research Preview)

Research Preview: Channels are an experimental feature. The API and behavior may change before general availability. Opt-in is required.

Normal Claude interaction is pull-based: you send a message, Claude responds. Channels invert this. An external system — a monitoring tool, a CI pipeline, a webhook handler — pushes a message into a running Claude session, and Claude responds automatically.

The session becomes reactive. Claude doesn’t wait for you to ask. It acts when something worth acting on happens.

The Core Difference: Pull vs Push

flowchart LR subgraph Pull["Standard (Pull)"] U1([You]) -->|ask| C1[Claude] C1 -->|respond| U1 end subgraph Push["Channels (Push)"] EXT[External System] -->|event fires| MCP[MCP Server] MCP -->|channel message| C2[Claude Session] C2 -->|action / output| OUT([Result]) end style U1 fill:#1e293b,color:#7dd3fc,stroke:#334155 style C1 fill:#1e293b,color:#7dd3fc,stroke:#334155 style EXT fill:#1e293b,color:#fcd34d,stroke:#334155 style MCP fill:#1e293b,color:#7dd3fc,stroke:#334155 style C2 fill:#1e293b,color:#7dd3fc,stroke:#334155 style OUT fill:#1e293b,color:#86efac,stroke:#334155

In the pull model, Claude is passive until you engage. In the push model, Claude is an active participant in your system — triggered by events, not just prompts.

How Channels Work

Channels are implemented on top of MCP (Model Context Protocol). An MCP server that implements the channel protocol can send structured messages directly into a Claude session’s input stream. From Claude’s perspective, a channel message arrives the same way a user message does — it reads it and responds.

The flow:

  1. An event occurs in an external system (alert fires, build fails, webhook received)
  2. The external system calls the MCP server’s channel endpoint
  3. The MCP server forwards the message to the target Claude session
  4. Claude receives the message and takes action
  5. Claude’s response goes to the configured output (a Slack channel, a GitHub comment, a log, etc.)

The session must be active to receive channel messages. A paused or completed session does not receive messages.

Configuration

Channels require explicit opt-in. In your session settings:

{
  "channels": {
    "enabled": true,
    "sources": ["datadog-alerts", "github-ci"],
    "permissions": ["read-logs", "create-issues", "post-comments"]
  }
}

The sources list specifies which MCP servers are allowed to push into this session. Unlisted sources are rejected. The permissions list scopes what Claude is allowed to do in response to channel messages — Claude cannot take actions beyond what the session’s channel permissions allow.

Note: Claude does not receive channel messages from unauthenticated sources. MCP servers must authenticate with the session before sending channel messages.

Use Cases

Monitoring and incident response

Your monitoring system detects a spike in 5xx errors. Instead of paging a human to start investigating, it pages Claude:

Alert: 5xx error rate is 12% on /api/checkout (up from 0.3% baseline).
Started approximately 14 minutes ago. Investigate.

Claude checks recent logs, traces the error to a specific function, cross-references recent deploys, and posts a summary:

Root cause: null pointer exception in PaymentService.processCharge()
introduced in commit a3f9b2 (deployed 14 min ago).
Affects: all checkout requests where shipping address is outside US.
Fix: PR #847 ready for review. Recommend immediate rollback pending merge.

All of this happens automatically, before a human has even opened their laptop.

CI/CD failure triage

Build failed: test suite in src/auth/ — 3 failures.
Logs attached. Investigate and create GitHub issues.

Claude reads the failure logs, groups failures by root cause, and creates labeled GitHub issues with suggested fixes — without anyone manually triaging the CI output.

Webhook-driven automation

New GitHub issue #312: "Login fails on Safari 17"
Labels: bug, authentication. No assignee.
Triage and label appropriately.

Claude reads the issue, checks for related issues, assesses severity, adds labels, and may add a first-response comment with reproduction steps — before a human has seen the notification.

Scheduled data feeds

A scheduled job pushes a daily data snapshot into Claude’s session:

Daily metrics snapshot attached.
Generate the weekly trend summary for the engineering digest.

Claude produces a narrative summary of the data, ready to paste into the team newsletter.

Channels vs Hooks

These are related but distinct:

HooksChannels
TriggerClaude’s own actions (pre/post tool use)External system pushing in
DirectionClaude → hook → Claude (intercept)External → Claude (inject)
Use whenYou want to intercept or augment Claude’s tool callsYou want external events to trigger Claude

Hooks are for modifying Claude’s behavior as it works. Channels are for getting Claude to start working in response to something outside its control.

See Hooks for the hook-based intercept pattern.

Channels vs /loop

Both enable Claude to act without a human prompt, but they differ in how the trigger works:

/loopChannels
Trigger mechanismClaude polls on a timerExternal system pushes
LatencyBounded by poll intervalNear real-time
External system requirementNone (Claude does the polling)Must implement channel protocol
Use whenExternal system can’t push; polling is acceptableReal-time response matters; system can implement push

If the external system can push, channels are more efficient and more responsive. If you don’t control the external system (or it doesn’t support webhooks), /loop with polling is the practical alternative.

See Loop for the polling-based approach.

Security Model

Channels are designed to be safe by default:

  • Explicit opt-in: channels must be enabled in session settings. No session receives channel messages unless it has opted in.
  • Source allowlist: only MCP servers listed in sources can push messages. Unlisted sources are rejected without notification to the sender.
  • Permission scoping: Claude’s channel permissions are separate from its general session permissions. A session with broad file-write access can have narrow channel permissions (e.g., read-only) to limit what channel-triggered actions can do.
  • Authentication: MCP servers must authenticate before the channel connection is established. Unauthenticated push attempts are silently dropped.

The threat model: a compromised external system that gains access to a channel endpoint should still be limited by the permission scope. Design channel permissions conservatively — grant only what the specific use case requires.

Limitations

  • Active session required: the session must be running to receive messages. A session that’s been idle for hours may need to be reactivated before it can receive channel messages.
  • Experimental API: the channel protocol spec is subject to change. Code built against the current API may need updates before GA.
  • MCP server implementation required: the external system (or an intermediary) must implement the channel protocol. Channels don’t work with arbitrary webhooks out of the box — there’s an integration layer.
  • One session per channel source: a given MCP server channel endpoint connects to one session at a time. Fan-out to multiple sessions requires multiple channel connections.

Full Example: Datadog Alert to Incident Summary

Setup:

  • Datadog alert configured to call the MCP channel endpoint on threshold breach
  • Claude session running with channels.sources: ["datadog-mcp"]
  • Session permissions: read-logs, read-traces, post-slack-message

Flow:

1. Datadog: 5xx rate crosses 10% threshold on /api/checkout
2. Datadog fires webhook → MCP server receives it
3. MCP server sends channel message to Claude session:
   "Alert: 5xx error rate is 12% on /api/checkout.
    Started 14 min ago. Runbook: https://wiki/checkout-runbook
    Investigate and post summary to #incidents."


4. Claude reads recent error logs (read-logs permission)
5. Claude pulls distributed traces for failing requests (read-traces)
6. Claude identifies: null pointer in PaymentService, commit a3f9b2, deployed 14 min ago
7. Claude posts to #incidents (post-slack-message permission):
   "Root cause identified: PaymentService.processCharge() null pointer
    on non-US addresses. Introduced in a3f9b2 (14 min ago).
    PR #847 ready. Recommend rollback while PR is reviewed."


Total time from alert to summary: ~90 seconds.
Human involvement: reviewing the summary and approving the rollback.

This is the channels value proposition: the slow, manual parts of incident response (log triage, trace analysis, root cause hypothesis) happen automatically. You arrive at the decision point — rollback or not — with the analysis already done.

  • Hooks — intercept Claude’s own tool calls
  • MCP — the protocol channels are built on
  • Background Tasks — long-running sessions without interactive guidance
  • Loop — polling-based alternative when push isn’t available