Dove l’auto mode e la sandbox fermano l’agente

Quali controlli supera un comando prima di essere eseguito?

Quando un agente di programmazione vuole eseguire un comando, la decisione non si prende in un solo punto. La documentazione di tutti e cinque gli strumenti descrive gli stessi quattro livelli: prima le regole che scrivi tu, poi la sandbox applicata dal sistema operativo, poi un modello a parte che esamina il comando e, per ultimo, tu. Come scrivere regole con gli hook l’abbiamo spiegato nell’articolo sugli hook. Qui guardiamo gli altri tre, con le misurazioni dei fornitori stessi:

Perché sia stato messo un modello in mezzo lo mostrano i dati dei fornitori stessi. Secondo Anthropic, gli utenti di Claude Code approvano il 97% delle richieste di permesso. Gli stessi utenti rifiutano il 39% dei piani che l’agente propone, ma sulle singole richieste di permesso il tasso di rifiuto è solo del 3%. È come approvare una pull request senza leggerla: le richieste arrivano così spesso che si approvano senza leggerle.

Un esperimento nello stesso articolo di Anthropic mette in numeri la differenza. Nella sessione di 1.053 utenti di test pagati è stato inserito un solo comando pericoloso. In realtà era stato cambiato solo il testo della richiesta; anche approvando il comando, non veniva eseguito nulla. Le persone hanno fermato questo comando nel 13,6% dei casi, l’auto mode nell’89%. Più la sessione si allungava, più cose sfuggivano alle persone: all’inizio fermavano circa il 17% dei comandi pericolosi, dopo 50 o più richieste circa il 5%. Questi risultati vengono dall’esperimento del fornitore stesso.

Anche OpenAI ha visto lo stesso problema tra i propri utenti. Secondo l’articolo di OpenAI, quando le richieste di approvazione sono frequenti, gli utenti passano alla modalità Full Access, in cui non si applica nessuna regola, oppure scrivono regole ampie che permettono qualsiasi comando che inizi con python. Secondo Anthropic, a giugno il 43% degli utenti attivi della CLI aveva una regola per un interprete come Bash(python:*). Entrambi i fornitori hanno scelto la stessa soluzione: fare la domanda a un modello a parte, non a una persona.

Come decidono l’auto mode e l’auto-review?

La chiamata su cui non decidono né le regole né la sandbox passa al modello che autorizza, ed è lui a decidere se eseguirla. Ormai tutti e cinque gli strumenti hanno un modello del genere; ma cosa vede, quando ti restituisce la decisione e se è attivo di default cambia da uno strumento all’altro. La situazione al 20 ottobre 2026:

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. Il giudice di Copilot è arrivato nella CLI il 7 luglio; la documentazione di VS Code indica questo livello di permesso come sperimentale.

In Claude Code l’ordine delle decisioni è fisso: prima le tue regole allow, ask e deny, poi le letture e le modifiche nella directory di lavoro, per ultimo il classificatore. Quando passi all’auto mode, le regole ampie che permettono di eseguire qualsiasi codice, come Bash(*) o Bash(python*), vengono messe da parte; le regole strette come Bash(npm test) restano. Il classificatore non vede l’output degli strumenti; così un’istruzione nascosta in un file o in una pagina web non può guidarlo direttamente. Quando blocca una chiamata, sullo schermo compare Denied by auto mode classifier, accanto al nome della regola corrispondente, come [Data Exfiltration].

Codex fa la scelta opposta. L’auto-review vede anche l’output degli strumenti e, se serve, fa da sé controlli in sola lettura. Ma guarda solo le chiamate che vogliono superare il confine della sandbox; un comando che resta dentro la sandbox non viene mai esaminato. Secondo la documentazione non è un permesso, solo un cambio di revisore: l’auto-review non allarga le directory scrivibili e non apre la rete. La policy di default si trova nel repository open source di Codex, in una cartella chiamata guardian. Se scrivi una policy tua, non si unisce a quella di default ma la sostituisce. Secondo l’articolo di OpenAI del 30 aprile 2026, il revisore allora girava su GPT-5.4 Thinking; la documentazione non dice quale modello usi oggi.

Cursor ha rilasciato Auto-review il 29 maggio e da allora la propone come default consigliato. Il classificatore gira con modelli piccoli sui server di Cursor e, per decidere, può leggere in sola lettura i file sulla tua macchina. In Copilot il giudice è arrivato prima nella CLI. Secondo la documentazione di VS Code, Assisted permissions è un livello sperimentale: un giudice LLM valuta ogni chiamata a uno strumento e, se non la approva, viene chiesto a te. Antigravity CLI ha aggiunto l’Auto mode il 14 ottobre: approva senza chiedere le modifiche ai file e i comandi sicuri, mentre i comandi che uscirebbero dalla sandbox li esamina prima un agente a parte. La pagina delle modalità di Antigravity non riporta ancora questa modalità; l’informazione è nelle note di rilascio.

