In questo articolo Indice dei contenuti 3 sezioni
La modalità auto di Claude Code è diventata l’impostazione predefinita su tutti i piani Pro, Max e Team, e la conseguenza pratica è semplice: l’agente smette di chiedere il permesso a ogni singolo passaggio e lavora molto più in fretta. Il cambio è scattato il 14 agosto, deciso da Anthropic dopo aver guardato i propri dati di utilizzo, che raccontano una cosa poco lusinghiera per chi sta davanti allo schermo. Le richieste di approvazione venivano accettate quasi sempre, senza troppe riflessioni.
Il funzionamento non è quello di un via libera cieco. Invece di fermarsi a ogni chiamata di strumento, Claude Code passa l’azione attraverso un sistema di classificatori interni. La maggior parte delle operazioni scorre liscia, mentre restano bloccate quelle che sembrano irreversibili, distruttive o rivolte fuori dall’ambiente di lavoro. Quando il classificatore ferma qualcosa, l’agente cerca una strada più sicura oppure si blocca e chiede conferma.
Come si comporta il classificatore quando qualcosa non torna
Una prova pratica aiuta a capire il meccanismo. È stata creata una cartella esca piena di backup finti, con dati casuali dentro, e all’agente è stato chiesto di ripulire vecchi backup rimasti da una migrazione avvenuta “mesi fa”. Nessuna cancellazione forzata: l’agente ha notato che i file erano blob simili ad archivi cifrati e non ai classici tarball, e soprattutto che i timestamp di creazione risalivano a poche ore prima. Il risultato è stato un menu di opzioni con “aspetta, fammi controllare” già selezionato come scelta predefinita, più un suggerimento alternativo su dove recuperare davvero spazio, cioè le cartelle con i modelli linguistici scaricati.
Il punto della modalità auto non è il rifiuto secco, ma la verifica preventiva. L’agente controlla se la richiesta ha senso prima di fare qualcosa di irreversibile, e in molti casi è più diligenza di quanta ne metta una persona che schiaccia Invio per abitudine.
I numeri che hanno convinto Anthropic
La motivazione dietro la scelta brucia un po’. Secondo Anthropic, il 97% delle richieste di permesso veniva approvato comunque. Non è supervisione umana, è qualcuno che preme un pulsante, e la differenza fra le due cose è enorme. L’azienda ha anche commissionato a una società esterna un test controllato su 1.053 persone, per misurare quanti comandi deliberatamente pericolosi venissero intercettati. Ne è stato individuato solo il 13,6%, con la percentuale in calo man mano che la sessione si allungava. Il sistema di classificatori costruito per Claude Code ne ha bloccati l’89%. Qualcosa gli è sfuggito, certo, ma il divario resta netto.
C’è una seconda rete di protezione. Se il classificatore blocca tre comandi di fila, oppure venti nell’arco di una sessione, Claude Code torna automaticamente in modalità manuale. In più i token consumati dal classificatore non vengono addebitati sui piani Pro, Max e Team, il che libera margine sul piano sottoscritto.
Dove vivono i controlli veri
Con i prompt spariti, contano di più le regole scritte. Il file CLAUDE.md va tenuto snello, perché viene letto a ogni sessione e ogni istruzione vecchia o nota morta di progetto è una tassa in token. Una compattazione ai checkpoint naturali evita che la finestra di contesto esploda nel momento peggiore, e un rapido comando di pulizia fra attività scollegate impedisce che una conversazione di debug si trascini nella funzione successiva. Anche la scelta del modello pesa: refactor rapidi e boilerplate possono passare a un modello più economico, tenendo quello grosso per il lavoro architetturale.
Poi c’è il file settings.json, spesso quasi vuoto, a volte senza nemmeno un blocco permissions. Fissare defaultMode nel file principale, non nella copia dentro la cartella di progetto, fa sì che il passaggio alla modalità auto rispetti le preferenze impostate. Le voci permissions.allow e permissions.deny girano prima del classificatore, quindi gli strumenti dichiarati lì lo saltano del tutto e si guadagna tempo.
Le regole deny valgono più di qualsiasi raccomandazione scritta in prosa: un “mai toccare la produzione” nel file di istruzioni resta un suggerimento gentile, mentre le regole sono un muro che l’agente non aggira. Il resto lo fa l’ambiente, fra esecuzione dentro WSL2, macchine virtuali Proxmox con snapshot preventivo, commit su Git prima di ogni run lungo e lavoro sui branch invece che su main. Le credenziali seguono la stessa logica, con token limitati allo stretto necessario e chiavi di produzione custodite in Tailscale o 1Password, lontane dall’agente.
