Before you wire anything yourself, check whether the official Anthropic Channels feature covers what you need. Channels is bidirectional — you can both push events and chat back from your phone. Telegram, Discord, iMessage are supported on the Web/Desktop app. For pure event push from the CLI, Channels is the cleanest first choice. The MCP-multi-channel path below is the right pick when you want full control of routing rules, multiple channels at once, custom webhook destinations, or you are running Claude Code in a non-Desktop environment.

Try Channels first if you only need one or two notification destinations. Continue with this recipe if Channels is not enough.

This is the most important step and the easiest to get wrong. Pick the channel where you will see the message within an hour, on a normal day, without effort. Common honest answers:

• Telegram — best if you live on your phone, do not check email, and want push notifications without enterprise overhead.
• Discord — best if you are already in a server you check daily, or you want a public/team channel.
• Slack — best if you are at a company that uses Slack and your AI work overlaps with team work.
• Email — best for digests (morning brief, weekly review). Bad for "build finished" pings — too slow.
• Webhook to your own server — best if you want to route to multiple channels with custom rules.

Pick exactly one for the first wire-up. Add others later if needed.

Two paths, pick one:

• Webhook-direct (recommended starter). No MCP server at all — just curl in a Stop hook (Step 5) or a one-line bash call from Claude. Works for every channel that has a webhook (Telegram bot API, Discord channel webhook, Slack incoming webhook, ntfy, your own server). Lowest dependency, fastest to wire up.
• Single-platform MCP. Search npm for the channel you want — mcp-telegram, mcp-discord, mcp-slack and similar packages exist with varying maintenance levels. They wrap the channel's API behind MCP send / list tools so the agent picks the right destination automatically. Worth the dependency if you want the agent to choose between channels in one call.

For the rest of the recipe we walk the webhook-direct path with Telegram. Substitute another channel's URL where Telegram appears — the rest is the same.

If Telegram is your channel:

1. Open @BotFather on Telegram, send /newbot, follow the prompts. Save the bot token (1234567890:ABC...).
2. Send your new bot a "hi" message so a chat exists between you.
3. Hit https://api.telegram.org/bot<TOKEN>/getUpdates — the JSON contains chat.id. Save it.

For Discord: create a webhook on a channel via Server Settings → Integrations → Webhooks. Copy the URL. For Slack: create an incoming webhook in your workspace's app config. Copy the URL.

Stick the credentials in ~/.claude/settings.json under env so hooks can read them:

{
  "env": {
    "TG_TOKEN": "1234567890:ABC...",
    "TG_CHAT": "123456789"
  }
}

The messaging_bridge_active validator runs claude mcp list and looks for multi-channel, telegram, discord, slack, or matrix in the server names — useful if you went the MCP-server path. For the webhook-direct path, just hit the API once from your shell to confirm credentials work:

TG_TOKEN=...your-token... TG_CHAT=...your-chat... \
  curl -s -X POST "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
  -d "chat_id=$TG_CHAT" -d "text=test from claude"

If a message arrives in your Telegram chat, the credentials are correct. Stop hook (Step 5) does the same call from Claude.

Notifications only land if something triggers them. Two trigger patterns:

• In-prompt — you ask the agent to send a notification at the end of a long task. Works for one-off "ping me when this build finishes".
• Hook-based — fires automatically on session end. Works for "ping me whenever a long Claude Code session closes".

For the hook pattern, in ~/.claude/settings.json (merge with existing hooks):

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "curl -s -X POST \"https://api.telegram.org/bot$TG_TOKEN/sendMessage\" -d \"chat_id=$TG_CHAT\" -d \"text=Claude session ended\""
          }
        ]
      }
    ]
  }
}

That fires every time a session closes — one curl, fast, no roundtrip.

If you want the bot to also include a session summary (more useful for long sessions), wrap a one-shot headless Claude:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'SUMMARY=$(echo \"summarize this session in one line\" | claude --headless --no-tty); curl -s -X POST \"https://api.telegram.org/bot$TG_TOKEN/sendMessage\" -d \"chat_id=$TG_CHAT\" -d \"text=Session ended: $SUMMARY\"'"
          }
        ]
      }
    ]
  }
}

For just the "build finished" case, a simpler hook on PostToolUse for specific tools:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash(npm run deploy*)",
        "hooks": [
          {
            "type": "command",
            "command": "curl -s -X POST \"https://api.telegram.org/bot$TG_TOKEN/sendMessage\" -d \"chat_id=$TG_CHAT\" -d \"text=Deploy finished\""
          }
        ]
      }
    ]
  }
}

Note the "matcher" + "hooks": [{ "type": "command", "command": "..." }] nesting — same shape as the safety-guard hook from Recipe 1.3. The flat { "command": ..., "args": [...] } form silently does nothing — Claude Code's harness ignores entries that miss the "hooks" array wrapper.

Three rules so notifications stay useful instead of becoming noise you mute:

• Notify on completion or failure, not progress. "Build started" is noise. "Build finished" or "Build failed: X" is signal.
• One channel per signal class. Morning brief → email. Build/deploy → Telegram. Ad-hoc agent finish → Telegram. Not "everything everywhere".
• Mute the bot during deep work. If you are coding 9-12, mute the Telegram bot for those three hours. Notifications you cannot respond to are stress, not information.

The right number of notifications per day for one person is 2-5. More than that, you start ignoring them. If you are getting 20 a day, the system is over-alerting and you need to tighten the triggers, not add more channels.

If you have your own server (n8n, your own Node service, anything that accepts a webhook), point the agent at that and route from there. Pattern:

Send to channel=webhook url=https://hook.mydomain.com/agent-events body={"event":"build_done","status":"ok"}

Your own server then decides what to do — fan out to Telegram + Slack + email, dedupe, batch into a daily digest, whatever you need. This is what you reach for when "always notify" is too much and "never notify" is too little, and you want a programmable middle layer.

For the average personal setup, single-channel direct (Telegram + a Stop hook + a build hook) is enough. Webhooks are for when notifications become their own product.