Se usi ancora Gemini CLI, la sua documentazione non descrive il modello che autorizza: il policy engine decide con regole fisse e il risultato lo stabilisce la prima regola che corrisponde. Google ha smesso di servire Gemini CLI agli abbonati Google AI Pro e Ultra e agli utenti individuali gratuiti il 18 giugno 2026 e li ha indirizzati ad Antigravity CLI; con una chiave API a pagamento puoi continuare a usare Gemini CLI. Attenzione anche a un nome che si confonde: in Copilot e in Cursor, «Auto» è anche il nome del router che sceglie un modello. Ne abbiamo parlato nell’articolo sulla scelta del modello; l’auto mode di questo articolo riguarda i permessi.

Quanto spesso sbaglia il modello che autorizza?

Il modello che autorizza può sbagliare in due modi: lascia passare una chiamata pericolosa oppure ferma inutilmente una chiamata innocua. Nel primo caso il comando viene eseguito; nel secondo l’agente prova un’altra strada o chiede a te. Due fornitori misurano e pubblicano entrambe le cose: Anthropic e OpenAI. Nella documentazione di Cursor, di GitHub e di Google non abbiamo trovato misurazioni. Anthropic ha confrontato le persone e il classificatore sugli stessi comandi:

Questi numeri vengono da set di test; nell’uso reale il quadro è meno roseo. Nell’articolo di ingegneria di Anthropic del 25 marzo 2026, su 10.000 chiamate reali agli strumenti fatte dai dipendenti dell’azienda, il classificatore ha fermato inutilmente lo 0,4% delle chiamate innocue. D’altra parte, l’agente è andato oltre ciò che l’utente voleva in 52 azioni reali, e il classificatore non ne ha individuato il 17%. L’articolo stesso chiama questo numero «the honest number». Nella maggior parte dei casi mancati il classificatore aveva visto il pericolo, ma aveva creduto che il consenso dato dall’utente coprisse anche questa azione: dire «Clean up the PR» non significa autorizzare un force push. Allora il classificatore girava su Sonnet 4.6; oggi il modello di default è Claude Sonnet 5.

OpenAI ha fatto la propria misurazione su dati sintetici. Secondo OpenAI, l’auto-review ha individuato il 90,3% dei casi in cui l’agente andava oltre quanto richiesto. Per la prompt injection il tasso di individuazione è del 99,3% su tre tipi di attacco; contando tutti i tipi, cancellazioni e manomissione dei dati compresi, scende al 90,2%. Nelle attività di red team hanno trovato casi in cui l’auto-review poteva essere indotta ad approvare un comando senza l’approvazione dell’utente; scrivono anche che da questo tipo di sistema non si aspettano garanzie deterministiche. In un test di attacchi sintetici che Anthropic ha condotto con un team esterno, la quota di casi mancati dal classificatore è scesa dal 12% al 7% dopo le correzioni; Anthropic chiede di non leggere questo numero come la quota di casi mancati sul traffico reale. Come leggere un risultato dichiarato da un fornitore l’abbiamo spiegato nell’articolo su SWE-bench.

La documentazione dice anche cosa il modello non può vedere. Il modello che autorizza vede solo la chiamata che ha davanti: in Codex i comandi che restano dentro la sandbox non gli arrivano mai, e in Claude Code nemmeno le letture e le modifiche nella directory di lavoro. OpenAI scrive che un modello che nasconde le proprie intenzioni potrebbe produrre una richiesta dall’aria innocua, o fare dentro la sandbox cose che l’auto-review non vede mai. Il classificatore di Claude Code non vede l’output dei comandi precedenti. Per questo, se il bersaglio di un rm -rf è una variabile di shell il cui valore non è mai comparso nella conversazione, non può verificare la cancellazione e la blocca. Un limite che fissi nella conversazione, come «non fare push», non viene nemmeno salvato come regola; secondo la documentazione, quel messaggio può andare perso quando il contesto viene compattato. Come succede l’abbiamo spiegato nell’articolo sull’auto compact. Per un divieto netto, scrivi una regola deny.

