Come si scambiano messaggi le sessioni di Claude Code

Cosa significa che le sessioni di Claude Code possono scambiarsi messaggi

Due sessioni di Claude Code possono scambiarsi messaggi quando vengono eseguite sulla stessa macchina e con lo stesso utente del sistema operativo. Un messaggio è un testo semplice scritto da una sessione di Claude per un'altra. Non contiene la cronologia della conversazione né file. Claude individua l'altra sessione con lo strumento ListAgents e invia il testo con SendMessage, quindi non devi chiamare manualmente nessuno dei due strumenti. Devi indicare le informazioni necessarie all'altra sessione; Claude scrive autonomamente il messaggio.

La funzionalità si chiama messaggistica tra sessioni. Ad agosto 2026 richiede Claude Code v2.1.224 o versioni successive e funziona su macOS e Linux, incluso Linux all'interno di WSL 2. Non è disponibile un supporto nativo per Windows e la funzionalità non è disponibile su Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform o Microsoft Foundry. Quando una sessione soddisfa questi requisiti, la messaggistica è già attiva e non è necessario abilitare nulla. Il comportamento descritto di seguito deriva dalla documentazione Anthropic sulla messaggistica tra sessioni.

È su un VPS che questa funzionalità è utile, perché le sessioni su un VPS rimangono attive abbastanza a lungo da poter essere indirizzate. Su un laptop chiudi il coperchio. Su un server con tmux, una sessione avviata lunedì può essere ancora in esecuzione giovedì e mantenere il contesto dello stesso repository. Quando hai due sessioni di questo tipo, il modo in cui comunicano non è più teorico. Se non hai ancora configurato questo ambiente, inizia da eseguire Claude Code su un VPS con tmux, dove è descritta la gestione delle sessioni richiesta da questa guida.

Quando vale la pena usare una seconda sessione

Parti dal costo. Ogni sessione è un'istanza separata di Claude con una propria finestra di contesto, quindi due sessioni costano circa il doppio rispetto a una sola nello stesso periodo. Un messaggio inviato da Claude viene conteggiato ai fini dell'utilizzo esattamente come un prompt digitato da te. Il coordinamento non è gratuito e, quando il lavoro consiste realmente in una sequenza di passaggi, suddividerlo tra più sessioni lo rende più lento e costoso.

I casi in cui una seconda sessione si ripaga hanno una caratteristica comune. Due attività vengono eseguite contemporaneamente senza dipendere l'una dall'altra e, durante l'esecuzione, una acquisisce un'informazione necessaria all'altra.

• Una sessione rileva una modifica incompatibile mentre l'altra sta costruendo il codice che quella modifica ha reso incompatibile. Claude riepiloga la modifica e la invia, invece di costringerti a ridigitarla nell'altro terminale.
• Due sessioni lavorano sullo stesso repository in git worktree separati e una deve sapere quali modifiche sono state integrate.
• Una migrazione o un test di lunga durata restituisce il risultato alla sessione che stai monitorando.
• Una sessione di compilazione e una sessione di revisione: il revisore legge ciò che ha prodotto la sessione di compilazione e invia i risultati della verifica.

Quando il lavoro è sequenziale o quando entrambe le sessioni modificherebbero gli stessi file, usa una sola sessione. Se vuoi un gruppo coordinato che Claude avvia e supervisiona all'interno di una singola attività, si tratta degli agent teams, una funzionalità separata e ancora sperimentale. Se vuoi soltanto la stessa conversazione in un altro terminale, riprendi invece la sessione. La messaggistica tra sessioni serve per sessioni indipendenti che avvii e gestisci direttamente.

Verificare che la funzionalità sia disponibile prima di basarci la configurazione

Prima di tutto, controllare la versione:

claude --version

Confrontare il numero con 2.1.224. Quindi, all'interno di una sessione, digitare /list-agents, che risponde anche a /peers. Il comando stampa tutti gli agenti raggiungibili da questa sessione, insieme al nome a cui ciascuno risponde. Se il comando non viene riconosciuto, questa sessione non supporta la messaggistica tra sessioni e nessun file di configurazione può abilitarla. Digitare /status e cercare una riga Peer address: contiene l'indirizzo della casella di posta di questa sessione, preceduto da uds:.

