AIREITERDal 22 ottobre Anthropic ha iniziato a preparare il passaggio alla modalità automatica come impostazione predefinita per le nuove sessioni nella maggior parte delle app Claude, sui piani Pro, Max e Team. Gli amministratori Enterprise ricevono prima una comunicazione via email, mentre API e piattaforme cloud restano per ora in modalità opt-in.
Cosa cambia dal 22 ottobre e cosa resta invariato
L’aggiornamento del 22 ottobre estende alla maggior parte delle app Claude una modifica già introdotta in Claude Code. Dal 14 agosto 2026, le nuove sessioni di Claude Code sui piani Pro, Max e Team partono in modalità automatica, mostrando una sola richiesta di conferma agli utenti che avevano fissato un’impostazione predefinita diversa. La nota del 22 ottobre, pubblicata nello stesso annuncio di Anthropic, specifica che la modalità automatica diventerà predefinita la settimana successiva per le nuove sessioni nella maggior parte delle app Claude, mentre gli amministratori Enterprise verranno avvisati via email prima del cambio nelle rispettive organizzazioni.
I confini principali, però, non cambiano. Gli amministratori Team che hanno fissato una modalità nelle impostazioni gestite non vedranno variazioni per i propri utenti. Enterprise, Claude API, Claude Platform su AWS, Amazon Bedrock, Google Cloud's Agent Platform e Microsoft Foundry restano in opt-in, con l’obiettivo di rendere predefinita la modalità automatica anche lì nel corso del mese successivo. Anche le impostazioni personali già fissate rimangono attive, a meno che l’utente non accetti la richiesta di passaggio mostrata una sola volta.
Anche la versione installata conta. Secondo il monitoraggio delle note di rilascio, Claude Code v2.1.283 e successive indicano la modalità automatica come modalità iniziale integrata per le sessioni interattive da terminale e VS Code, quando non è configurata una modalità di autorizzazione. Una nuova installazione può comunque partire in modalità manuale al primo avvio se i flag delle funzionalità non sono ancora arrivati.
Come decide Claude in modalità automatica
In modalità automatica, ogni chiamata agli strumenti passa attraverso un classificatore separato invece di richiedere l’approvazione a ogni singolo passaggio, come spiega Anthropic nel suo annuncio. Il classificatore autorizza le operazioni di routine e blocca quelle ritenute irreversibili, distruttive o dirette al di fuori dell’ambiente di lavoro; Claude prova quindi a trovare una strada più sicura oppure chiede conferma direttamente. Dopo tre blocchi consecutivi o venti blocchi complessivi nella stessa sessione, il sistema torna alle approvazioni manuali.
Le regole di autorizzazione esplicite vengono comunque applicate prima del classificatore. Le voci in permissions.deny bloccano l’azione senza eccezioni e nessun verdetto del classificatore può sovrascriverle, mentre quelle in permissions.ask richiedono sempre una conferma. Le regole allow molto ampie che concedono l’esecuzione arbitraria di codice, come Bash(python:*), vengono messe da parte quando la modalità automatica è attiva, così i comandi non possono aggirare completamente il classificatore.
Il classificatore considera più contesto rispetto a una semplice allowlist. Anthropic spiega che, prima di eseguire un’operazione, verifica la destinazione di un push Git o di una pull request — privata, attendibile o pubblica — e controlla lo stato corrente di Git prima di comandi distruttivi come git reset --hard.
I contenuti esterni provenienti da pagine web, file o output degli strumenti passano attraverso un controllo contro i prompt injection. Quando qualcosa sembra un tentativo di iniezione, Claude aggiunge un avviso al proprio contesto. L’esfiltrazione dei dati rientra invece nella categoria del blocco rigido e non viene approvata automaticamente: per eseguire un’azione simile bisogna cambiare modalità o lanciare direttamente il comando.
Perché Anthropic preferisce l’automazione ai clic su “Approva”
Anthropic presenta il cambiamento come una scelta di ergonomia supportata dai dati. In Claude Code gli utenti approvano il 97% delle richieste di autorizzazione, ma rifiutano il 39% dei piani presentati: secondo l’azienda, questa differenza indica che molti clic sulle singole richieste sono automatici più che frutto di una vera revisione. A giugno 2026, il 49,5% degli utenti CLI attivi aveva scritto a mano una regola allow per Bash, il 62% aveva usato bypassPermissions o "don't ask again" e il 25% delle sessioni interattive era partito in modalità bypass.
Lo studio controllato ha quantificato questo comportamento. Anthropic ha coinvolto 1.053 tester paganti tramite un fornitore di servizi di ricerca, sostituendo una richiesta di autorizzazione per sessione con un comando chiaramente pericoloso e registrando la risposta; il testo pericoloso non eseguiva alcuna operazione. Gli esseri umani hanno individuato il comando nel 13,6% dei casi (143 su 1.053), mentre la modalità automatica ha bloccato l’89% degli stessi comandi (937 su 1.053).
Nel confronto diretto, la modalità automatica ha bloccato 800 comandi che gli utenti avevano approvato, mentre gli utenti ne hanno bloccati soltanto 6 lasciati passare dalla modalità automatica. Inoltre, la percentuale di rilevamento umano è scesa da circa il 17% all’inizio a circa il 5% dopo 50 o più richieste precedenti, mentre quella della modalità automatica è rimasta stabile.
Anche i dati di produzione e quelli di terze parti vanno nella stessa direzione, secondo l’annuncio di Anthropic. Tra le sessioni segnalate da maggio a giugno 2026, il 6,3% di quelle approvate manualmente conteneva un danno a livello di produzione non richiesto esplicitamente dall’utente, contro il 2,4% delle sessioni in modalità automatica. Trajectory Labs ha eseguito 72 scenari di prompt injection dieci volte ciascuno: nessuno dei 720 tentativi è riuscito contro Claude Fable 5, Opus 5 o Sonnet 5 in modalità automatica, mentre contro GPT-5.6 Sol in modalità Codex Auto-review il tasso di successo è stato del 5,83%.
Il red teaming di Apollo Research ha ridotto dal 12% al 7% il tasso di errori del classificatore, dopo averlo rafforzato con regole sulla visibilità del repository, sullo stato Git e sulla gestione dei dati. Anthropic cita inoltre tre casi interni evitati — un fallback per l’upload fuori rete verso un sito pubblico di paste, l’eliminazione massiva di processi su circa 2.000 pod che avrebbe messo a rischio i job di addestramento GPU e un’escalation troppo ampia dei ruoli di fatturazione — oltre a circa il 25% di pull request in più tra gli adottanti Teams ed Enterprise, tra cui Adobe, Nuro, Gusto e Garner Health.
Cosa succede davvero dopo il passaggio
Le discussioni degli utenti aggiungono alcuni problemi pratici che l’annuncio tende a lasciare in secondo piano. Le lamentele riguardano soprattutto le operazioni di routine: commit, pulizia dei worktree, attività via SSH e sui server, oltre ai comandi di deployment che in modalità automatica vengono bloccati o sottoposti nuovamente a richiesta di conferma.
"il classificatore automatico chiede il permesso anche per le operazioni più basilari e continua a non eseguirle nemmeno dopo aver ricevuto un’autorizzazione esplicita." — u/dfritter4 su r/ClaudeCode
Il punto più fastidioso è che un’approvazione non annulla necessariamente un rifiuto. Diversi utenti raccontano di aver approvato un’azione per poi vedersela comunque negare dall’ambiente di esecuzione, con il risultato di dover passare alla modalità manuale o al terminale.
"Mi è capitato di dover tornare alla modalità manuale, dire all’agente di continuare, approvare manualmente e poi ritornare alla modalità automatica." — u/phoenixmatrix su r/ClaudeCode
I malfunzionamenti del classificatore sono un problema distinto dai blocchi di sicurezza. Durante un incidente che ha coinvolto più progetti, gli utenti hanno visto il messaggio "The server-side auto mode classifier gave no verdict" su diversi progetti, mentre la pagina di stato non segnalava incidenti. Il rimedio è stato passare alla modalità manuale fino al ripristino del servizio.
Tra le preoccupazioni compare anche la qualità del lavoro, discussa nel thread sul rollout predefinito. Per alcuni il problema non sono tanto i comandi distruttivi, quanto la tendenza di Claude a complicare eccessivamente le soluzioni, allargare il perimetro o adottare un’architettura debole quando lavora in autonomia. Le frizioni ripetute spingono una minoranza a tornare verso --dangerously-skip-permissions, affidandosi soltanto a Git, container e revisione prima del merge.
Come mantenere i checkpoint senza abbandonare Claude Auto Mode
La scelta predefinita che sorprende di più gli sviluppatori è che, in modalità automatica, push e creazione di pull request sono consentiti, compresi i push sul branch di lavoro e su quello predefinito. I force push, i segreti presenti nei commit e le riscritture della cronologia restano bloccati in modo reversibile e richiedono un’intenzione esplicita. Dire "ripulisci il repository" non autorizza un force push, mentre indicare esattamente l’azione sì. I branch che identificano destinazioni di deploy, come production, release o gh-pages, vengono valutati autonomamente come deployment in produzione.
Per usare la modalità automatica su tutto tranne push e pull request, aggiungi regole ask limitate al contenuto, che vengono valutate prima del classificatore:
{ "permissions": { "ask": ["Bash(git push *)", "Bash(gh pr create *)"] } }Quando un confine non deve essere oltrepassato, usa permissions.deny invece di affidarti alle istruzioni nella chat. Un messaggio come "non fare push finché non ho revisionato" può sparire quando il contesto viene compattato, mentre una regola ask o deny resta attiva. Se un certo ambiente continua a essere rifiutato, di solito significa che il classificatore non riconosce l’infrastruttura: indicarla in autoMode.environment nelle impostazioni personali o gestite può aiutare.
Puoi rivedere i rifiuti nella scheda Recently denied di /permissions e premere r per riprovare un’azione. Per controllare la configurazione usa claude auto-mode config, claude auto-mode defaults e claude auto-mode critique. Attenzione a due dettagli: regole allow ristrette come Bash(npm test) vengono risolte prima del classificatore e possono lasciare passare un argomento distruttivo senza controllo; su v2.1.193 o successive puoi impostare autoMode.classifyAllShell su true per classificare ogni comando shell, pagando un certo costo in latenza. Inoltre, gli elenchi personalizzati allow, soft_deny, hard_deny o environment sostituiscono interamente quelli integrati, a meno che non contengano la voce letterale "$defaults".
Come disattivarla quando serve
Passare da una modalità all’altra durante una sessione richiede un solo gesto. Premi Shift+Tab nella CLI per scorrere le modalità, usa il menu della modalità nell’app desktop oppure avvia una sessione con claude --permission-mode manual. La modifica vale soltanto per la sessione corrente.
Per fissare definitivamente la modalità manuale, salva l’impostazione predefinita nelle impostazioni utente in ~/.claude/settings.json:
{ "permissions": { "defaultMode": "manual" } }Su v2.1.200 e successive, il valore manual è un alias di default. Il file .claude/settings.json a livello di repository non può concedere né fissare la modalità automatica: defaultMode: auto e bypassPermissions inseriti lì vengono ignorati. La scelta di attivare o disattivare la modalità automatica va quindi fatta nelle impostazioni utente o gestite. Gli amministratori dell’organizzazione possono fissare il valore predefinito con defaultMode nelle impostazioni gestite oppure rimuovere del tutto la modalità automatica impostando permissions.disableAutoMode su "disable"; dalla v2.1.251, questa scelta vale anche per le sessioni già in esecuzione. Quando useAutoModeDuringPlan è attivo, il classificatore della modalità automatica controlla anche i comandi shell durante la modalità plan, che è l’impostazione predefinita nei contesti in cui la modalità automatica è disponibile.
Meglio lasciarla attiva o fissare la modalità manuale?
La scelta va rapportata all’impatto potenziale delle operazioni, non all’entusiasmo per la nuova funzione. La modalità automatica è adatta a esperimenti individuali, refactoring locali isolati, aggiornamenti delle dipendenze, generazione di test e pulizia della documentazione, purché diff e test suite restino il filtro finale. Nei repository condivisi serve una condizione in più: percorsi protetti, blocchi rigidi per segreti e manifest di deployment, oltre a sandbox o branch temporanei concordati prima dell’adozione.
| Flusso di lavoro | Modalità consigliata | Prima protezione da impostare |
|---|---|---|
| Esplorazione individuale, modifiche reversibili | Modalità automatica | Revisione di Recently denied + abitudine a riprovare con r |
| Repository di team, sviluppo ordinario di funzionalità | Modalità automatica con checkpoint sui push | ask su git push * e gh pr create * |
| Deployment in produzione, IAM, segreti, risposta agli incidenti | Modalità manuale o plan + revisione umana del diff | Regole deny per i confini da non oltrepassare |
| Sessioni regolamentate o idonee HIPAA | Manuale (la modalità automatica resta disponibile per il passaggio) | defaultMode gestito + controllo di chi può modificarlo |
Aggiorna CLI e integrazioni con gli editor seguendo la stessa versione, imposta un unico valore predefinito gestito, definisci percorsi protetti e blocchi rigidi, esegui i primi test in devcontainer o VM isolate con dati fittizi e mantieni git diff, esecuzione dei test e revisione reale come passaggi obbligatori prima del merge. Secondo Anthropic, circa il 10% delle sessioni dalla metà di maggio include un rifiuto del classificatore.
FAQ
Claude Auto Mode consuma token aggiuntivi?
No: sui piani Pro, Max e Team non ci sono costi aggiuntivi, secondo Anthropic con decorrenza 7 agosto 2026. Le sessioni Enterprise, API e sulle piattaforme cloud conteggiano invece le chiamate al classificatore lato client nel consumo di token.
Cosa devo fare se la modalità automatica blocca un’operazione legittima?
Apri /permissions, controlla la scheda Recently denied e premi r per riprovare l’azione rifiutata. Se la stessa destinazione continua a essere bloccata, indicala in autoMode.environment tra le infrastrutture attendibili.
Perché un push su main è passato senza richiesta di conferma?
In modalità automatica i push verso qualsiasi branch del repository di lavoro, compreso quello predefinito, sono consentiti di default. Aggiungi Bash(git push *) a permissions.ask per imporre un checkpoint, oppure a permissions.deny per creare un blocco rigido.
La modalità automatica è sicura per il lavoro in produzione?
Anthropic la considera più sicura del clic automatico sulle richieste, ma raccomanda comunque una revisione umana per le modifiche ad alto impatto sull’infrastruttura di produzione. Mantieni la modalità automatica per il lavoro reversibile e usa la modalità manuale o plan per deployment, segreti e IAM.
Come distinguo un rifiuto di sicurezza da un problema del classificatore?
Un rifiuto di sicurezza indica il motivo del blocco e Claude di solito propone un’alternativa; un errore "no verdict" blocca contemporaneamente operazioni di scrittura e comandi Bash su più progetti. Controlla la riga del server della modalità automatica con /status e, se sospetti un’interruzione, prova la modalità manuale.
La modalità automatica funziona allo stesso modo in Claude Code e nelle app Claude?
Il meccanismo del classificatore è condiviso, ma i tempi di rollout sono diversi: Claude Code è passato per primo il 14 agosto, le app Claude lo seguiranno la settimana successiva, mentre le superfici Enterprise e API restano in opt-in finché gli amministratori non vengono avvisati.
Letture correlate: guida alla modalità automatica di OpenAI Codex