Spcnet.it

2026-08-11 11:48:02

Attacchi CSS contro le webmail: come Outlook, Gmail e Yahoo possono essere aggirati per rubare password e token

A Black Hat USA 2026 il ricercatore di PortSwigger Gareth Heyes ha presentato una raccolta di tecniche che sfruttano il CSS per rompere il confine di sicurezza tra il contenuto di un’email e l’interfaccia della webmail che lo visualizza. Il lavoro, intitolato “CSS: the bomb inside your inbox”, dimostra catene di attacco funzionanti contro Outlook, Gmail, Yahoo Mail, AOL Mail, Fastmail e Proton Mail, capaci di catturare password, rubare token di sessione, dirottare azioni dell’interfaccia e persino manipolare gli assistenti AI collegati alla casella di posta.

Per chi amministra sistemi di posta aziendali, gestisce client webmail personalizzati o integra connettori email in strumenti AI, si tratta di una ricerca da conoscere: non è un singolo bug da patchare, ma una classe di vulnerabilità che nasce da un problema architetturale ricorrente.

Il problema di fondo: un confine che il browser non conosce

Le webmail moderne sanificano l’HTML delle email in arrivo per impedire l’esecuzione di script, ma devono comunque permettere una quantità significativa di CSS per preservare la formattazione (colori, layout, media query per la resa su mobile). Il CSS, però, non è “innocuo” quanto sembra: può leggere lo stato del DOM, condizionare la visibilità di elementi in base a selettori d’attributo, generare richieste di rete (per immagini e font) e persino inferire il contenuto testuale di un elemento carattere per carattere.

Heyes distingue due strategie generali:

• Abuso diretto di HTML e CSS che la webmail permette esplicitamente (selettori, media query, image-set(), elementi <label>).
• Discrepanza tra sanitizer e browser: il sanificatore approva un markup ritenendolo sicuro, ma il motore di rendering o il JavaScript dell’applicazione lo trasforma in qualcosa di diverso da quanto previsto.

Entrambe le strade permettono al contenuto di un messaggio non fidato di “uscire” dal proprio confine e interferire con l’interfaccia fidata che lo circonda.

Le catene di attacco dimostrate

Outlook: un menu a tendina travestito da campo password

Nella catena più sofisticata, elementi <label> consentiti dal sanitizer vengono usati per attivare controlli esterni al messaggio. Il JavaScript applicativo di Outlook trasforma poi attributi personalizzati “sanificati” in nuovi nodi del DOM che portano con sé CSS fuori dalla lista consentita dal sanitizer, e un trucco nel parsing delle media query fornisce infine CSS arbitrario. Il risultato è un <select> mascherato visivamente da campo password: poiché Firefox azzera il timer di selezione delle opzioni (circa un secondo) quando il menu esce dallo schermo, l’attacco riesce a catturare quasi in tempo reale ciò che la vittima digita, ricostruendo una schermata di login Microsoft credibile.

Yahoo e AOL: furto di token via race condition sul copia-incolla

Su Firefox, l’HTML incollato negli appunti può mantenere per un breve istante il CSS attivo prima che il sanificatore intervenga. Nella dimostrazione, l’attaccante avvia un flusso di login via email su Medium, la vittima copia del CSS fornito dall’attaccante e lo incolla in una bozza Yahoo o AOL: le richieste generate rivelano abbastanza cifre del token di login a 12 caratteri da permettere all’attaccante di ricostruirlo e autenticarsi come la vittima.

Exfiltration via click quando CSP blocca le risorse esterne

Quando la Content Security Policy impedisce richieste verso domini esterni, il paper introduce una tecnica alternativa basata sul click: dato un token numerico visualizzato come testo nell’email, il CSS iniettato può determinare quali cifre compaiono e con quale frequenza, nascondere i link che non corrispondono e lasciare visibile solo quello corretto. Un singolo click della vittima invia cifre e frequenza al server dell’attaccante.

Quando il bersaglio è l’AI, non l’utente