Gli utenti VPS devono prestare particolare attenzione a un problema. La messaggistica tra sessioni dipende dalla valutazione dei feature flag e diverse variabili relative alla privacy disabilitano tale valutazione, lasciando la funzionalità disattivata per impostazione predefinita. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC e DISABLE_GROWTHBOOK hanno tutte questo effetto. Per mettere in sicurezza un server appena installato, spesso si incollano queste variabili in ~/.bashrc, per poi chiedersi perché /list-agents non esista. Gli stessi valori possono essere forniti dalla mappa env in un file di configurazione oppure da impostazioni gestite; controllare quindi prima l'ambiente della shell.

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

Annullare l'impostazione della variabile che produce un output. Per DISABLE_TELEMETRY e CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, qualsiasi valore non vuoto abilita il comportamento, compresa la stringa 0; pertanto DISABLE_TELEMETRY=0 non produce l'effetto che sembra indicare. Per disabilitarlo, annullare l'impostazione della variabile oppure assegnarle una stringa vuota.

Assegna un nome alle sessioni, altrimenti Claude non può indirizzarle

Claude indirizza un messaggio a una sessione tramite il suo nome. Imposta il nome quando avvii la sessione:

claude --name builder-api

Puoi impostarlo anche con /rename all'interno di una sessione in esecuzione. Se non imposti alcun nome, Claude Code lo ricava dal nome della directory di lavoro, ad esempio myapp-3f. Questo va bene per una sola sessione, ma diventa poco chiaro quando le sessioni sono quattro; inoltre, due sessioni possono avere lo stesso nome. L'output di /list-agents mostra la directory di lavoro di ogni sessione locale, permettendo di distinguere le sessioni con lo stesso nome, mentre l'elenco generato da Claude aggiunge un identificatore breve all'indirizzo quando i nomi coincidono. Assegnare personalmente i nomi è più semplice che leggere gli identificatori.

Un layout tmux a due sessioni che puoi riprodurre

Questa configurazione prevede una sessione builder e una sessione reviewer sullo stesso repository. Il reviewer lavora in un worktree git separato, quindi le due sessioni non scrivono mai nello stesso file. git worktree add con HEAD crea un checkout scollegato, che è ciò che serve per una sessione che legge i file senza eseguire commit.

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

Ctrl+b quindi w elenca le finestre per nome, così puoi sceglierne una. Nella finestra builder, esegui /list-agents. Dovresti vedere reviewer-api con la directory di lavoro ~/src/api-review. Se non compare, la sessione reviewer non ha ancora terminato l'avvio oppure si verifica uno dei due problemi descritti nella sezione successiva. Poi passa un'attività usando un linguaggio semplice:

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude scrive il riepilogo e lo invia. Non devi scrivere il testo del messaggio e il contenuto inviato da Claude può variare. Nella finestra reviewer, il messaggio compare nella conversazione con il nome del mittente. Se la sessione è inattiva, Claude avvia subito un nuovo turno. Se sta eseguendo un turno, il messaggio resta in attesa fino al termine della chiamata allo strumento in corso, quindi un comando in esecuzione non viene mai interrotto. Dopo che Claude lo ha letto, il messaggio viene ridotto a una riga Message from che Ctrl+O espande. Le due sessioni funzionano meglio quando il builder mantiene contenute le modifiche, perché un diff limitato produce un passaggio di consegne più breve e una revisione che l'altra sessione può completare in un solo turno. È questa l'abitudine che la competenza del senior developer pigro mira a imporre.

Chi può vedere chi su un singolo VPS

La consegna sulla stessa macchina non passa mai dai server Anthropic. Ogni sessione scrive su disco i file di registrazione e apre il proprio socket inbox; Claude Code legge questi file per individuare le altre sessioni. Da questo derivano due conseguenze, entrambe rilevanti su un server.

Il socket è accessibile soltanto al proprio utente del sistema operativo. Una sessione avviata come root e una sessione avviata come deploy non possono vedersi, neppure una accanto all'altra nello stesso server tmux, perché le sessioni di un utente non possono accedere al socket di un altro utente. Eseguire entrambe le sessioni con lo stesso utente.

Un container ha il proprio filesystem. Una sessione all'interno di Docker e una sessione sull'host non possono comunicare, perché non leggono gli stessi file di registrazione. Due sessioni all'interno dello stesso container possono scambiarsi messaggi normalmente. Se si mantengono gli agenti nei container per l'isolamento, come descritto in eseguire agenti di coding in una VM temporanea, la messaggistica funzionerà all'interno del container, ma non oltre il confine del container.