L’equilibrio tra un pericolo mancato e uno stop inutile è lo stesso che nella code review c’è tra bug reale e falso allarme: l’impostazione che riduce l’uno aumenta l’altro. Anche i fornitori stessi sono chiari. Cursor scrive in un titolo che Auto-review non è un confine di sicurezza; VS Code dice lo stesso di Assisted permissions. OpenAI scrive che l’auto-review non è una garanzia di sicurezza deterministica, e Anthropic che l’auto mode non garantisce la sicurezza. Il confine lo traccia la sandbox.

Cosa limita davvero una sandbox?

La sandbox limita il comando che l’agente esegue con gli strumenti del sistema operativo stesso: Seatbelt su macOS, e bubblewrap, Landlock o i namespace del kernel su Linux. Anche se il modello sbaglia, il comando non può scrivere in un file non consentito né collegarsi a un server non consentito. Ma i default dei cinque strumenti sono molto diversi:

Fonte: documentazione sulla sandbox degli strumenti, 20 ottobre 2026. La sandbox locale di Copilot è disponibile per tutti dal 7 ottobre. Anche in Gemini CLI la sandbox la attivi tu, con un flag, una variabile d’ambiente o un’impostazione.

La colonna più importante della tabella è l’ultima. La documentazione di Claude Code dice che la sandbox copre solo i comandi di shell: gli strumenti per i file come Read ed Edit seguono le regole dei permessi, e gli hook e i server MCP locali girano con tutti i tuoi permessi. Secondo la documentazione di GitHub, neanche la sandbox del sistema operativo vede cosa fanno gli strumenti per i file propri di Copilot CLI; li limita solo un controllo nel software. Perché i server MCP locali richiedono un’attenzione in più l’abbiamo spiegato nell’articolo sulla sicurezza MCP.

La maggior parte delle evasioni dalla sandbox registrate nasce proprio da questo varco: un comando dentro la sandbox prepara qualcosa e una parte fuori dalla sandbox lo esegue o ci scrive attraverso. Nella NVD ce ne sono tre esempi, tutti e tre corretti:

• Claude Code (CVE-2026-39861, prima della 2.1.64): un comando nella sandbox poteva creare un link simbolico che puntava fuori dalla directory di lavoro. Quando Claude Code, che gira fuori dalla sandbox, scriveva su quel percorso, il file finiva fuori dalla directory. Secondo la scheda, nessuno dei due poteva scrivere fuori dalla directory da solo; l’evasione avveniva quando i due si combinavano.
• Cursor (CVE-2026-26268, prima della 2.5): un agente guidato tramite prompt injection poteva scrivere nelle impostazioni .git poco protette e negli hook di git; git poi eseguiva da solo quegli hook, fuori dalla sandbox. Ora Cursor blocca sempre la scrittura in .git/hooks e .git/config.
• Codex (CVE-2026-19591): il parser che distingue i comandi sicuri ha considerato sicuri per errore alcuni comandi PowerShell, e un comando git che scrive su un file ha potuto girare senza chiedere l’approvazione. Secondo la scheda, su macOS e Linux la sandbox di default poteva comunque impedire la scrittura nei punti non consentiti: quando il livello delle regole ha sbagliato, la sandbox poteva tenere il confine.

Questa debolezza del livello delle regole la descrive anche la documentazione di VS Code: l’approvazione automatica basata su regole può analizzare un comando solo al meglio delle sue possibilità; la concatenazione di virgolette o gli alias della shell possono aggirare le regole. Anche sul lato della rete c’è un punto debole noto. Secondo la documentazione di Claude Code, il proxy decide in base al nome di dominio indicato dal client, senza ispezionare il TLS; per questo, con tecniche come il domain fronting si possono raggiungere server che non sono nell’elenco. La stessa pagina avverte che consentire un dominio ampio come github.com può aprire una via all’esfiltrazione dei dati. Anche i bug della sandbox stessa compaiono nelle note di rilascio: nella versione 2.1.224 è stato corretto un bug per cui una voce denyRead che termina con una barra poteva essere aggirata in silenzio su Linux e macOS.

Anche con i segreti gli strumenti si comportano in modo diverso. Claude Code non ha una lista di blocco integrata per le credenziali; vengono limitati solo i file e le variabili che elenchi tu. Se vuoi, puoi mascherare una chiave: il comando vede un segnaposto valido solo per quella sessione al posto del valore reale, e il proxy inserisce il valore reale solo nelle richieste verso i server che consenti. Claude Code non legge questa impostazione dal .claude/settings.json del repository, ma solo dalle impostazioni utente o gestite dall’amministratore. Copilot, con la sandbox attiva, passa di default le credenziali di Git e gh nello stesso modo; il token reale di gh va solo agli indirizzi di github.com. Antigravity blocca ~/.ssh e .env fin dall’inizio. Cosa succede in Copilot con la sandbox disattivata lo dice chiaramente la documentazione di GitHub: i comandi possono leggere e scrivere ovunque con i permessi del tuo account, raggiungere qualsiasi rete raggiungibile dalla tua macchina e usare le tue credenziali senza restrizioni.

