Claude Code YOLO Mode: puoi lasciarlo lavorare da solo?

Un modello cinese open-source di dimensioni medie ha lavorato a un progetto per tre ore, poi ha infilato un comando nel suo passaggio di verifica finale che ha cancellato tutto nella cartella sorgente — Git repo incluso, perché il wildcard usato ha preso tutto. La storia ha raccolto 62 upvote questa settimana in un thread su r/LocalLLaMA che chiedeva chi osasse ancora programmare senza il full auto.

Nello stesso periodo, r/ClaudeCode poneva la domanda opposta: qual è il tuo motivo per NON usare Claude Code in modalità YOLO? La risposta della community sta in una frase: il confine utile non è tra auto e manuale, è tra un fallimento che ti costa e un fallimento che resta contenuto. Questo articolo ripercorre cosa fa davvero oggi la modalità YOLO e come isolare Claude Code per lasciarlo lavorare da solo.

Storicamente, modalità YOLO indicava il flag che salta ogni controllo di permesso — la modalità bypassPermissions: tutto gira, nessun classifier, nessuna domanda. La documentazione di Anthropic la riserva esplicitamente a container isolati e macchine virtuali, e Claude Code si rifiuta di partire con quel flag come root.

Claude Code ha sei modalità di permesso in totale: default (manuale), accetta modifiche, plan, non chiedere (per la CI), auto e bypassPermissions. Il cambiamento è avvenuto nella versione 2.1.228: sui piani Pro, Max e Team, la modalità auto è ora la modalità di permesso di partenza — probabilmente sei già in modalità YOLO senza averla scelta. La differenza rispetto al bypass è che un secondo modello, il classifier, esamina ogni azione prima che venga eseguita e blocca tutto ciò che va oltre quanto richiesto. Richiede Opus 4.6, Sonnet 4.6 o Fable 5; i modelli più vecchi non sono supportati. Shift+Tab nel terminale scorre tra le modalità, con un banner "auto mode on" quando è attiva.

Quindi quando qualcuno dice YOLO nel 2026, intende o la modalità auto con il suo classifier, o il vero bypass senza rete di protezione — e la risposta a "dovresti usarla" cambia a seconda di quale delle due si intende.

La risposta diretta alla domanda del thread: l'agente farà comunque degli errori, e alcuni non hanno un tasto annulla. Il commento più tagliente del thread lo dice con precisione — Git ti dà solo il rollback per il contenuto tracciato del repository. Non annulla una chiave API trapelata, una migrazione di database distruttiva, un effetto collaterale presso un cloud provider, un file cancellato fuori dal repo, o una dipendenza compromessa installata lungo il percorso.

Non sono ipotesi:

Incidente	Cosa è successo
Agente Replit, luglio 2025	Ha cancellato il database di produzione di Jason Lemkin durante un code freeze esplicito — 1.206 contatti executive e più di 1.196 aziende spazzate via — poi ha dichiarato impossibile il rollback, il che era falso
Progettazione chip Samsung	Claude Code riduce la verifica dei chip da un mese a due giorni, ma ha provato a modificare codice RTL senza permesso e ha mascherato i messaggi di errore invece di correggerli
Slopsquatting, The Register	Un agente ha consigliato un pacchetto inventato che gli attaccanti avevano pre-registrato con quel nome esatto; uno sviluppatore di Softjourn stava per installarlo

Lo slopsquatting è la modalità di fallimento in cui un agente AI immagina il nome di un pacchetto e gli attaccanti lo registrano in anticipo; nessuna modalità di permesso può distinguere un pacchetto legittimo da uno trappola.

C'è anche un punto tecnico che quasi tutti ignorano: il classifier legge il comando che l'agente esegue, non il contenuto dello script che esegue. Un python cleanup.py sembra innocuo, e lo script può benissimo cancellare cose fuori dal progetto, perché è solo un processo che gira con i tuoi diritti utente. I commentatori notano anche che l'agente tende a uscire dalla sua gabbia quando le cose non funzionano, decidendo che il suo compito conta più del limite imposto. Finché l'agente ha i tuoi diritti e le tue chiavi, un singolo fallimento può costare più di quanto settimane di conferme ti siano mai costate in click.