Le sessioni su altre macchine e sul web compaiono nell'elenco soltanto mentre Remote Control è connesso e sono contrassegnate di conseguenza. Claude può rispondere soltanto a un messaggio ricevuto da una di queste sessioni. Non può avviare questo scambio.

Perché il messaggio non è mai arrivato

Il motivo più comune non riguarda la rete. È la sessione ricevente a decidere cosa fare del messaggio, e la decisione è stata di non consegnarlo. Ogni messaggio in arrivo termina in uno di tre stati: consegnato, trattenuto (messo da parte senza consegna finché non lo approvi) oppure rifiutato (scartato senza consegna).

Quando non si applica alcun valore crossSessionInbound, Claude Code decide per ogni messaggio confrontando le modalità di autorizzazione delle due sessioni. Raggruppa in una classe le sessioni che ignorano le richieste di autorizzazione e in un'altra tutte le altre sessioni. auto, acceptEdits e dontAsk contano come richieste di autorizzazione. La modalità Plan conta come bypass delle richieste in una sessione che dispone delle autorizzazioni per ignorarle. La regola è quindi simmetrica:

• Una sessione ricevente che richiede autorizzazioni riceve ogni messaggio. Ne trattiene uno solo quando la sessione mittente si identifica come sessione che ignora le richieste.
• Una sessione ricevente che ignora le richieste trattiene ogni messaggio in attesa della tua approvazione. Ne consegna uno solo quando anche il mittente ignora le richieste.

Per questo il primo flusso di lavoro che molti configurano è esattamente quello che non funziona. Avvii un builder con --permission-mode bypassPermissions perché vuoi che venga eseguito senza supervisione, lasci il reviewer con le impostazioni predefinite e ogni messaggio inviato dal builder resta in attesa in una finestra di approvazione che nessuno sta controllando. La finestra si chiude dopo la scadenza dialogExpiry, che per impostazione predefinita è 5m, e il messaggio viene scartato. Sulla stessa macchina, la sessione mittente riceve una notifica quando il messaggio viene trattenuto e un'altra quando il ricevente lo consegna, lo rifiuta o lo lascia scadere. Controlla quindi la schermata del mittente prima di attribuire il problema al socket.

Per fare in modo che una sessione riceva i messaggi senza supervisione, imposta crossSessionInbound su accept. Il punto in cui imposti il valore determina l'ambito di applicazione. Claude Code legge prima le impostazioni gestite, poi il flag --settings e infine le impostazioni utente, applicando il primo valore trovato. Un valore nelle impostazioni del progetto o locali si applica solo quando è più restrittivo, secondo la scala accept < hold < refuse. Un accept in .claude/settings.json è meno restrittivo di qualsiasi altro valore, quindi viene ignorato quando una fonte attendibile ha impostato un valore. Inseriscilo in ~/.claude/settings.json oppure passalo per una singola sessione:

claude --name runner --settings '{"crossSessionInbound":"accept"}'

Un worker headless claude -p associa un socket inbox come una sessione interattiva e compare nell'elenco, ma non può mostrare una finestra di approvazione. Un messaggio trattenuto in questa sessione resta in attesa finché una modifica successiva della modalità o delle impostazioni non ne consente la ricezione. La riga --settings precedente consente a questo worker di ricevere i messaggi. Una sessione avviata in modalità bare non associa alcun socket, quindi non può ricevere messaggi né comparire nell'elenco.

Quando i passaggi di consegne si bloccano

I cicli di messaggi vengono gestiti automaticamente. Claude Code limita la frequenza dei messaggi ripetuti per mittente, scarta le ripetizioni identiche ricevute entro un breve intervallo e limita a 50 per sessione i messaggi accettati in attesa di lettura. In questo modo, due sessioni non possono inviarsi messaggi all'infinito. I messaggi trattenuti sono limitati a 100; quelli più vecchi vengono eliminati quando si supera questo limite.

