Claude Code passa alla modalità automatica

Cosa cambia davvero con la modalità automatica di Claude Code

La modalità automatica sostituisce gran parte dei consueti popup di autorizzazione con una valutazione di sicurezza separata. Prima dell’esecuzione, un classificatore — cioè un modello specializzato nel decidere se un’azione può essere eseguita — confronta le chiamate agli strumenti più rischiose con la richiesta dell’utente e con l’ambiente operativo.

È la soluzione intermedia tra fermarsi a ogni approvazione e rimuovere del tutto i controlli:

La modalità automatica non equivale all’accesso completo. Il controllo resta, ma la prima decisione passa dallo sviluppatore stanco che continua a cliccare “approva” a un classificatore progettato appositamente. È una differenza che pesa soprattutto nelle sessioni di un’ora, quando rispondere alle richieste di autorizzazione tende a diventare un automatismo.

La documentazione attuale di Claude Code indica che la modalità automatica è disponibile con tutti i piani, purché il modello, il provider e le policy dell’organizzazione selezionati la supportino. La modifica del 14 agosto ha un perimetro più ristretto: rende Auto la modalità iniziale delle nuove sessioni Pro, Max e Team. Per Enterprise, API e distribuzioni su cloud di terze parti resta invece necessario attivarla esplicitamente, almeno per ora.

Come viene gestita un’azione in modalità automatica

La maggior parte delle attività in un repository segue uno di questi tre percorsi.

1. Gli strumenti sicuri passano direttamente. Lettura dei file, ricerca, navigazione del codice e altre operazioni integrate di sola lettura possono essere eseguite senza chiamare il classificatore.
2. Le modifiche interne al progetto seguono la corsia rapida locale. Scritture e modifiche nel repository di lavoro proseguono perché possono essere controllate nel sistema di versionamento.
3. Le azioni con conseguenze concrete arrivano al classificatore. Comandi shell, richieste web, integrazioni esterne, avvio di subagent, operazioni sul file system fuori dal progetto e altre attività più rischiose vengono valutati prima dell’esecuzione.

Il classificatore lavora a sua volta in due passaggi. Il primo è un rapido filtro sì/no, ottimizzato per riconoscere i pericoli. Solo le azioni segnalate arrivano a una seconda fase di ragionamento, riducendo così i blocchi superflui. Il meccanismo ricorda un aeroporto: i passeggeri ordinari seguono la corsia normale, uno scanner rapido individua le anomalie e solo quei casi passano a un controllo aggiuntivo.

Una seconda difesa sorveglia ciò che Claude legge. Un sistema lato server contro la prompt injection esamina contenuti dei file, pagine web, output della shell e risposte degli strumenti esterni alla ricerca di istruzioni ostili, prima che il materiale entri nel contesto di Claude. Il classificatore delle azioni riceve poi i messaggi dell’utente e la chiamata allo strumento che Claude intende effettuare, ma non la spiegazione prodotta da Claude né l’output grezzo dello strumento. Questa separazione rende più difficile che una pagina web malevola convinca sia chi esegue il lavoro sia chi lo controlla ad autorizzare la stessa azione dannosa.

Per entrare in modalità automatica si può usare Shift+Tab, selezionare Auto in un’app supportata oppure avviare una sessione da terminale con claude --permission-mode auto. Per renderla l’impostazione predefinita a livello utente prima del 14 agosto, va inserita questa configurazione in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

Claude Code ignora questa impostazione nella configurazione locale del progetto, quindi un repository non può concedersi autonomamente la modalità automatica. Se è già stata scelta un’altra modalità personale predefinita, Anthropic segnala che potrebbe apparire una richiesta una tantum per effettuare il passaggio. Un’impostazione predefinita bloccata, compresa quella gestita da un’organizzazione, rimane invariata.

I risultati sulla sicurezza sono solidi, ma non assoluti

Nel test controllato di Anthropic, la modalità automatica ha superato con ampio margine l’approvazione umana ormai abitudinaria. Tra 1,053 professionisti paganti coinvolti nella prova, le persone hanno fermato 143 comandi pericolosi, pari al 13.6%. La modalità automatica ne ha bloccati 937, cioè l’89%. All’inizio di una sessione gli utenti ne intercettavano circa il 17%, ma dopo 50 o più richieste precedenti la quota scendeva a circa il 5%. Il tasso di blocco della modalità automatica è invece rimasto costante.