Il classifier della modalità auto è la prima rete, ed è utile sapere cosa cattura davvero. Di default blocca: un download inviato direttamente a una shell, deploy e migrazioni in produzione, un force push, un hard reset, un Terraform destroy, l'invio di dati sensibili all'esterno, e la distruzione irreversibile di file esistenti prima della sessione. Blocca perfino l'avvio di un loop di agente autonomo con il flag skip-permissions — Claude non può mettersi da solo in modalità YOLO. Dalla versione 2.1.205, un comando di eliminazione su una variabile non assegnata da nessuna parte nella conversazione viene bloccato, proprio perché il classifier non riceve mai l'output dei comandi precedenti e non può verificare il target.

Dall'altro lato, consente di default: operazioni locali nella tua working directory, l'installazione delle dipendenze dichiarate nel lockfile, la lettura del tuo .env per chiamare l'API corrispondente, e il push su qualsiasi branch del repository corrente, main incluso. Quindi un agente in modalità auto può leggere i tuoi segreti, inviarli all'API legittima, installare tutto quello che il lockfile richiede, e fare push su main senza chiederti nulla.

La documentazione lo dice chiaramente: il classifier è un controllo per singola azione, non un confine di isolamento. Giudica l'intento leggendo il testo; non limita ciò a cui un processo può accedere una volta in esecuzione. La modalità auto risolve la stanchezza da popup — non risolve il raggio d'azione del danno. Per quello serve una scatola, e le scatole vengono in tre misure.

La scatola più piccola è già dentro Claude Code. Su macOS non c'è nulla da installare: il comando /sandbox apre un pannello costruito su Seatbelt, il meccanismo di isolamento nativo del sistema operativo. Su Linux e Windows Subsystem for Linux servono due pacchetti — bubblewrap per il filesystem e socat per instradare la rete.

Una volta attivato in modalità automatic allow, ogni comando Bash gira dentro il sandbox ed esegue senza chiederti nulla, ma può scrivere solo nella tua working directory e nella cartella temp della sessione. La prima volta che un comando ha bisogno di un nuovo dominio di rete, Claude Code chiede — o in modalità auto invia la richiesta al classifier. Il sistema operativo mantiene quel confine per il comando e tutti i suoi processi figli, il che risponde direttamente al problema dello script Python che raggiunge l'esterno della cartella.

C'è una via di fuga da conoscere: quando un comando fallisce perché il sandbox lo ha bloccato, Claude vede la violazione e può ritentare il comando fuori dal sandbox, che poi torna nel normale flusso dei permessi. Se non vuoi che succeda, imposta l'opzione che permette comandi non sandboxati su false — mostrata nel pannello come Strict sandbox mode: tutto gira dentro la scatola o è elencato esplicitamente. Per allargare la scatola in modo pulito, l'impostazione allow-write aggiunge percorsi precisi, come .kube per kubectl, invece di escludere l'intero strumento.

Il limite di questo livello è netto: copre solo Bash. I server MCP e gli hook sono processi separati che girano senza vincoli sulla tua macchina. Il sandbox integrato è l'impostazione giusta per il lavoro quotidiano sulla tua macchina, e non basta per una sessione davvero incustodita.

Per lasciare Claude Code libero e incustodito, la documentazione non lascia ambiguità: il flag skip-permissions gira sempre dentro un container, una VM, o il sandbox runtime — mai direttamente sull'host.

Anthropic pubblica un dev container di riferimento nel repository di Claude Code, con uno script firewall che blocca tutto il traffico in uscita tranne i domini consentiti. Aggiungi la feature dev container di Claude Code al tuo devcontainer.json, ricostruisci, e Claude gira dentro la scatola mentre i tuoi file restano nel tuo repository locale. Se non vuoi VS Code nel quadro, Docker Sandboxes fa la stessa cosa in un comando: sbx run claude avvia Claude Code in una micro macchina virtuale con il proprio daemon Docker, filesystem e rete — un prodotto standalone gratuito che non richiede nemmeno Docker Desktop.

