Workspace trust e cosa un repo può far fare all’agente

Cos’è il workspace trust e che cosa si attiva quando ti fidi di una cartella?

Nell’articolo sugli hook abbiamo parlato dei comandi che un agente esegue da solo, nell’articolo sulla sicurezza MCP dei server aggiunti a un repository e nell’articolo sulla sandbox di che cosa limita i comandi dell’agente. Questo articolo guarda alla domanda che hanno in comune: quando apri un repository con un agente di programmazione, che cosa può far fare il repository all’agente? La risposta breve:

Il workspace trust serve per la prima via. La prima volta che apri una cartella, lo strumento ti chiede se ti fidi e, finché non lo fai, non carica una parte della configurazione del repository. Secondo la documentazione di VS Code, lo scopo è impedire che il codice venga eseguito da solo; per questo la Restricted Mode disattiva o limita gli agenti, il terminale, i task, il debug, le impostazioni dell’area di lavoro e le estensioni. Ecco che cosa resta spento nei cinque strumenti finché non ti fidi della cartella:

Fonte: documentazione e note di rilascio degli strumenti, 20 ottobre 2026. «La documentazione non lo dice»: nelle pagine che abbiamo letto quel giorno non abbiamo trovato una frase che lo descriva. In Gemini CLI la decisione viene salvata in ~/.gemini/trustedFolders.json.

Gli strumenti hanno una cosa in comune: la fiducia si dà alla cartella, non al suo contenuto. Claude Code lega la fiducia alla radice del repository, e vale per tutto il repository. In Copilot CLI, quando ti fidi di una cartella anche per le sessioni future, la domanda non torna più; anche Gemini CLI chiede una sola volta per cartella. Quindi un hook che arriva più tardi in un repository di cui ti fidi può essere eseguito senza una nuova domanda. Il worm npm descritto più sotto ha usato proprio questa strada.

In VS Code, fidarsi di una cartella superiore significa fidarsi di tutte le cartelle che contiene. La documentazione lo propone come modo di organizzarsi: tieni i repository di cui ti fidi in una cartella e quelli che non conosci in un’altra, e fidati solo della prima. Se avvii Claude Code direttamente nella tua home directory, la fiducia vale solo per quella sessione e non viene scritta su disco.

Su Gemini CLI due fonti dicono cose diverse. La pagina Trusted Folders (aggiornata il 23 aprile) dice che la funzione è disattivata per impostazione predefinita; le note di rilascio della v0.59.0 (8 settembre) scrivono che la policy di fiducia è diventata «fail-closed». Controlla l’impostazione security.folderTrust.enabled nella tua installazione. Il 18 giugno 2026 Google ha smesso di servire Gemini CLI agli utenti gratuiti e agli abbonati Google AI Pro e Ultra, indirizzandoli ad Antigravity CLI; con una chiave API a pagamento puoi continuare a usare Gemini CLI.

Con quali file un repository può eseguire codice?

Quando un agente di programmazione apre una cartella, diversi file possono eseguire codice da soli. La maggior parte entra nel repository con un commit e compare nel diff della pull request. Uno non compare in nessun diff:

Lo stesso file può essere letto da più strumenti: Copilot CLI legge anche il .claude/settings.json del repository, e Cursor CLI unisce gli hook di Claude Code ai propri. Abbiamo spiegato gli hook nel dettaglio nell’articolo sugli hook e i file MCP nell’articolo su MCP. Qui guardiamo come gli attaccanti usano questi file; i due esempi sono di agosto e settembre.

Secondo il report di Aikido, il 4 agosto alcuni attaccanti hanno preso il controllo dell’account GitHub del maintainer della libreria keyv e hanno inserito nei pacchetti un worm che ruba credenziali. Il giorno dopo erano colpiti almeno 444 pacchetti e 1.381 versioni. Se tra le credenziali rubate il worm trovava un token di una GitHub App, faceva commit nei repository che riusciva a raggiungere, fino a 50 branch per repository. Questi commit aggiungevano hook a .claude/settings.json e a .vscode/tasks.json; l’autore era claude, il messaggio chore: update config.

