Più sessioni di Claude Code: come farle parlare fra loro

Un messaggio cross-sessione di Claude Code è un messaggio che una sessione manda direttamente a un'altra sessione, anche quando le due girano su macchine diverse. Far parlare fra loro più sessioni di Claude Code non è più un problema da risolvere a mano: il changelog ufficiale di Claude Code registra nella versione 2.1.224, pubblicata il 7 agosto 2026, SendMessage cross-sessione e il comando ListAgents per scoprire quali sessioni sono raggiungibili, su macOS e Linux.

Fino a ieri chi teneva più agenti al lavoro sullo stesso progetto li faceva coordinare come si coordinano due processi che non si conoscono: un file di stato, un branch, un commit, un campo dentro il repository. Funziona, ed è il motivo per cui continuerà a funzionare anche adesso. Ma è comunicazione asincrona travestita, e paga il conto quando due agenti lavorano nello stesso momento e l'informazione serve subito.

Cosa cambia quando due sessioni di Claude Code si possono scrivere

Cambia che l'unità di lavoro non è più la sessione singola. Con SendMessage cross-sessione una sessione smette di essere una scatola chiusa che comunica col mondo solo attraverso i file che lascia in giro, e ListAgents le dà un modo per sapere chi altro sta lavorando in quel momento. È una differenza di modello mentale prima che di funzionalità: si passa dal ragionare su un agente al ragionare su una flotta.

Insieme al messaggio arrivano due impostazioni che vale la pena guardare subito, crossSessionInbound e dialogExpiry. Il changelog di Claude Code 2.1.224 descrive il comportamento in modo preciso: i messaggi cross-sessione diretti a una sessione che gira con i permessi bypassati vengono trattenuti in attesa di approvazione, mentre i messaggi verso le altre sessioni vengono consegnati automaticamente. È la scelta giusta, e ha una logica che si capisce solo pensando all'attaccante: una sessione senza dialoghi di permesso è esattamente il posto dove un messaggio in arrivo diventa un modo per far fare qualcosa a una macchina senza chiedere niente a nessuno.

C'è poi una correzione che dice più della funzione stessa. La 2.1.224 sistema SendMessage che riportava "Message sent" anche quando la scrittura nella casella del destinatario era in realtà fallita, e adesso le consegne fallite vengono segnalate come errori. Chi costruisce un coordinamento fra agenti su una consegna che si dichiara riuscita quando non lo è si ritrova con due sessioni convinte di essersi parlate e nessuna delle due che aspetta. Questo tipo di bug non produce un crash, produce un lavoro fatto due volte o un lavoro non fatto affatto.

Perché è sparito il tetto dei 200 subagenti per sessione

Claude Code 2.1.224 rimuove il tetto di 200 subagenti generabili in una singola sessione, e il changelog precisa che i limiti di concorrenza e di profondità restano in vigore. Tradotto: non cambia quanti agenti girano insieme nello stesso istante, cambia che una sessione lunga non arriva più a un punto in cui rifiuta di crearne di nuovi.

Il tetto dei 200 era un limite pensato per sessioni che durano un'ora. Toglierlo nello stesso rilascio in cui le sessioni imparano a parlarsi fra loro non è una coincidenza: sono due pezzi della stessa direzione, cioè sessioni che restano vive a lungo e che nel frattempo delegano molto. Chi lascia girare un agente per una giornata intera su un refactor grosso lo stava già toccando, quel muro, e lo toccava sempre nel momento peggiore, dopo ore di contesto costruito.

Su questo sito il coordinamento fra agenti esiste già, e non usa nessuna di queste novità. Nella cartella automazione-blog/cloud-agent/ stanno due prompt distinti, uno per gli articoli di attualità e uno per gli articoli business, che girano ogni mattina a mezz'ora di distanza sullo stesso repository. Non si mandano messaggi: quando uno dei due pubblica lascia il campo sourceId nel frontmatter dell'articolo, e l'altro legge quel campo con un grep su content/blog/ per sapere quale notizia è già stata presa. È coordinamento tramite tracce lasciate su disco, ed è la cosa giusta finché il segnale che devono scambiarsi è "questo l'ho già fatto io". Se dovessero invece contrattare chi prende cosa mentre entrambi stanno ancora leggendo le fonti, il file smetterebbe di bastare e servirebbe esattamente il messaggio diretto.