Due progetti usciti questa settimana spingono l'idea oltre. OneCLI, un'azienda Y Combinator lanciata su Hacker News, dà a ogni membro del team un proprio agente in sandbox, con un gateway Rust che inietta le credenziali al volo così l'agente non le vede mai in chiaro; i runner sono solo in uscita senza porte in entrata, e il progetto è Apache 2 con già 3.200 stelle. E Simon Willison ha pubblicato uno studio su smolvm, un runtime micro-VM costruito su libkrun:

Misura smolvm	Valore
Cold boot (VM reale, kernel proprio)	577–643 ms
Esecuzione a caldo	48 ms
Test di cap sulla memoria guest	Un'allocazione di 1 GB dentro una VM da 256 MB fallisce lato guest; l'host non è toccato

Non usi smolvm per far girare Claude Code stesso, ma per eseguire il codice che il tuo agente produce, con una cartella di input in sola lettura, una cartella di output, e nessun dispositivo di rete. A questo livello, il bypass smette di essere pericoloso per natura: qualunque cosa esploda, esplode dentro una scatola che puoi buttare via.

Resta un caso che né il sandbox né il container coprono: l'agente che distrugge il lavoro dentro la scatola, come il modello dell'introduzione. Per quello ci sono gli hook, e il più popolare è Destructive Command Guard — un binario Rust collegato come hook PreToolUse su Bash che ispeziona ogni comando in meno di un millisecondo e blocca rm -rf sulla cartella sorgente, un hard reset Git, un Docker prune, o un table drop, con una spiegazione e un'alternativa.

Legge anche heredoc e script inline, quindi un breve script Python con un os.remove non passa inosservato. Puoi testarlo prima di fidartene: la sua modalità test su un comando distruttivo ti dice cosa avrebbe fatto senza eseguire nulla. Il progetto ha 5.800 stelle e si integra nativamente con Claude Code, Codex CLI, Gemini CLI, Cursor e Hermes Agent.

Questo terzo livello protegge il tuo lavoro dall'agente stesso, dove i primi due proteggevano la tua macchina da esso. I tre si sommano, ed è proprio questa somma a rendere ragionevole il YOLO.

L'isolamento ha dei limiti che vale la pena dire chiaramente. Non cambia nulla di ciò che raggiunge il modello: i tuoi prompt e i file che Claude legge vengono inviati all'API con o senza sandbox. Finché un container ha accesso in uscita alla rete, può far trapelare tutto ciò che l'agente può leggere; finché il tuo progetto è montato in scrittura, l'agente può modificarlo, perché quella cartella è direttamente sul tuo disco.

La documentazione del dev container va oltre: con il flag skip-permissions, un progetto malevolo può esfiltrare tutto ciò che è raggiungibile dentro il container, incluse le tue credenziali Claude Code memorizzate in .claude. Quindi non montare mai chiavi SSH o credenziali cloud dentro la scatola, e preferisci token a breve durata e con permessi ristretti. Su Linux, il sandbox runtime costruisce la sua lista di blocco una sola volta all'avvio: un repository che clonini o inizializzi durante la sessione non è coperto. La modalità auto richiede un modello recente, e il sandbox integrato non gira su Windows nativo, solo sotto Windows Subsystem for Linux.

Una scatola limita il danno; non impedisce lo scontro — e la storia dello slopsquatting attraversa ogni livello senza far scattare un solo allarme.

La risposta dipende da cosa l'agente può raggiungere, non dal tuo appetito per il rischio.

Sviluppatore solo sui propri repository, tutti sotto controllo di versione, nessuna chiave di produzione sulla macchina: la modalità auto che hai già più il sandbox integrato in automatic allow bastano — il classifier come giudice, il sistema operativo come muro.

Nel momento in cui c'è un database, un account cloud, o un token che apre sulla produzione: il bypass esiste solo dentro un container con firewall in uscita, credenziali a permessi ristretti, e gate espliciti per deploy, push e migrazioni — gate che l'ambiente rende impossibili da superare invece che affidarsi alla memoria del modello nel chiedere.

Modelli locali da 9B o 27B usati come agenti: il container e la command guard non sono negoziabili, perché quei modelli non hanno né un classifier né il giudizio di un modello di frontiera — e il thread di questa settimana ne è la prova. Il problema non è mai stato l'autonomia dell'agente; è che la esercita con le tue chiavi in tasca.