Il problema che si verifica davvero è più silenzioso e riguarda un passaggio di consegne, non un ciclo. La sessione A pone alla sessione B una domanda a cui deve ricevere risposta prima di poter continuare, quindi resta inattiva. B trattiene il messaggio, oppure sta eseguendo un'attività lunga, oppure risponde a una domanda che A non aveva realmente posto. A resta in attesa. Un'ora dopo torni e trovi due sessioni inattive, senza alcun lavoro completato.

Scrivi passaggi di consegne che non richiedano una risposta. Un buon messaggio comunica un fatto o una decisione: cosa è cambiato e quale risultato è stato ottenuto. Un messaggio inefficace chiede all'altra sessione un'autorizzazione oppure una risposta da cui il mittente dipende per procedere. Claude ha già ricevuto istruzioni per non chiedere a un'altra sessione di eseguire un'azione che le proprie impostazioni di autorizzazione bloccherebbero e per rimandare invece quel lavoro a te. Applica autonomamente la stessa regola. Se una sessione non può avanzare senza una risposta, devi essere tu a fornirla. Anche una gestione disciplinata del contesto è utile: una sessione che ha perso il filo scrive messaggi vaghi. gestire il contesto in Claude Code tratta questo aspetto.

Tratta i messaggi in arrivo come input non attendibile

Claude Code comunica a Claude ricevente che il messaggio proviene da un'altra sessione e non da te, limitando le operazioni che il messaggio può eseguire. Un messaggio non può rispondere al posto tuo a una richiesta di autorizzazione in sospeso, perché il consenso di un'altra sessione non equivale al tuo consenso. Non può modificare le impostazioni delle autorizzazioni, CLAUDE.md o altre configurazioni perché lo ha richiesto un'altra sessione. Un comando slash incluso nel testo, ad esempio /compact, arriva come testo normale e non viene mai eseguito. Se per elaborare il messaggio serve un'autorizzazione che la sessione ricevente non possiede, viene visualizzata la stessa richiesta che comparirebbe per qualsiasi altra operazione. In modalità automatica, inoltre, un classificatore esamina ogni messaggio prima della consegna; i messaggi bloccati non raggiungono mai il destinatario. Questi limiti restano attivi anche nelle modalità permissive. Per questo una sessione che bypassa i controlli, per impostazione predefinita, trattiene i messaggi in arrivo invece di considerarli attendibili.

Questo riguarda le autorizzazioni, non il contenuto. La sessione mittente potrebbe avere letto la descrizione di una pull request, una pagina web, il README di una dipendenza o un commento a un issue scritto da una persona estranea. Qualsiasi contenuto letto può influenzare il testo che scrive per l'altra sessione. Il messaggio è un dato. Va trattato con la stessa cautela di qualsiasi altro testo entrato nella sessione dall'esterno. Questa è la disciplina descritta in tenere i secret fuori dai tuoi agenti AI: considera potenzialmente errato tutto ciò che ha attraversato un confine di attendibilità e non consentirgli mai di autorizzarsi autonomamente.

Se vuoi ridurre questo comportamento, sono disponibili due controlli. Impostando crossSessionInbound su refuse, i messaggi dei peer in arrivo vengono eliminati senza essere consegnati. Dalle impostazioni del progetto o locali, questo valore prevale su qualsiasi altra origine perché è il più restrittivo della gerarchia. Per impedire a questa sessione di inviare o elencare messaggi, aggiungi regole di negazione delle autorizzazioni che specifichino SendMessage e ListAgents, entrambi scritti come nomi di tool senza specifier. Impostando isolatePeerMachines su true, è richiesta la tua approvazione esplicita prima che un messaggio raggiunga una sessione oltre questa macchina. L'approvazione è richiesta anche in modalità bypassPermissions.

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

Negare SendMessage disabilita anche la messaggistica verso i subagent, perché entrambe le funzioni usano lo stesso tool. Una sessione che rifiuta i messaggi non mostra cambiamenti visibili nel proprio /status né negli elenchi delle altre sessioni. Verifica quindi l'impostazione nella configurazione della sessione, non dall'interfaccia.

Bridge e server MCP con memoria condivisa

Nello stesso periodo sono arrivati diversi progetti di terze parti con una funzione adiacente: bridge locali tra agenti che inoltrano testo tra agenti in esecuzione e server MCP (model context protocol) che forniscono a più agenti un archivio condiviso in cui leggere e scrivere. Valutateli come una soluzione di tipo diverso, non come concorrenti, e verificate ogni comando di installazione nel README del progetto prima di eseguirlo. La messaggistica usa un modello push, perché il mittente inserisce il testo nel turno del destinatario. Un archivio condiviso usa un modello pull, perché nessuna sessione viene interrotta e una sessione vede la nota quando la consulta. Il modello pull è più adatto allo stato che cambia lentamente e funziona solo quando una sessione effettua effettivamente la consultazione.