La parte più rilevante per chi lavora con assistenti AI collegati alla posta è la catena su Gmail: il fallback di image-set() genera una richiesta esterna nonostante la sanificazione. Heyes e il collega Pete Hendy l’hanno incatenata a una prompt injection indiretta processata da un assistente AI collegato via connettore Gmail: dopo che l’attaccante ha innescato un’email di conferma token Slack e la vittima ha chiesto all’assistente di processare la posta, le istruzioni iniettate hanno fatto recuperare il token e inserirlo in una bozza HTML, che lo ha esposto alla semplice visualizzazione.

Una dimostrazione su Fastmail ha colpito un browser AI: pseudo-elementi CSS e opacità rendevano visibile all’utente solo testo innocuo, mentre il modello leggeva istruzioni nascoste. Quando l’utente chiedeva di tradurre il testo visibile, il prompt nascosto faceva aprire tab e codificare dati nei frammenti URL.

Cosa è stato corretto (e cosa no)

Alla data della pubblicazione della ricerca (6 agosto 2026), Fastmail aveva corretto due bug di mutazione CSS e il bypass del proxy di Proton Mail non funzionava più al retest. Il label-jacking su Outlook e il bypass image-set() su Gmail risultavano invece ancora funzionanti, e il paper non specifica se l’intera catena di cattura password su Outlook sia stata risolta. I proof-of-concept sono pubblici su repository GitHub del team PortSwigger.

Le contromisure per chi gestisce infrastrutture di posta

Le raccomandazioni della ricerca, applicabili sia a chi sviluppa client webmail sia a chi ne valuta la postura di sicurezza, si riassumono in cinque punti:

• Isolamento rigoroso: rendere l’HTML delle email in un iframe sandboxed, separato dal contesto dell’applicazione principale.
• Allowlist di caratteri per la validazione CSS, non semplici blocklist di proprietà pericolose.
• Verifica dei “CSS gadget” prima di permettere attributi personalizzati che il JavaScript applicativo potrebbe trasformare in markup non sanificato.
• Blocco di elementi <select> e selettori pericolosi (attributo, sibling, media query complesse) nel contenuto delle email.
• Prevenzione delle richieste immagine controllate dall’attaccante, con proxy per le immagini remote e allowlist di domini stretta.

Per chi integra assistenti AI con connettori email (Gmail, Outlook, Slack), vale inoltre la pena trattare ogni contenuto proveniente dalla posta come potenzialmente ostile nei confronti del modello, non solo dell’utente umano: la prompt injection indiretta via CSS dimostra che la superficie di attacco si è spostata anche sull’agente stesso.

Conclusione

Questa ricerca conferma un pattern che si ripete da anni nella sicurezza web: qualsiasi linguaggio dichiarativo abbastanza espressivo da controllare visibilità, layout e generazione di richieste di rete può essere usato per exfiltrare dati, anche senza esecuzione di JavaScript. Con l’aggiunta di assistenti AI che leggono e agiscono sulla posta, il perimetro da difendere si allarga: non basta più proteggere l’utente dalla pagina, bisogna proteggere anche il modello dal contenuto che gli viene dato in pasto.

Fonte: The Hacker News – “New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens”, ricerca originale di Gareth Heyes su PortSwigger Research.

New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens

Outlook CSS techniques can spoof Microsoft sign-in and capture passwords, while Gmail image-set() can trigger external requests from malicious email c

^{The Hacker News}

Spcnet.it

2026-08-11 11:47:40

CVE-2026-9198: Langflow sotto attacco attivo, ecco perché aggiornare subito

Langflow sotto attacco attivo: cosa sta succedendo

Il 4 agosto 2026 la CISA (Cybersecurity and Infrastructure Security Agency statunitense) ha aggiunto CVE-2026-9198 al proprio Known Exploited Vulnerabilities Catalog, la lista delle vulnerabilità sfruttate attivamente in the wild. Il bersaglio è Langflow, il framework open source low-code per costruire applicazioni AI, agenti e pipeline RAG (Retrieval-Augmented Generation), oggi sviluppato e supportato da IBM dopo l’acquisizione di DataStax nel 2025.

Per chi gestisce infrastrutture IT, anche solo per supportare i team che sperimentano con l’AI generativa, questa non è una notizia da ignorare: si tratta di una remote code execution non autenticata, con CVSS 9.8, su un prodotto che viene spesso esposto in rete per comodità di accesso ai team di sviluppo.