Dove girano le sessioni: il self-hosted runner

La 2.1.224 introduce anche claude self-hosted-runner, che trasforma macchine o container propri nel posto in cui girano le sessioni di Claude Code avviate da web, mobile e desktop. Il changelog ufficiale lo indica disponibile sui piani Team ed Enterprise.

Messo accanto ai messaggi cross-sessione, il senso della mossa si vede meglio. Una flotta di agenti ha bisogno di due cose per essere gestibile: che le sessioni si parlino, e che chi le lancia sappia su quale hardware stanno girando e con quali accessi. Finché la macchina è quella di Anthropic la seconda domanda non ha risposta locale, e per parecchie aziende è la ragione per cui l'agente resta confinato in un laptop. Sempre in questo rilascio arriva la sorgente archive per i plugin, che permette di installarli da uno zip via HTTPS senza git e senza npm, con un blocco opzionale su SHA-256: è la stessa logica applicata alla distribuzione, cioè far entrare gli agenti in ambienti dove non tutto è raggiungibile.

Cosa fare adesso, in concreto

Cinque cose, nessuna delle quali richiede più di qualche minuto.

1. Aggiornare Claude Code e verificare di essere almeno alla 2.1.224, altrimenti SendMessage cross-sessione e ListAgents semplicemente non ci sono.
2. Lanciare ListAgents in una sessione mentre un'altra è aperta, prima di costruirci sopra qualsiasi automazione. Serve a vedere con i propri occhi cosa la sessione riesce a scoprire e cosa no, visto che il supporto dichiarato è per macOS e Linux.
3. Decidere crossSessionInbound e dialogExpiry prima di far girare sessioni non presidiate, non dopo. Chi usa sessioni con i permessi bypassati sta ricevendo messaggi trattenuti in attesa di approvazione: se nessuno approva, quei messaggi restano lì.
4. Non trattare l'invio come una consegna. La 2.1.224 corregge SendMessage che dichiarava "Message sent" su scritture fallite, quindi vale la pena controllare che il proprio codice di coordinamento guardi davvero l'errore invece di dare per riuscito ogni invio.
5. Rileggere le voci di deny della sandbox scritte con la barra finale. La stessa versione corregge un caso in cui una regola come denyRead: "~/.aws/" era aggirabile in silenzio su Linux e macOS. Chi ha protetto le credenziali cloud in quel modo aveva una difesa che non c'era, e non aveva modo di accorgersene.

Su questi ultimi due punti il ragionamento è lo stesso che vale per tutto il resto dei permessi, e l'ho scritto nel pezzo sulla finestra di approvazione dei comandi corretta nella 2.1.223: un confine vale quanto la sua parte peggiore, e quasi sempre la parte peggiore è quella che nessuno guarda. Chi non ha ancora messo mano al proprio file di impostazioni trova il punto di partenza nella guida alla configurazione di Claude Code.

Una cosa in più la direi a chi si sta entusiasmando per la flotta. Far parlare fra loro più sessioni di Claude Code risolve un problema di comunicazione, non un problema di isolamento: due sessioni che si scrivono restano due sessioni che possono toccare gli stessi file, ed è il motivo per cui l'isolamento dei worktree introdotto nella 2.1.222 conta oggi più di ieri. La messaggistica rende il coordinamento possibile, non automatico. Chi non aveva un'idea chiara di chi fa cosa quando c'era un agente solo, con dieci agenti che si parlano avrà lo stesso problema, moltiplicato per dieci e più difficile da leggere.

Il fatto tecnico della giornata è che due terminali possono scriversi. La conseguenza vera è che da qui in avanti progettare come si dividono il lavoro diventa parte del lavoro, e non è una cosa che l'agente può decidere al posto di chi lo usa.