Secondo l’analisi di Elastic Security Labs, per Claude Code veniva aggiunto un hook SessionStart, eseguito a ogni nuova sessione, e per VS Code un task folderOpen, eseguito all’apertura della cartella. La conclusione di Elastic: per infettarsi basta che lo sviluppatore apra il repository. Secondo Aikido non serviva nemmeno npm install.

Qui la domanda di fiducia può anche non entrare in gioco: la fiducia si dà a una cartella una volta, mentre il nuovo hook arriva con un commit in un repository che apri ogni giorno. VS Code ha una barriera in più: i task automatici non vengono mai eseguiti in una cartella non attendibile e, in una cartella attendibile, per impostazione predefinita chiedono il permesso una volta. In una pull request, il punto in cui si può individuare è il diff stesso: un «aggiornamento della config» che aggiunge un hook a .claude/settings.json. Autore e messaggio del commit sembravano normali; guarda il contenuto.

Il secondo esempio è il file che non arriva con un commit. Secondo GitSpawn, la ricerca che Manifold Security ha pubblicato il 1° settembre, gli agenti di programmazione eseguono comandi git in background per raccogliere contesto; alcuni lo facevano prima ancora che tu scrivessi qualcosa, perfino prima della domanda di fiducia. Quando aggiornano l’indice, comandi come git status eseguono il programma indicato nell’impostazione core.fsmonitor, e git legge questa impostazione dal .git/config del repository stesso. Il risultato, come lo descrive Manifold: il repository nomina un comando e git lo esegue con i tuoi permessi, fuori dalla sandbox e senza alcuna richiesta di approvazione.

Conta come arriva il file. Secondo Manifold, clonare il repository da un indirizzo malevolo non fa scattare la falla, e nemmeno fetch e pull; git non trasferisce questa impostazione. Perché l’attacco funzioni, il repository deve arrivare con la sua cartella .git: in un file zip, su un’unità condivisa, in una cartella sincronizzata o su una chiavetta USB. La regola della ricerca sta in una frase: qualsiasi impostazione che nomina un programma può eseguirlo. Il giorno della pubblicazione, 4 degli 8 rilievi erano stati corretti; controlla le note di rilascio del tuo strumento. Questo file non compare in nessun diff e può essere eseguito prima della domanda di fiducia; puoi controllarlo solo quando la cartella ti arriva.

Un agente che gira in CI fa la domanda di fiducia?

No: non c’è nessuno a cui chiedere. Gli strumenti si distinguono per quello che fanno al suo posto: alcuni usano la configurazione del progetto, altri non la caricano affatto, altri si fermano. Se un agente esamina le tue pull request in CI, guarda questa tabella:

Fonte: documentazione e note di rilascio degli strumenti, 20 ottobre 2026. «La documentazione non lo dice»: nelle pagine che abbiamo letto quel giorno non abbiamo trovato una frase che lo descriva. Cursor CLI si comporta così da gennaio 2026. Quando la fiducia nelle cartelle è attiva, Gemini CLI ferma un’esecuzione non interattiva con FatalUntrustedWorkspaceError.

La documentazione sui permessi di Claude Code mostra questo caso in una tabella apposita. In un’esecuzione claude -p in una cartella di cui nessuno si è mai fidato, le regole allow non vengono usate, ma gli hook del file di impostazioni e il blocco env sì. La parte MCP l’abbiamo trattata nell’articolo su MCP. La documentazione dice anche che cosa fare con un repository che non hai scritto tu: con --setting-sources user Claude Code non legge affatto i file di impostazioni del progetto; con --bare non legge dal progetto hook, skill, subagenti e plugin, ma il blocco env del progetto si applica comunque. Per spegnere gli hook, passa disableAllHooks a quell’esecuzione con --settings. Secondo la documentazione non basta scriverlo solo nelle tue impostazioni utente, perché le impostazioni del progetto possono prevalere sulle tue e rimetterlo a false.