Anche i dati di produzione vanno nella stessa direzione. Nelle sessioni segnalate per una verifica di sicurezza, si sono verificati danni involontari gravi nel 6.3% delle sessioni approvate manualmente e nel 2.4% di quelle in modalità automatica. Anthropic riferisce inoltre che gli utenti Team ed Enterprise che adottano Auto producono circa il 25% di pull request in più.

Questi numeri non rendono infallibile il classificatore. In una precedente valutazione della pipeline, Anthropic ha misurato un tasso di falsi negativi del 17% su 52 azioni reali in cui l’agente si era spinto troppo oltre. Un falso negativo è un’azione pericolosa che il classificatore lascia passare. La stessa pipeline ha registrato un tasso di falsi positivi dello 0.4% su 10,000 normali chiamate a strumenti interni e un tasso di falsi negativi del 5.7% su 1,000 tentativi sintetici di esfiltrazione.

Poiché questi set di dati misurano fenomeni diversi, le percentuali non vanno fuse in un unico punteggio. La conclusione operativa è più semplice: la modalità automatica è più sicura di una persona che approva meccanicamente le richieste, ma per le attività ad alto rischio una revisione umana attenta può ancora fare meglio.

Per impostazione predefinita, il classificatore è progettato per fermare deploy e migrazioni in produzione, eliminazioni massive sul cloud, force push, comandi distruttivi sull’infrastruttura, trasferimenti di dati sensibili, modifiche dei permessi e cancellazioni irreversibili di file già esistenti prima della sessione. Dopo tre blocchi consecutivi o venti blocchi nella stessa sessione, Claude Code torna all’approvazione manuale.

Chi ne beneficia di più: sette casi d’uso concreti

I vantaggi maggiori riguardano i team che svolgono attività ripetitive e circoscritte al repository, con test capaci di segnalare a Claude gli errori. La modalità automatica elimina i tempi morti; un compito ristretto, i test e la revisione del codice mantengono il controllo.

1. Team di prodotto che gestiscono grandi cataloghi di pagine

Un team merchandising responsabile di centinaia di pagine localizzate potrebbe assegnare a Claude una modifica ben definita a un componente, lasciargli aggiornare i file interessati, eseguire controlli visivi e unit test, correggere gli errori e preparare una pull request. Il vantaggio non consiste nel saltare la revisione, ma nel ricevere un unico insieme di modifiche completo senza dover sorvegliare ogni intervento sui file e ogni comando. Anthropic descrive un ciclo simile di sviluppo e verifica adottato da Adobe in più di 90 paesi e 30 lingue.

2. Team di piattaforma alle prese con migrazioni del codice

Un platform engineer che deve spostare un monorepo da una libreria deprecata potrebbe chiedere a Claude di trovare ogni utilizzo, applicare la sostituzione documentata, eseguire le suite di test interessate e raggruppare gli errori per causa. È un lavoro ripetitivo, semplice da controllare nel diff e costoso da interrompere. La modalità automatica mantiene in movimento la migrazione, mentre l’ingegnere verifica la patch finale e le eccezioni.

3. Team QA che riparano suite di test non riuscite

Un responsabile QA potrebbe fornire a Claude l’output di una pipeline CI fallita, all’interno di un branch dal perimetro rigoroso, e chiedergli di riprodurre ogni problema, capire se è cambiato il codice o il risultato atteso dal test, correggere la causa più probabile e rieseguire soltanto i controlli pertinenti. Il beneficio è una coda più corta di errori già diagnosticati, non la fiducia cieca in ogni correzione.

4. Squad di prodotto che trasformano specifiche approvate in pull request

Quando una funzionalità dispone di criteri di accettazione chiari, una squadra può lasciare che Claude ricostruisca il percorso nel codice interessato, implementi la modifica, aggiunga i test e scriva il riepilogo della pull request. Spetta comunque alle persone stabilire se il comportamento rispecchia l’intento di prodotto. La modalità automatica elimina soltanto i clic di approvazione tra una fase e l’altra.