Il dettaglio tecnico della vulnerabilità

CVE-2026-9198 nasce dalla combinazione di due endpoint API di Langflow che, singolarmente, sarebbero problemi di severità minore ma che, incatenati, diventano un disastro:

• /api/v1/auto_login — su un’installazione con la configurazione di default, questo endpoint rilascia un bearer token con privilegi SUPERUSER a qualsiasi chiamante di rete, senza richiedere credenziali.
• /api/v1/validate/code — accetta codice Python fornito dal chiamante e lo esegue tramite la funzione exec(), pensata per validare gli snippet usati nei flow visuali.

Un attaccante non autenticato può quindi ottenere il token dal primo endpoint e usarlo immediatamente per eseguire codice Python arbitrario sul secondo, ottenendo di fatto l’esecuzione di comandi con i privilegi del processo Langflow. Non serve alcuna interazione dell’utente, alcun account preesistente, né credenziali valide: è sufficiente che l’istanza sia raggiungibile in rete.

Perché la finestra di rischio è così stretta

A fine luglio 2026 sono comparsi online exploit proof-of-concept pienamente funzionanti, con istruzioni dettagliate per la weaponizzazione. Non è la prima volta che Langflow finisce sotto i riflettori: nei mesi precedenti altre vulnerabilità della piattaforma sono state sfruttate per distribuire miner di Monero e, più recentemente, in campagne di post-exploitation orchestrate da agenti AI autonomi. Uno di questi casi, documentato da Palo Alto Networks Unit 42, descrive un attore cinese che ha usato un agente basato su DeepSeek (framework Hermes) per condurre ricognizione e sfruttamento automatizzato contro oltre 460 target esposti su Internet, includendo proprio falle Langflow tra i vettori iniziali.

Le agenzie federali civili USA (FCEB) hanno una scadenza fissata al 7 agosto 2026 per applicare la correzione: un termine estremamente ravvicinato che segnala quanto la CISA consideri urgente questo caso.

Sei esposto? Come verificarlo

Se gestisci o hai installato Langflow, anche solo per test interni, verifica prima di tutto la versione in uso:

pip show langflow | grep Version
# oppure, se installato via Docker
docker exec <container> python -c "import langflow; print(langflow.__version__)"

Le versioni vulnerabili vanno dalla 1.0.0 alla 1.10.0. Se la tua istanza è raggiungibile da reti non fidate (Internet pubblico, VLAN non segmentate, VPN aziendale ad ampio accesso), il rischio è massimo. Puoi anche verificare rapidamente se l’endpoint di auto-login risponde senza autenticazione:

curl -i https://tuo-host-langflow/api/v1/auto_login

Una risposta 200 con un token JWT nel body, su un’istanza che non dovrebbe permetterlo, è un segnale da prendere sul serio.

Come mitigare e correggere

La correzione ufficiale è disponibile dal luglio 2026:

• Aggiorna a Langflow OSS 1.10.1 o superiore (al momento la release più recente è la 1.11.2). Con pip: pip install --upgrade langflow; con Docker, aggiorna il tag dell’immagine e ricrea il container.
• Non esporre Langflow direttamente su Internet. Se serve accesso remoto, mettilo dietro una VPN o un reverse proxy con autenticazione a livello di rete (es. Basic Auth via Nginx, oppure un identity-aware proxy come Cloudflare Access o OAuth2 Proxy).
• Segmenta la rete: le istanze usate per sviluppo/test AI dovrebbero stare in una VLAN dedicata, non nella stessa rete di produzione critica.
• Monitora i log applicativi per chiamate anomale a /api/v1/auto_login seguite da richieste a /api/v1/validate/code, che rappresentano l’impronta tipica di questo exploit chain.
• Se non puoi aggiornare subito, valuta di disabilitare temporaneamente l’endpoint di validazione codice a livello di reverse proxy, bloccando le richieste verso /api/v1/validate/code dall’esterno.

Il quadro più ampio: sicurezza delle piattaforme AI low-code

