Con la versione 2.1.224, rilasciata la prima settimana di agosto 2026, Claude Code introduce la messaggistica tra sessioni: due o più istanze del CLI, avviate in terminali diversi, possono ora scambiarsi messaggi di testo senza che sia l’utente a fare da tramite copiando e incollando contesto da un terminale all’altro. È una funzionalità pensata per chi lavora abitualmente con più sessioni parallele su worktree diversi dello stesso repository, e merita attenzione anche solo per capire come configurarla in modo sicuro in un contesto aziendale.

Il problema che risolve

Chi usa Claude Code su progetti complessi finisce spesso per aprire più terminali: uno per il lavoro principale, uno per un hotfix urgente, uno per un refactoring in un worktree separato. Fino a v2.1.223 l’unico modo per far sapere a una sessione cosa stava succedendo in un’altra era manuale: copiare un riassunto, incollarlo, ripetere il contesto. La messaggistica cross-session automatizza esattamente questo passaggio.

Due strumenti nuovi: ListAgents e SendMessage

Claude Code espone due tool interni che il modello usa autonomamente, senza che l’utente li invochi direttamente:

• ListAgents individua le sessioni raggiungibili: subagent nella sessione corrente, altre sessioni locali sulla stessa macchina (incluse quelle in background) e sessioni remote se è attiva la Remote Control.
• SendMessage consegna un messaggio di testo a una sessione specifica, identificata per nome.

Il messaggio non è mai la cronologia della conversazione né un file: è un testo che una Claude scrive per un’altra Claude. Per spostare davvero un intero contesto conversazionale tra terminali resta lo strumento giusto il resume di sessione, non la messaggistica.

Per vedere quali sessioni sono raggiungibili basta lanciare, in un terminale con Claude Code attivo:

/list-agents

Il comando elenca ogni sessione con il nome a cui risponde (derivato dalla cartella di lavoro, oppure impostato con /rename o il flag --name), utile per distinguere sessioni omonime che girano in directory diverse.

Come si usa in pratica

Non si compone il messaggio a mano: si dice a Claude cosa si vuole che l’altra sessione sappia, ed è Claude a scrivere il riassunto effettivo. Due esempi di prompt tipici:

Chiedi alla sessione nell'altro terminale se la migrazione è terminata

Spiega alla sessione che lavora sulle API di pagamento cosa abbiamo appena cambiato

Nel secondo caso il contenuto esatto del messaggio varia: è Claude a decidere come riassumere il lavoro fatto. Quando il messaggio arriva, compare nella conversazione della sessione ricevente con il nome del mittente, e viene compattato in una riga Message from che si espande con Ctrl+O.

Dove viaggia il messaggio

Il percorso dipende da dove gira la sessione di destinazione:

• Stessa macchina: il messaggio passa attraverso un socket per-sessione, mai attraverso i server Anthropic. In questo caso sono possibili sia nuovi messaggi sia risposte.
• Altra macchina dell’utente: il messaggio passa dai server Anthropic e arriva tramite la connessione Remote Control di quella macchina. Da qui è possibile solo rispondere, non avviare una conversazione.
• Claude Code on the web: stesso discorso, solo risposte.

Ogni sessione si registra su disco e apre un proprio “inbox socket”: due sessioni si trovano a vicenda solo se vedono lo stesso filesystem, il che significa che una sessione dentro un container e una sull’host non possono raggiungersi, mentre due sessioni nello stesso container sì.

Controllo dei messaggi in arrivo

Per un uso in ambienti con requisiti di governance, il parametro di configurazione rilevante è crossSessionInbound, impostabile su tre valori:

{
  "crossSessionInbound": "accept"
}

• accept: ogni messaggio viene consegnato direttamente.
• hold: Claude Code mostra un avviso ma non consegna nulla, finché l’utente non approva.
• refuse: il messaggio viene scartato senza notifica al destinatario.

Quando non è impostato alcun valore, Claude Code decide messaggio per messaggio in base alla modalità di permessi delle due sessioni: se la sessione ricevente richiede conferma per i permessi, il messaggio viene consegnato; se la sessione ricevente salta le conferme (modalità bypassPermissions), il messaggio viene messo in attesa di approvazione, a meno che anche il mittente dichiari di essere in bypass.

Per richiedere sempre un’approvazione esplicita prima che un messaggio lasci la macchina locale, si può impostare:

{
  "isolatePeerMachines": true
}

Per disattivare del tutto la funzionalità a livello di organizzazione, nelle managed settings:

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

Cosa una sessione remota non può fare

Un messaggio in arrivo da un’altra sessione non equivale mai al consenso dell’utente: non può approvare un prompt di permesso in sospeso, non può modificare impostazioni di permessi o il file CLAUDE.md, ed eventuali comandi contenuti nel testo (ad esempio /compact) vengono trattati come testo normale, mai eseguiti. Se agire sul messaggio richiede un permesso che la sessione ricevente non ha, scatta comunque il prompt standard.

I limiti attuali

La limitazione più rilevante per chi lavora su Windows: la messaggistica cross-session funziona su macOS e Linux, inclusa una sessione Linux dentro WSL 2, ma non su Windows nativo. È inoltre assente su Amazon Bedrock, Claude Platform su AWS, Google Cloud Agent Platform e Microsoft Foundry. Restano infine due limiti strutturali: i messaggi sono solo testo semplice (i protocolli strutturati degli agent team restano interni al team) e i loop di messaggi vengono limitati automaticamente, con un massimo di 50 messaggi accettati in attesa di lettura per sessione.

Quando ha senso usarla

La documentazione ufficiale indica quattro casi d’uso principali: passare un finding da una sessione a un’altra dopo una scoperta rilevante, coordinare worktree paralleli sullo stesso repository, far riportare lo stato di un’operazione lunga (una migrazione, una suite di test) alla sessione che la sta monitorando, e rispondere a messaggi arrivati da sessioni su altre macchine o dal web. Per chi lavora già con più terminali aperti sullo stesso progetto, è una funzione che elimina una frizione reale, a patto di capire bene i default di crossSessionInbound prima di usarla in un ambiente con permessi sensibili.

Fonte: documentazione ufficiale Claude Code – Cross-session messaging.