Quale modalità usare per quale lavoro?

Tutte le prove vanno nella stessa direzione: il modello che autorizza riduce le domande che arrivano a te, il confine lo traccia la sandbox. Usali insieme e scegli l’impostazione in base al lavoro:

Nel lavoro quotidiano che segui di persona, usa il modello che autorizza insieme alla sandbox. In Claude Code l’auto mode è già la modalità di partenza; attiva anche la sandbox con /sandbox. In Codex la sandbox è già attiva; scegli «Approve for me» nel menu dei permessi. In Cursor lascia attiva Auto-review. In Copilot CLI attiva la sandbox con /sandbox enable. In Antigravity CLI attiva la sandbox con --sandbox e scegli --mode auto. Se vuoi vedere cosa blocca il modello, dal 15 ottobre Claude Code scrive la decisione del classificatore negli eventi OpenTelemetry, e Codex conserva le trascrizioni dell’auto-review in ~/.codex/sessions.

Se l’agente chiede continuamente il permesso, regola il confine invece di aprire tutto. È anche il consiglio di OpenAI: se le richieste ordinarie finiscono in revisione, correggi prima il confine della sandbox e scrivi regole strette come ["cargo", "test"] invece di prefissi ampi come ["python"]. In Claude Code, se non vuoi un classificatore, usa la modalità Manual insieme alla modalità auto-allow della sandbox; i comandi che restano dentro la sandbox girano senza chiedere. Dai il permesso una volta, come regola stretta, non ogni volta che l’agente lo chiede.

Nelle esecuzioni non presidiate non c’è nessuno a cui chiedere. Claude Code avvia le esecuzioni lanciate con -p in Manual, a meno che tu non indichi una modalità, e rifiuta le chiamate che richiedono un’approvazione. Gli agenti cloud di Cursor girano su una macchina tutta loro e non chiedono mai approvazioni. In un’esecuzione del genere tieni attiva la sandbox, limita la rete a un elenco di domini e non mettere nell’ambiente chiavi che non servono. Se devi dare accesso completo, fallo solo in un container usa e getta; lì il confine lo traccia il container stesso. La documentazione di Codex scrive che anche in un container del genere un progetto malevolo può portare fuori tutto ciò che c’è dentro, comprese le credenziali di Codex.

Una parte di queste impostazioni vive nel repository e può cambiare con una pull request. Claude Code non permette di attivare l’auto mode dal file di impostazioni del repository; ma, a meno che un amministratore non renda obbligatoria la sandbox, legge da quel file le voci che allentano il confine, come excludedCommands e network.allowedDomains. La sua documentazione scrive che con una voce excludedCommands ampia l’agente può scrivere un file ed eseguirlo fuori dalla sandbox. Cursor unisce il .cursor/sandbox.json del repository all’impostazione dell’utente e dà la priorità al file del repository; Codex carica il .codex/config.toml del repository in un progetto di cui ti fidi. Una pull request che tocca uno di questi file cambia il confine per tutti quelli che aprono il repository; esaminala come una modifica di sicurezza. Prima di aprire con un agente un repository di cui non ti fidi, guarda anche questi file.

Applichiamo lo stesso principio nel nostro prodotto. In diffox, il nostro strumento di code review con l’IA, il passaggio che traccia il blast radius di una pull request legge i file del cliente e non chiama nessuno all’esterno. Questo passaggio costruisce il proprio ambiente a partire da un elenco di consentiti: oltre a PATH, HOME, le impostazioni della lingua e la directory temporanea, non prende nessuna variabile. Una lista di blocco lascerebbe passare una nuova chiave aggiunta domani.

Domande frequenti

Cos’è l’auto mode di Claude Code?

L’auto mode è una delle modalità di permesso di Claude Code: un modello classificatore a parte risponde al posto tuo alle richieste di permesso. Prima si applicano le tue regole allow, ask e deny, e le letture e le modifiche nella directory di lavoro passano senza chiedere; le chiamate restanti le esamina il classificatore, che di default gira su Claude Sonnet 5. Puoi cambiare il modello con CLAUDE_CODE_AUTO_MODE_MODEL. Di default blocca l’invio di dati sensibili all’esterno, i deploy in produzione e il force push; dopo 3 blocchi di fila o 20 in totale nella sessione, torna a chiedere a te. Il 14 agosto è diventato la modalità di partenza nei piani Pro, Max e Team; dal 28 settembre le sessioni interattive partono in questa modalità in tutti i piani. La documentazione di Anthropic scrive che l’auto mode non garantisce la sicurezza.