Questo episodio è un promemoria utile per chi valuta l’adozione di strumenti come Langflow, n8n, Flowise o piattaforme simili in ambito enterprise: sono prodotti giovani, in rapida evoluzione, spesso pensati per la produttività degli sviluppatori più che per un modello di sicurezza hardened by default. La combinazione di autenticazione permissiva e capacità di esecuzione codice arbitrario è un pattern che si ripete in questa categoria di software, ed è probabile che vedremo altre vulnerabilità simili nei prossimi mesi.

Per i sistemisti, la lezione operativa è duplice: trattare ogni piattaforma di orchestrazione AI come una superficie di attacco a tutti gli effetti (patch management, segmentazione, monitoring) e mantenere un inventario aggiornato di dove questi strumenti sono stati distribuiti, spesso al di fuori dei processi IT ufficiali grazie a shadow IT dei team di data science.

Conclusione

CVE-2026-9198 è un caso da manuale: due endpoint singolarmente poco pericolosi che, incatenati, portano a remote code execution non autenticata su un prodotto sempre più diffuso nei reparti che sperimentano con l’AI. Se hai Langflow in produzione o anche solo in un ambiente di test raggiungibile dalla rete aziendale, l’aggiornamento a 1.10.1+ va considerato prioritario, non rimandabile alla prossima finestra di manutenzione.

Fonte: The Hacker News e 4sysops.

Patch IBM Langflow now: CISA flags actively exploited CVE-2026-9198 – 4sysops

Langflow is an open-source, visual low-code framework for building AI applications, agents, and retrieval-augmented-generation workflows. IBM owns and supports

^{IT News (4sysops)}

Spcnet.it

2026-08-11 11:44:38

Windows Server 2016: gli Extended Security Updates via Azure Arc sono ora GA

Il 12 gennaio 2027 Windows Server 2016 uscirà dal supporto esteso: niente più aggiornamenti di sicurezza “gratuiti” tramite Windows Update o WSUS. Per molte aziende italiane che ancora gestiscono infrastrutture on-premises con carichi legacy su questa versione, non è una scadenza lontana da ignorare. Microsoft ha appena reso generally available una via per guadagnare tempo senza dover migrare tutto su macchine virtuali Azure: gli Extended Security Updates (ESU) abilitati da Azure Arc, con un modello pay-as-you-go. Vediamo cosa cambia concretamente e come prepararsi.

Cosa sono gli ESU e perché contano

Gli Extended Security Updates sono patch che coprono esclusivamente vulnerabilità classificate come Critical e Important: niente nuove funzionalità, niente fix non di sicurezza. Per Windows Server 2016 la finestra di copertura ESU va dal 12 gennaio 2027 al gennaio 2030, quindi fino a tre anni extra di protezione per i sistemi che non possono essere aggiornati o migrati in tempo.

Finora, per usufruirne su server on-premises servivano contratti tramite Volume Licensing e chiavi di attivazione da gestire manualmente, un processo tutt’altro che agile su larga scala. La novità è che ora gli ESU si possono attivare direttamente tramite Azure Arc, senza spostare il carico di lavoro su una VM Azure.

Come funziona l’abilitazione via Azure Arc

Il meccanismo si basa sul fatto che il server, anche se resta fisicamente on-premises, in edge o presso un altro cloud provider, viene “proiettato” in Azure come risorsa Arc-enabled. Una volta connesso, diventa possibile:

• Iscrivere il server agli ESU direttamente dal portale Azure, senza chiavi di attivazione tradizionali da inserire manualmente su ogni macchina.
• Pagare a consumo (pay-as-you-go) invece di dover sottoscrivere un impegno pluriennale anticipato: utile per chi non sa ancora con precisione quanti server serviranno la copertura o per quanto tempo.
• Gestire in modo centralizzato lo stato di copertura ESU su tutta la flotta di server, dentro e fuori Azure.

Va tenuto presente un requisito di licensing: le Extended Security Updates per Windows Server 2016 richiedono, nella maggior parte dei casi, Software Assurance attiva tramite un programma di Volume Licensing. È un punto da verificare con il proprio referente Microsoft prima di pianificare l’onboarding su larga scala.

