Come scambiare messaggi tra 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 Claude per l'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 ciò che l'altra sessione deve sapere e Claude scrive 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 eseguito 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.

Un VPS è l'ambiente in cui questa funzionalità è utile, perché le sessioni vi rimangono attive abbastanza a lungo da poter essere contattate. Su un laptop chiudi il coperchio. Su un server con tmux, una sessione avviata lunedì può essere ancora in esecuzione giovedì e conservare il contesto di un repository. Quando ne hai due, il modo in cui comunicano non è più un aspetto teorico. Se non hai ancora configurato questo ambiente, inizia da eseguire Claude Code su un VPS con tmux, che descrive la gestione delle sessioni presupposta da questa guida.

Quando conviene usare una seconda sessione

Parti dal costo. Ogni sessione è un'istanza Claude separata, con una propria finestra di contesto. Di conseguenza, nello stesso intervallo, due sessioni costano all'incirca il doppio di una sola sessione. Un messaggio generato viene conteggiato nell'utilizzo esattamente come un prompt digitato da te. Il coordinamento non è gratuito e, quando il lavoro consiste realmente in un'unica sequenza di passaggi, dividerlo tra più sessioni lo rende più lento e costoso.

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

• Una sessione individua una modifica incompatibile mentre l'altra sta lavorando sul codice interessato. Claude riepiloga la modifica e la invia, invece di costringerti a riscriverla nell'altro terminale.
• Due sessioni lavorano sullo stesso repository in git worktree separati e una deve sapere quali modifiche sono state integrate.
• Una migrazione lunga o un test comunica il risultato alla sessione che stai monitorando.
• Una sessione esegue la compilazione e un'altra la revisione: il reviewer legge il risultato prodotto dal builder e invia ciò che ha rilevato.

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

Verificare la disponibilità della funzionalità prima di basarvi la configurazione

Prima controllate la versione:

claude --version

Confrontate il numero con 2.1.224. Quindi, all'interno di una sessione, digitate /list-agents, che risponde anche a /peers. Il comando stampa tutti gli agenti raggiungibili da questa sessione, indicando il 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. Digitate /status e cercate una riga Peer address: contiene l'indirizzo della casella di posta di questa sessione, preceduto da uds:.

Gli utenti VPS devono prestare attenzione a un caso specifico. La messaggistica tra sessioni dipende dalla valutazione dei feature flag e diverse variabili relative alla privacy disabilitano tale valutazione, lasciando la funzionalità disabilitata per impostazione predefinita. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC e DISABLE_GROWTHBOOK producono tutti questo effetto. Per applicare un livello di sicurezza iniziale a un nuovo server, spesso si incollano queste variabili in ~/.bashrc, per poi chiedersi perché /list-agents non esista. Gli stessi valori possono provenire dalla mappa env in un file di configurazione o da impostazioni gestite; controllate quindi prima l'ambiente della shell.

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

Annullate l'impostazione della variabile che restituisce un valore. Per DISABLE_TELEMETRY e CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, qualsiasi valore non vuoto abilita il comportamento, inclusa la stringa 0; di conseguenza DISABLE_TELEMETRY=0 non produce l'effetto apparente. Per disabilitarlo, annullate l'impostazione della variabile oppure assegnatele una stringa vuota.

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

Imposta il nome quando avvii la sessione:

claude --name builder-api

Puoi anche impostarlo con /rename all'interno di una sessione già attiva. Se non imposti alcun nome, Claude Code lo ricava dal nome della directory di lavoro, ad esempio myapp-3f. Questo può funzionare per una sessione, ma crea confusione 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 quelle con lo stesso nome; l'elenco generato da Claude aggiunge anche 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 riproducibile