5. Team di machine learning che eseguono esperimenti notturni

Alla fine della giornata, un team ML potrebbe mettere in coda un’attività di valutazione ben delimitata e lasciare che Claude modifichi il codice dell’esperimento, esegua le valutazioni approvate, confronti le metriche e restituisca al mattino le pull request candidate. L’ambiente deve essere definito esplicitamente. Cluster condivisi, dati di produzione e ampi diritti di eliminazione devono restare fuori dal perimetro di fiducia, a meno che un amministratore non li configuri intenzionalmente.

6. Team di strumenti interni che smaltiscono la manutenzione arretrata

Un gruppo dedicato agli strumenti interni potrebbe trasformare problemi a basso rischio — aggiornamenti delle dipendenze, correzioni alla validazione dei moduli e piccole modifiche alle dashboard — in branch isolati. Claude può modificare, testare e documentare ogni intervento, mentre una persona mantiene la responsabilità delle priorità e dell’approvazione del merge. È qui che un’esecuzione senza interruzioni trasforma una lunga coda di attività trascurate in lavoro pronto da revisionare.

7. Founder indipendenti che realizzano prototipi in un solo repository

Un founder con un’idea chiara della funzionalità potrebbe lasciare che Claude realizzi una prima versione, avvii l’applicazione in locale, corregga gli errori più evidenti e produca un riepilogo essenziale delle modifiche. Il vantaggio è una sessione di prototipazione coerente, senza decine di richieste di conferma. Il limite è altrettanto evidente: test deboli e un intento di prodotto vago continuano a generare errori dall’aspetto convincente.

Per approfondire il funzionamento di progetti, contesto e revisione, si può consultare Come usare Claude Code. Per chi deve ancora scegliere lo strumento di base anziché la modalità dei permessi, il punto di partenza migliore è il confronto aggiornato tra gli agenti AI per il coding.

Quali prodotti si possono costruire intorno alla modalità automatica

Il passaggio alla nuova impostazione predefinita apre un piccolo mercato software dedicato a rollout, tracciabilità e revisione. L’opportunità più interessante non è creare l’ennesimo agente di coding generalista, ma offrire il livello di controllo che consente a un team di adottare il lavoro autonomo senza dover improvvisare le policy.

1. Una console di rollout per Auto Mode: l’opportunità più solida

Si potrebbe costruire una console per policy e tracciabilità destinata ai team di piattaforma e sicurezza. Il sistema censirebbe repository affidabili, domini interni, bucket cloud, destinazioni di deploy e posizioni dei dati sensibili, quindi genererebbe voci gestite per autoMode.environment, hard_deny, soft_deny e allow, preservando i $defaults di Anthropic.

Tempistica e domanda coincidono. “Claude Code auto mode” totalizza circa 1,900 ricerche Google al mese con una difficoltà keyword pari a 0, mentre “AI powered coding agent” arriva a circa 5,400. Il 14 agosto la funzionalità diventa predefinita per tre piani principali, trasformando un esperimento facoltativo in una questione di governance immediata.

La versione minima vendibile potrebbe importare un’organizzazione GitHub e un breve questionario sull’infrastruttura, produrre un file di configurazione revisionato, eseguire una libreria di azioni sicure e non sicure e raccogliere gli eventi dell’hook PermissionDenied in un’unica dashboard. Il risultato utile è la tracciabilità: che cosa è stato eseguito, che cosa è stato bloccato, quale regola ha determinato la decisione e dove la descrizione dell’ambiente è incompleta.

Il limite è il rischio di piattaforma: Anthropic potrebbe introdurre un’interfaccia di configurazione migliore. Per durare, il prodotto deve offrire policy trasversali agli agenti, cronologia delle approvazioni, revisione delle modifiche e prove per gli audit, non soltanto un generatore JSON più gradevole.

2. Un servizio notturno per preparare pull request

Si potrebbe creare una coda che trasforma ticket di manutenzione ben specificati in pull request isolate e testate. Il cliente ideale è un engineering manager con un arretrato di migrazioni, aggiornamenti delle dipendenze, riparazioni dei test e piccole modifiche di prodotto che non trovano mai spazio durante la giornata.