Non solo patch: cosa arriva in dote con Azure Arc

Connettere i server a Azure Arc per gli ESU porta con sé, quasi come effetto collaterale positivo, l’accesso a un set di strumenti di gestione che normalmente sono associati alle risorse cloud native:

• Azure Update Manager: visibilità e pianificazione delle patch su tutta la flotta, ibrida o multicloud, da un’unica console.
• Change Tracking and Inventory: tracciamento delle modifiche a file, registro di sistema e software installato, utile in fase di audit o incident response.
• Azure Policy Guest Configuration: verifica automatica della conformità della configurazione interna della macchina rispetto a policy definite centralmente.

Per chi gestisce decine o centinaia di server Windows Server 2016 sparsi tra data center e sedi periferiche, questo significa passare da un controllo manuale, server per server, a una gestione centralizzata paragonabile a quella di un ambiente cloud nativo, pur restando on-premises.

Come prepararsi in pratica

Microsoft indica un percorso di preparazione abbastanza lineare, che vale la pena pianificare per tempo:

1. Censire i server a rischio

Identificare tutte le istanze Windows Server 2016 (edizioni Standard e Datacenter) che non potranno essere aggiornate o dismesse prima di gennaio 2027.

2. Connetterle ad Azure Arc

L’onboarding richiede l’installazione dell’agente Azure Connected Machine sui server target e la relativa registrazione nel proprio tenant Azure. È il prerequisito tecnico per tutto il resto.

3. Verificare i canali di distribuzione degli aggiornamenti

I server devono poter ricevere gli aggiornamenti tramite almeno uno di questi canali: Windows Update diretto, WSUS, oppure lo stesso Azure Update Manager. Vale la pena controllare ora, non a ridosso della scadenza, che le regole firewall e i proxy aziendali non blocchino questi endpoint.

4. Iscrivere i server agli ESU

Una volta Arc-enabled, l’attivazione della copertura ESU si fa dal portale Azure, senza dover distribuire chiavi di licenza manualmente su ogni singola macchina.

Un ponte, non una destinazione

Microsoft è esplicita su questo punto, e vale la pena ripeterlo a chi in azienda pensasse di usare gli ESU come soluzione permanente: gli Extended Security Updates sono pensati come bridge temporaneo per applicazioni business-critical che hanno bisogno di più tempo, non come alternativa a lungo termine alla modernizzazione. I tre anni di copertura vanno usati per pianificare concretamente la migrazione, che sia verso Windows Server più recenti on-premises, verso VM Azure, o verso il ridisegno delle applicazioni interessate.

Chi si limita a “comprare tempo” senza usarlo per muoversi si troverà comunque, a gennaio 2030, davanti allo stesso problema, ma con meno margine di manovra.

Conclusione

Il passaggio degli ESU per Windows Server 2016 da un modello a chiavi manuali a un’attivazione via Azure Arc pay-as-you-go semplifica sensibilmente la gestione della compliance di sicurezza su ambienti ibridi, e porta in dote strumenti di visibilità che normalmente restano appannaggio del cloud puro. Per i sistemisti che gestiscono infrastrutture legacy, il momento giusto per censire i server coinvolti e avviare l’onboarding su Azure Arc è adesso, non a dicembre 2026.

Fonte: Petri IT Knowledgebase – Microsoft Makes Azure Arc-Enabled ESUs for Windows Server 2016 Generally Available e Microsoft Community Hub – Azure Arc Blog

Generally Available: Windows Server 2016 Extended Security Updates enabled by Azure Arc | Microsoft Community Hub

Today, the Azure Arc team is pleased to announce that Extended Security Updates (ESUs) enabled by Azure Arc is now generally available for Windows Server...

^{Mason_Torres (TECHCOMMUNITY.MICROSOFT.COM)}

Spcnet.it

2026-08-10 11:47:20

Claude Code: le sessioni ora comunicano tra loro (ma non su Windows)

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.

Message your other Claude Code sessions - Claude Code Docs

Let Claude list and message your other Claude Code sessions on one machine, and reply to your sessions on other machines or on the web through Remote Control.

^{Claude Code Docs}