Questa è una sessione builder e una sessione reviewer sullo stesso repository. Il reviewer lavora in un git worktree separato, quindi le due sessioni non scrivono mai nello stesso file. git worktree add con HEAD crea un checkout detached, adatto a una sessione che legge invece di eseguire commit. Poiché le due sessioni svolgono attività diverse, conviene assegnare al reviewer uno stile di output dedicato. Questo modifica il prompt di sistema della sessione e rimane valido per ogni turno, invece di esaurirsi come un'istruzione digitata una sola volta.

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 seguito da 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 completato l'avvio oppure si verifica uno dei due problemi descritti nella sezione successiva. Poi passa qualcosa all'altra sessione in linguaggio naturale:

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; 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 il turno è in corso, il messaggio resta in attesa fino al termine di una chiamata a uno strumento, quindi un comando in esecuzione non viene mai interrotto. Dopo che Claude lo ha letto, il messaggio viene compresso in una riga Message from che Ctrl+O espande. La coppia funziona meglio quando il builder mantiene ridotte le modifiche, perché un diff circoscritto 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 dev 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 propri file di registrazione e associa il proprio socket inbox; Claude Code legge questi file per trovare le altre sessioni. Su un server questo comporta due conseguenze, entrambe rilevanti.

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 raggiungere il 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 raggiungersi, 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 esecuzione di agenti di coding in una VM temporanea, i messaggi funzionano 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 qui può rispondere soltanto a un messaggio ricevuto da una di queste sessioni. Non può avviare lo 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 in questo caso decide di non consegnarlo. Ogni messaggio ricevuto termina con uno di tre esiti: consegnato, trattenuto (messo da parte senza consegna finché non lo approvi) oppure rifiutato (eliminato 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 nell'altra tutte le restanti sessioni. auto, acceptEdits e dontAsk vengono considerate modalità con richieste di autorizzazione. La modalità Plan viene considerata una modalità che ignora le richieste in una sessione che dispone di autorizzazioni per ignorarle. Se non sai a quale classe appartenga una sessione, conviene leggere prima cosa fa effettivamente ogni modalità di autorizzazione, perché auto è la modalità iniziale della maggior parte delle sessioni e appartiene al lato delle modalità con richieste di autorizzazione di questa suddivisione. La regola è quindi simmetrica:

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

Il primo flusso di lavoro che molti configurano è quindi proprio quello che non funziona. Avvii un builder con --permission-mode bypassPermissions perché vuoi che operi 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 di dialogExpiry, che per impostazione predefinita è 5m, e il messaggio viene eliminato. Sulla stessa macchina, la sessione mittente riceve una notifica quando il suo messaggio viene trattenuto e un aggiornamento quando il destinatario lo consegna, lo rifiuta o lo lascia scadere. Controlla quindi lo schermo 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 questo valore determina dove si applica. 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 di progetto o locali si applica soltanto quando è più restrittivo, secondo la scala accept < hold < refuse. Un valore 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 sola sessione:

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

Un worker claude -p senza interfaccia associa un socket inbox come una sessione interattiva e compare nell'elenco, ma non può visualizzare 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 gli hand-off si bloccano

I loop di messaggi vengono gestiti automaticamente. Claude Code limita la frequenza dei messaggi ripetuti per mittente, scarta le ripetizioni identiche ricevute in una finestra temporale breve e limita a 50 per sessione i messaggi accettati in attesa di lettura, quindi due sessioni non possono scambiarsi messaggi all’infinito. I messaggi in attesa sono limitati a 100; oltre questo limite vengono eliminati prima quelli più vecchi.

Il problema che si verifica realmente è più silenzioso e riguarda un hand-off, non un loop. La sessione A pone alla sessione B una domanda a cui deve ricevere risposta prima di poter continuare, quindi resta inattiva. B conserva 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 hand-off che non richiedano una risposta. Un buon messaggio comunica un fatto o una decisione: che cosa è cambiato e quale risultato è stato ottenuto. Un messaggio problematico chiede all’altra sessione un’autorizzazione oppure una risposta da cui il mittente dipende per poter continuare. Claude ha già ricevuto istruzioni di non chiedere a un’altra sessione un’azione che le proprie impostazioni delle autorizzazioni impedirebbero, e di riportare invece il lavoro a te. Estendi autonomamente questa regola. Se una sessione non può avanzare senza una risposta, sei tu a doverle rispondere. Anche una gestione disciplinata del contesto è utile, perché una sessione che ha perso il filo scrive messaggi vaghi; la gestione del contesto in Claude Code tratta questo aspetto.

Tratta i messaggi in ingresso come input non attendibile

Claude Code comunica alla sessione Claude ricevente che il messaggio proviene da un'altra sessione e non da te, e limita le operazioni che il messaggio può eseguire. Questo controllo viene applicato dal programma che avvolge il modello, non dalla disponibilità del modello a obbedire. Questa è la differenza pratica introdotta da un harness per agenti. 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 solo perché lo ha richiesto un'altra sessione. Un comando slash contenuto nel testo, come /compact, arriva come testo normale e non viene mai eseguito. Se per eseguire un'azione sul messaggio serve un'autorizzazione che la sessione ricevente non possiede, viene visualizzata la stessa richiesta che vedresti per qualsiasi altra operazione. In modalità automatica, inoltre, un classificatore esamina ogni messaggio prima della consegna; se lo blocca, il messaggio non raggiunge mai il destinatario. Questi limiti restano attivi anche nelle modalità permissive. Per questo una sessione che elude i controlli trattiene per impostazione predefinita i messaggi in ingresso invece di considerarli attendibili.

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

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

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

Il diniego di SendMessage impedisce anche l'invio di messaggi ai subagent, perché entrambe le funzioni usano lo stesso tool. Una sessione che rifiuta i messaggi non mostra alcuna modifica visibile nel proprio /status né negli elenchi delle altre sessioni. Verifica quindi l'impostazione nella configurazione della sessione e non sullo schermo.

Bridge e server MCP con memoria condivisa

Nello stesso periodo sono comparsi 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 da cui leggere e in cui 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 la volta successiva in cui la consulta. Il modello pull è più adatto agli stati che cambiano lentamente e funziona solo quando una sessione esegue 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 tratta il caso più semplice in cui ciò che volete condividere tra sessioni sono istruzioni anziché stato in tempo reale; in questo modo eliminate molti dei messaggi che altrimenti dovreste inviare. Per una visione più ampia, il punto di partenza è eseguire un agente di coding 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 funzione richiede quella versione o una successiva. Controlla poi la piattaforma: la funzione è 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, perché ciascuno di questi elementi blocca la valutazione del feature flag da cui dipende la funzione e la lascia disattivata.

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

Se /list-agents funziona, la messaggistica è attiva e qualcosa di 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 trattiene ogni messaggio in ingresso in attesa della tua approvazione, a meno che anche il mittente non ignori tali richieste. La finestra di approvazione viene eliminata dopo la scadenza dialogExpiry, impostata su cinque minuti per impostazione predefinita. Controlla nella sessione mittente la notifica del messaggio trattenuto. 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 sul disco e un socket di inbox specifico per sessione. Un container ha il proprio filesystem, quindi le due sessioni non possono accedere agli stessi file. Due sessioni all'interno dello stesso container possono scambiarsi messaggi normalmente. La stessa regola spiega perché una sessione eseguita come root e una sessione eseguita come utente normale non possano raggiungersi: il socket è limitato all'utente del sistema operativo che lo possiede.

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

Tratta 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 qualcun altro. 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 incluso nel testo arriva come testo normale e non viene mai eseguito. Queste protezioni riguardano le autorizzazioni, non il giudizio. Leggi quindi ciò che è arrivato prima di indicare 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 attraverso un socket specifico per sessione su quella macchina e non passa mai dai server Anthropic. Viene inviato soltanto il testo scritto da Claude, mai la cronologia della conversazione o i file. I messaggi verso una sessione su un'altra macchina di tua proprietà o verso 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, non inviarne uno autonomamente. Imposta isolatePeerMachines su true per richiedere la tua approvazione prima che qualsiasi contenuto lasci la macchina.