In Copilot CLI fai attenzione a una variabile: se COPILOT_ALLOW_ALL vale esattamente true, la CLI si fida della cartella senza chiedere e carica tutto ciò che c’è nel repository, compresi gli hook che eseguono comandi di shell. Se vedi questa variabile in un workflow, controlla se il job gira sul branch della pull request. La documentazione di Codex fa anche un avvertimento specifico per la CI: nei job che fanno checkout del codice del repository o lo eseguono, non impostare la chiave API come variabile d’ambiente a livello di job; script di build, test e hook di installazione delle dipendenze possono leggerla.

In Gemini CLI questa falla è diventata un avviso di sicurezza ed è stata chiusa. Secondo l’avviso GHSA-wpqr-6v78-jr5g su GitHub (24 aprile 2026, critico, CVSS 10,0), le versioni precedenti si fidavano automaticamente della cartella quando giravano in CI. L’avviso nomina il rischio in modo esplicito: i workflow di CI che esaminano pull request inviate dagli utenti. Variabili d’ambiente messe nella cartella .gemini/ di un repository del genere potevano portare all’esecuzione di codice da remoto. La vulnerabilità è stata corretta in Gemini CLI 0.39.1 e nell’azione run-gemini-cli 0.1.22; ora devi fidarti esplicitamente della cartella anche in un’esecuzione non interattiva.

Cos’è la prompt injection e una pull request può ingannare un bot di review?

La prompt injection consiste nel mettere istruzioni in un testo che un modello legge, per cambiarne il comportamento. OWASP ne distingue due tipi: la prompt injection diretta, fatta con l’input dell’utente stesso, e la prompt injection indiretta, nascosta in una pagina web o in un file che il modello legge dall’esterno. Secondo OWASP il testo non deve nemmeno essere visibile a una persona; basta che il modello lo legga. Per un agente di programmazione questo testo può essere un file del repository, la descrizione di una pull request, una issue o un commento.

Il workspace trust non chiude questa via: appena esegui l’agente in una cartella, gli fai leggere anche il testo di quella cartella. Per questo la documentazione di VS Code consiglia di aprire in Restricted Mode un progetto che non hai esaminato. Qualsiasi file che l’agente porta nel suo contesto può dare luogo a una prompt injection; in Restricted Mode gli agenti non girano affatto. Contro il testo ti restano due leve: da dove vengono lette le regole e che cosa può fare l’agente.

GitInject (7 giugno 2026) ha misurato fin dove può arrivare tutto questo in CI, su workflow GitHub reali. I ricercatori hanno provato le configurazioni dei workflow di 4 provider di IA e documentato 11 attacchi. Si dividono in quattro classi: iniezione nei file di configurazione, furto di credenziali, manipolazione del giudizio e attacchi alla disponibilità. Ogni provider provato è risultato vulnerabile ad almeno una classe nella sua configurazione predefinita. Secondo gli autori, le vulnerabilità più gravi non nascono dal comportamento del modello, ma da come l’infrastruttura di CI gestisce credenziali e file di configurazione.

Per ingannare un bot di review non serve nemmeno scrivere istruzioni. PRWeaver (3 agosto 2026) ha costruito 208 attacchi in 10 repository reali, ognuno convalidato eseguendolo, e li ha fatti esaminare ciascuno in quattro presentazioni (832 casi) da 3 agenti di review con 6 configurazioni di modello. Quando le pull request venivano esaminate una per una, è stato individuato tra il 50% e il 60% degli attacchi; quando ne venivano esaminate 24 in una volta, il tasso scendeva tra il 16% e il 22%. Inserire l’attacco in una modifica reale, con una descrizione credibile che spiega entrambe le cose, ha abbassato il tasso di individuazione da 10 a 18 punti percentuali. Dividere l’attacco in più commit ha cambiato il risultato al massimo di 5 punti.

La conclusione degli autori: nascondere l’attacco funziona meglio quando modifiche innocue e malevole stanno insieme davanti a chi esamina, o quando lo scopo dichiarato nella descrizione fa sembrare ragionevole il diff. Nell’elenco dell’articolo sulla code review del codice generato dall’IA c’è un punto per questo: ogni affermazione della descrizione deve avere un riscontro nel diff. Dopo PRWeaver, chiediti anche il contrario: ogni modifica nel diff ha un motivo nella descrizione?