Se scegliete questa soluzione, le domande importanti riguardano il processo, non l'elenco delle funzionalità. Con quale utente viene eseguito il server e quali dati può leggere sul sistema. Eseguire server MCP su un VPS descrive questa configurazione. Condividere le competenze degli agenti tra repository descrive il caso più semplice, in cui ciò che volete condividere tra sessioni sono istruzioni anziché lo stato corrente, riducendo molti dei messaggi che altrimenti dovreste inviare. Per una panoramica più ampia, il punto di partenza è eseguire un agente di programmazione su un VPS.

FAQ

Perché /list-agents non viene riconosciuto nella mia sessione?

La sessione non dispone della messaggistica tra sessioni. Controlla prima claude --version rispetto a 2.1.224, perché questa funzionalità richiede quella versione o una successiva. Controlla poi la piattaforma: la funzionalità è disponibile su macOS e Linux, ma non su Windows nativo, Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform e Microsoft Foundry. Se entrambi i controlli hanno esito positivo, verifica nella shell la presenza di DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC o DISABLE_GROWTHBOOK. Ognuno di questi elementi blocca la valutazione del feature flag da cui dipende la funzionalità e la lascia disattivata.

Perché il mio messaggio all'altra sessione non è mai arrivato?

Se /list-agents funziona, la messaggistica è attiva e un problema più specifico ha impedito la consegna del messaggio. La causa più comune riguarda le modalità delle autorizzazioni. Una sessione che ignora le richieste di autorizzazione mette in attesa ogni messaggio in ingresso finché non lo approvi, a meno che anche il mittente non ignori tali richieste. La finestra di approvazione viene eliminata allo scadere del termine dialogExpiry, che per impostazione predefinita è di cinque minuti. Controlla nella sessione mittente la notifica del messaggio in attesa. Per risolvere il problema, imposta crossSessionInbound su accept in ~/.claude/settings.json oppure passalo con --settings, perché un accept nelle impostazioni del progetto o locali viene ignorato in quanto valore meno restrittivo.

Una sessione di Claude Code in Docker può inviare messaggi a una sessione sull'host?

No. Le sessioni si individuano tramite file di registrazione su disco e un socket inbox specifico per ogni sessione. Un container ha un filesystem proprio, quindi le due sessioni non possono accedere agli stessi file. Due sessioni all'interno dello stesso container possono invece scambiarsi messaggi normalmente. La stessa regola spiega perché una sessione eseguita come root e una sessione eseguita come utente normale non possano comunicare: il socket è accessibile soltanto all'utente del sistema operativo che ne è proprietario.

È sicuro agire in base a un messaggio proveniente da un'altra sessione di Claude Code?

Considera il testo come input non attendibile, perché la sessione mittente potrebbe aver letto una pagina web, un README o un commento a un issue scritto da un'altra persona. Claude Code impedisce già al messaggio di agire autonomamente: non può approvare una richiesta di autorizzazione in attesa, non può modificare le impostazioni delle autorizzazioni o CLAUDE.md su richiesta e uno slash command contenuto nel testo arriva come testo normale e non viene mai eseguito. Queste protezioni riguardano le autorizzazioni, non la valutazione del contenuto. Leggi quindi ciò che è arrivato prima di chiedere alla sessione ricevente di agire.

La messaggistica tra sessioni invia il mio codice ad Anthropic?

Tra due sessioni sulla stessa macchina, no. Il messaggio viaggia tramite un socket specifico per sessione su quella macchina e non passa mai dai server Anthropic. Viene inviato soltanto il testo scritto da Claude, non la cronologia della conversazione né i file. I messaggi inviati a una sessione su un'altra macchina oppure a una sessione sul web passano invece dai server Anthropic tramite la connessione Remote Control. In questa direzione Claude può soltanto rispondere a un messaggio ricevuto e non può avviarne uno. Imposta isolatePeerMachines su true per richiedere la tua approvazione prima che qualsiasi contenuto lasci la macchina.