Cosa significa «Denied by auto mode classifier»?

Significa che il classificatore di Claude Code ha giudicato quella chiamata non sicura. Il nome tra parentesi quadre, per esempio [Data Exfiltration] o [Production Deploy], è quello della regola corrispondente. Puoi vedere le chiamate bloccate nella scheda Recently denied di /permissions e, con il tasto r, dire all’agente che può riprovare quella chiamata. Se ciò che è stato bloccato è un registro di pacchetti o un dominio interno di cui l’agente ha sempre bisogno, aggiungilo ad autoMode.environment; /auto-mode-setup prepara per te una bozza di queste voci. Se si tratta di un’operazione una tantum, scrivi chiaramente la tua intenzione nel messaggio successivo.

Che differenza c’è tra l’auto-review e il full access di Codex?

Entrambi riducono le richieste di approvazione, ma mettono il confine in punti diversi. L’auto-review («Approve for me») lascia la sandbox workspace-write così com’è; solo le chiamate che vogliono uscire dalla sandbox vengono mandate a un agente revisore a parte invece che a te. Il full access significa sandbox_mode = "danger-full-access" con approval_policy = "never": niente sandbox e niente domande; l’agente accede a internet e a ogni file del tuo computer. Nella misurazione di OpenAI stessa, l’auto-review ha individuato il 90,3% degli scenari sintetici in cui l’agente superava il confine, e la sessione si è fermata per un’approvazione umana circa 200 volte meno spesso. Con il full access questo controllo non c’è proprio.

Come si attiva la sandbox di Claude Code?

Scrivi /sandbox nella sessione oppure imposta sandbox.enabled a true in ~/.claude/settings.json. Su macOS non serve altro; su Linux e WSL2 devono essere installati bubblewrap e socat. Su Windows nativo i comandi girano senza sandbox. Quando è attiva, i comandi possono scrivere nella directory di lavoro e nella directory temporanea, e uscire in rete solo verso i domini che consenti. La sandbox copre solo i comandi di shell; strumenti per i file, hook e server MCP locali restano fuori. Se non vuoi che i comandi vengano riprovati fuori dalla sandbox, imposta allowUnsandboxedCommands a false.

L’agente può leggere ~/.ssh con la sandbox attiva?

Dipende dallo strumento. Di default la sandbox di Claude Code può leggere quasi tutta la macchina, ~/.ssh e ~/.aws/credentials compresi; per chiuderla serve l’impostazione filesystem.denyRead o credentials. In Cursor il limite di lettura di default è «system» e ~/.ssh è leggibile; se scegli «workspace», di ~/.ssh resta solo known_hosts. La sandbox di Copilot chiude ogni percorso del file system che non hai consentito, ma con l’accesso di default agli strumenti di sviluppo i comandi possono leggere i token salvati dai gestori di pacchetti. Antigravity blocca ~/.ssh e .env fin dall’inizio. La documentazione di Codex non indica chiaramente il limite di lettura di default; consiglia una regola deny per percorsi come ~/.ssh.

Perché Claude Code chiede sempre il permesso?

Di solito perché la sessione è partita in modalità Manual. Dal 28 settembre Claude Code avvia le sessioni interattive in auto mode; ma se nelle tue impostazioni utente defaultMode indica un’altra modalità, se il tuo modello non supporta l’auto mode o se la tua organizzazione ha disattivato l’auto mode, la sessione parte in Manual. Puoi passare all’auto mode con Shift+Tab. Anche in auto mode ti viene chiesto per le regole ask come Bash(git push *) e per la prima lettura fuori dalla directory di lavoro. Se non vuoi un classificatore, attiva la sandbox in modalità auto-allow; i comandi dentro la sandbox girano senza chiedere. Non scrivere una regola come Bash(*) che apre tutto.

L’auto mode è a pagamento?

Dipende dallo strumento. Dal 7 agosto Anthropic non fa pagare i token extra del classificatore nei piani Pro, Max e Team. Nel piano Enterprise e negli account che usano la Claude API, Bedrock, Google Cloud o Foundry, le chiamate del classificatore contano nell’uso dei token; quando la revisione avviene lato server, non c’è una chiamata separata. Cursor scrive che il classificatore di Auto-review non aggiunge costi all’uso dell’agente. La documentazione di Codex, Copilot e Antigravity non indica quanto costa il modello che autorizza.