Il modo per guidare un bot di review in modo duraturo è cambiarne le regole. Se il file delle regole viene letto dal branch della pull request, la pull request può cambiare anche le regole della propria review. La documentazione degli strumenti dice cose diverse su questo punto:

Fonte: documentazione degli strumenti, 20 ottobre 2026. «La documentazione non lo dice»: nelle pagine che abbiamo letto quel giorno non abbiamo trovato una frase che lo descriva.

Un esempio di come restringere ciò che l’agente può fare è GitHub Agentic Workflows: l’agente gira con permessi di sola lettura, e le scritture, come una pull request che aprirebbe, non vengono applicate subito ma messe in attesa. Secondo la documentazione, prima che vengano applicate gira un job separato che cerca nell’output tentativi di prompt injection, segreti trapelati e codice malevolo. Un agente ingannato può fare solo i danni che gli consentono i permessi che gli hai dato.

Che cosa fare con un repository o una pull request che non conosci?

Ricapitolando: la domanda di fiducia arriva una volta, in CI mai, e non filtra il testo. Che cosa fare dipende dal caso:

• Un repository che non conosci. Non fidarti. VS Code consiglia, nel dubbio, di lasciare la cartella in Restricted Mode, e Cursor di aprire un repository non attendibile in un semplice editor di testo. Se devi lavorarci con un agente, aprilo in una macchina virtuale o in un container; anche la documentazione di Claude Code consiglia le macchine virtuali. Una sandbox da sola non basta: in Claude Code la sandbox copre solo i comandi di shell, e hook e server MCP restano fuori. I dettagli sono nell’articolo sulla sandbox.
• Una cartella che ti hanno passato. Se una cartella arrivata in uno zip, su un’unità condivisa o su una chiavetta USB contiene .git, come consiglia Manifold, leggi .git/config prima di aprirla con un agente, oppure clona di nuovo il repository dalla sua origine.
• Un agente che in CI esamina pull request da fork. Non far caricare all’agente la configurazione del progetto: in Claude Code passa --setting-sources user, e non usare COPILOT_ALLOW_ALL in Copilot CLI né --trust in Cursor CLI sul branch della pull request. La guida di GitHub del 7 maggio 2026 considera permissions: read-all un default ragionevole e dice di non fare mai eval dell’output del modello. Non mettere segreti nello step dell’agente.
• Una pull request che tocca un file di impostazioni o di regole. Leggi un diff che tocca uno dei file della seconda sezione come una modifica di sicurezza; anche la guida di GitHub considera bloccante qualsiasi modifica che indebolisce la CI. Se il tuo bot di review legge le regole dal branch della pull request, una modifica al file delle regole decide anche come verrà esaminata quella pull request; leggi anche quella come codice.

Abbiamo fatto le stesse domande al nostro servizio di review. Il nostro strumento di code review con l’IA, diffox, a ogni review clona da zero il repository da GitHub in una cartella vuota; dato che un clone non porta con sé .git/config, la strada usata da GitSpawn non ci raggiunge. Come abbiamo descritto nell’articolo sull’architettura, le regole vengono lette dal branch in cui la pull request verrà unita. L’autore di una pull request da un fork può scrivere il diff e i nomi dei file come vuole; ma il testo che da lì arriva nel nostro commento non può aprire un tag HTML né diventare un link. Questa regola serve a impedire che compaia un link di phishing con il nostro nome, che qualcuno chiuda la sezione compressa per scrivere una falsa sezione «nessun problema» e che i dati escano attraverso un’immagine.

Domande frequenti

Cos’è il workspace trust?

È lo strumento di programmazione o l’editor che, la prima volta che apri una cartella, ti chiede se ti fidi e, finché non lo fai, non carica una parte della configurazione della cartella. Lo scopo è impedire che hook, task e server MCP messi in un repository vengano eseguiti prima che tu li abbia guardati. Ce l’hanno Claude Code, Codex, GitHub Copilot, Cursor e Antigravity CLI; nell’editor di Cursor è disattivato per impostazione predefinita. La fiducia si dà a una cartella una volta, e non impedisce al testo della cartella di guidare l’agente.