La domanda è abbastanza ampia da essere rilevante: “AI powered coding agent” riceve circa 5,400 ricerche Google al mese e gli utenti pongono agli assistenti AI domande su “AI coding agent” circa 188 volte al mese. I dati di adozione di Anthropic indicano che chi usa la modalità automatica con Team ed Enterprise produce circa il 25% di pull request in più.

Un MVP potrebbe collegarsi a un issue tracker, creare per ogni ticket un worktree o un container temporaneo, avviare Claude Code in modalità automatica, imporre un comando di test e un limite di tempo, quindi consegnare il branch risultante a un revisore specifico. Una prima nicchia utile potrebbe essere quella degli aggiornamenti di framework o della correzione di test intermittenti, dove il successo è misurabile.

Il limite è la qualità delle attività. Una coda piena di ticket vaghi genera una coda altrettanto piena di pull request plausibili ma sbagliate. Più che prompt sofisticati, il prodotto richiede controlli di accettazione, limiti di spesa, isolamento e un passaggio di consegne chiaro a una persona.

3. Un controllo indipendente delle prove per il codice scritto dagli agenti

Si potrebbe creare un controllo sulle pull request che verifichi il lavoro prodotto da Claude Code e da altri agenti prima che arrivi a un revisore umano. Il cliente è un team in cui la produzione di codice è aumentata più rapidamente della capacità di revisione.

“AI code review” registra circa 1,300 ricerche Google al mese con un CPC di $63.85, mentre “AI powered code review platform” raggiunge circa 1,600 ricerche con una crescita annua del 3,173% in questa rilevazione. I prodotti già presenti dimostrano che esiste un budget: CodeRabbit Pro indica un prezzo di $24 per utente al mese con fatturazione annuale, mentre Greptile Pro costa $30 per postazione al mese.

L’MVP potrebbe essere un’app GitHub che esegue test e controlli statici, collega il diff ai criteri di accettazione, segnala le prove mancanti e pubblica un unico pacchetto di revisione con i comandi eseguiti e i relativi risultati. Dovrebbe verificare la traccia delle prove lasciata dall’agente, non limitarsi a chiedere a un secondo modello se il codice sembra corretto.

Il limite è la concorrenza. Il settore della code review è affollato e Claude dispone già di prodotti per la revisione. Un nuovo operatore ha bisogno di un punto d’ingresso ben definito, come prove di audit per settori regolamentati, provenienza trasversale agli agenti o regole approfondite per un singolo framework.

Limiti e valutazione finale

La modalità automatica risolve la stanchezza da continue interruzioni. Non risolve obiettivi ambigui, test deboli, un’architettura infrastrutturale poco sicura o una cattiva cultura della revisione.

Non va usata come autorità finale per migrazioni in produzione, modifiche dei permessi a livello di account, interventi distruttivi sull’infrastruttura, gestione dei segreti o merge in cui un errore avrebbe un impatto molto ampio. Sono proprio le azioni che le impostazioni predefinite sono progettate per mettere in discussione, e Anthropic continua a raccomandare la revisione umana per i cambiamenti di produzione ad alto rischio.

Anche la configurazione può introdurre rischi. Aggiungere una destinazione affidabile e ben delimitata può eliminare un falso positivo. Sostituire hard_deny, soft_deny o allow senza includere letteralmente $defaults, invece, elimina l’elenco integrato di Anthropic per quella sezione. I team dovrebbero esaminare la policy effettiva con claude auto-mode config e possono usare autoMode.classifyAllShell: true quando ogni comando shell deve essere sottoposto al classificatore.

La mia valutazione: la modalità automatica è l’impostazione predefinita giusta per attività software circoscritte, perché le richieste manuali di autorizzazione sono ormai diventate un rituale. Il modello operativo responsabile combina esecuzione automatica in un ambiente ristretto, test oggettivi durante il lavoro e giudizio umano nel punto in cui il codice raggiunge clienti o infrastruttura.

Per realizzare un flusso di lavoro controllato basato su agenti per il proprio team di sviluppo, il punto di partenza è lo sviluppo di agenti AI.