Hai presente quando stai aspettando un deploy, sei fuori casa, ti viene in mente una cosa da fixare e pensi “ah, se solo potessi dire a Claude di farlo adesso”? Ecco, ora puoi.
I channels sono server MCP che spingono eventi dentro la tua sessione Claude Code mentre è aperta. Non spawn di sessioni cloud nuove, non polling ogni tot minuti – l’evento arriva nella sessione che hai già lì che gira, con i tuoi file aperti, il contesto di quello che stavi facendo.
Come funziona in pratica
Esempio concreto: installi il plugin Telegram, configuri il bot, lanci Claude Code con --channels. Sei in metro, apri Telegram, scrivi al tuo bot “hey, quella funzione di login ha ancora il bug del timeout?”. Il messaggio arriva nel terminale dove Claude sta girando, lui fa il check, ti risponde via Telegram. Nel terminale vedi il tool call e “sent”, la risposta vera te la ritrovi in chat.
Due-way: leggi evento, Claude risponde attraverso lo stesso canale. Tipo chat bridge, ma con accesso ai file veri sulla tua macchina.
Canali supportati (per ora)
Nella research preview ci sono:
- Telegram – crei un bot con BotFather, gli dai il token, fatto
- Discord – stesso flow, bot nel server, token, via
- Fakechat – demo localhost per testare senza autenticare niente, interfaccia web su porta 8787
Setup base per Telegram (Discord è identico):
- Crei il bot (
/newbota BotFather) /plugin install telegram@claude-plugins-official/telegram:configure <token>- Rilanci con
claude --channels plugin:telegram@claude-plugins-official - Mandi un messaggio al bot, lui ti dà un pairing code
/telegram:access pair <code>/telegram:access policy allowlistper bloccare tutto tranne te
Security: chi può mandarti roba
Ogni channel ha una allowlist. Solo gli ID che approvi possono pushare messaggi, il resto viene droppato silenziosamente. Il pairing serve a quello: mandi messaggio al bot, lui ti dà codice, tu lo approvi nel terminale, il tuo sender ID finisce nella lista.
Essere in .mcp.json non basta – il server deve anche essere nominato in --channels quando lanci la sessione. Controllo doppio.
Per Team/Enterprise c’è channelsEnabled nelle managed settings – gli admin devono abilitarlo esplicitamente, default è off.
Il caso d’uso che mi ha fatto alzare le sopracciglia
Webhook receiver. Tipo: hai Claude Code aperto che sta debuggando un problema di deploy. Arriva webhook da CI che il build è fallito di nuovo. Invece di switchare finestra, controllare logs, copiare errore, tornare al terminale – il webhook arriva dove Claude ha già tutto il contesto aperto. Lui vede l’errore, sa cosa stavi facendo, può correggere subito.
O error tracker che ti pinga “eccezione nuova in produzione” – Claude la riceve nella sessione dove ha già i file aperti, stack trace a portata, storia di cosa hai modificato oggi.
Confronto con le altre feature
Claude Code ha tipo quattro modi di connettersi a roba esterna, ognuno per un use case diverso:
- Web sessions – spawn sandbox cloud pulito clonato da GitHub, per task self-contained async
- Slack integration –
@Claudein un thread spawna web session, comodo per partire dal contesto di conversazione team - MCP server standard – Claude lo interroga on-demand durante task, niente push
- Remote Control – guidi la sessione locale da claude.ai o mobile app
- Channels (nuovo) – eventi pushati dentro sessione già aperta
I channels riempiono il buco: roba che viene da fuori (Telegram, webhook, Discord) arriva dove Claude sta già lavorando sui tuoi file veri con tutto il contesto.
Quickstart con fakechat
Se vuoi testare senza configurare bot veri:
/plugin install fakechat@claude-plugins-official
claude --channels plugin:fakechat@claude-plugins-officialApri localhost:8787, scrivi “what’s in my working directory?”, il messaggio arriva nel terminale come evento <channel source="fakechat">, Claude risponde, vedi la risposta nel browser.
Note tecniche sparse
Permission prompts: se Claude chiede conferma per un tool mentre sei lontano dalla tastiera, la sessione si blocca. Channels che dichiarano permission relay capability possono forwardare questi prompt dove puoi approvarli/negarli da remoto. Oppure --dangerously-skip-permissions bypassa tutto, ma solo in ambienti fidati.
Research preview: --channels accetta solo plugin da allowlist Anthropic-maintained. Quelli in claude-plugins-official sono approvati. Per testare channel custom che stai buildando, usa --dangerously-load-development-channels.
Enterprise: Team/Enterprise hanno channels disabilitati di default. Admin deve enablere da claude.ai → Admin settings → Claude Code → Channels o settare channelsEnabled: true nelle managed settings.
Il pattern che emerge
Quello che mi piace: non è “Claude risponde a webhook”, è “Claude che sta già lavorando sui tuoi file riceve eventi mentre lavora”. La differenza è grossa. Non parte da zero ogni volta, ha il contesto, sa cosa stai debuggando, quali file hai modificato.
Tipo avere un collega che sta già guardando il codice con te e gli arriva una notifica Slack – lui già sa di cosa si parla, non deve riaprire tutto.