Che cosa attiva la fiducia in una cartella in Claude Code?

Claude Code lega la fiducia alla radice del repository, e vale per tutto il repository. Dopo che ti sei fidato vengono usati le regole allow e le directory aggiuntive del .claude/settings.json del progetto, gli hook e i server MCP dei subagenti e i plugin che arrivano dal repository; anche gli hook e il blocco env del file di impostazioni girano nella sessione. Per i server di .mcp.json c’è una domanda a parte. La domanda compare solo in una sessione interattiva; claude -p e l’SDK non chiedono mai. Se lo avvii nella tua home directory, la fiducia vale solo per quella sessione.

Come si toglie una cartella attendibile?

Dipende dallo strumento. In VS Code apri l’editor di Workspace Trust (Workspaces: Manage Workspace Trust) e togli la cartella dall’elenco delle cartelle attendibili. In Copilot CLI modifica l’elenco trustedFolders in ~/.copilot/config.json. In Gemini CLI scrivi /permissions in quella cartella; tutte le decisioni sono in ~/.gemini/trustedFolders.json. In Codex imposta il trust_level di quel progetto a untrusted in ~/.codex/config.toml. Claude Code salva la fiducia nel campo hasTrustDialogAccepted di ~/.claude.json; un comando per annullarla, la documentazione non lo dice. Nemmeno la documentazione di Cursor e quella di Antigravity ne parlano.

Si può disattivare il workspace trust in VS Code?

Sì: l’impostazione security.workspace.trust.enabled (attiva per impostazione predefinita) spegne del tutto la funzione, mentre l’opzione --disable-workspace-trust lo fa solo per quella sessione. VS Code stesso consiglia il contrario: nel dubbio, lascia la cartella in Restricted Mode; la fiducia puoi darla dopo. In Restricted Mode agenti, task, debug e terminale sono spenti. Puoi raccogliere i repository che apri spesso in una cartella superiore e fidarti solo di quella, e tenere quelli che non conosci in un’altra.

Cos’è la prompt injection?

È nascondere istruzioni in un testo che un modello legge, per cambiarne il comportamento. OWASP ne distingue due tipi: la prompt injection diretta, fatta con l’input dell’utente stesso, e la prompt injection indiretta, nascosta in una pagina web, in un file o in un commento che il modello legge dall’esterno. Negli agenti di programmazione conta soprattutto la seconda: un file del repository, la descrizione di una pull request o il testo di una issue entrano nel contesto dell’agente. Secondo OWASP il testo non deve nemmeno essere visibile a una persona; basta che il modello lo legga.

Una pull request può ingannare uno strumento di code review con l’IA?

Le ricerche dicono di sì. In PRWeaver, agenti di review basati sull’IA hanno individuato tra il 50% e il 60% degli attacchi nascosti quando le pull request venivano esaminate una per una, e tra il 16% e il 22% quando ne venivano esaminate 24 insieme; una descrizione credibile ha abbassato ancora il tasso. In GitInject tutti e 4 i provider provati erano vulnerabili ad almeno una classe di attacchi nella loro configurazione predefinita. Controlla se il tuo strumento legge le regole dal branch della pull request o dal branch in cui verrà unita. In diffox le regole vengono lette dal branch in cui la pull request verrà unita, e il testo della pull request che arriva nel suo commento non può diventare né un tag né un link.

La domanda di fiducia compare con claude -p o in CI?

No. Secondo la documentazione di Claude Code, claude -p e le sessioni dell’SDK non mostrano mai la domanda di fiducia; vengono usati gli hook del file di impostazioni del repository, il blocco env e apiKeyHelper, e i server di .mcp.json si collegano senza chiedere. In un repository che non hai scritto tu, avvialo con --setting-sources user o --bare; per spegnere gli hook, passa disableAllHooks con --settings. La modalità -p di Copilot CLI non carica gli hook del repository in una cartella non attendibile; Cursor CLI si ferma se non passi --trust.