Claude Code: modalità automatica predefinita dal 14 agosto

Cosa cambia con la modalità automatica il 14 agosto 2026

La modalità automatica di Claude Code esegue le chiamate agli strumenti senza interrompersi per chiedere conferma e invia prima ogni azione a un modello classificatore separato per la revisione. Dal 14 agosto 2026 sarà la modalità predefinita per le nuove sessioni nei piani Pro, Max e Team. Puoi cambiare modalità in qualsiasi momento e un'impostazione predefinita che hai già configurato non viene sovrascritta.

La documentazione descrive il cambiamento in questo modo:

A partire dal 14 agosto 2026, la modalità automatica diventa la modalità di autorizzazione predefinita per le nuove sessioni nei piani Pro, Max e Team. Puoi cambiare modalità in qualsiasi momento. Un'impostazione predefinita configurata da te rimane attiva, a meno che tu non accetti la richiesta di passaggio visualizzata una sola volta; un'impostazione predefinita gestita dalla tua organizzazione non cambia.

Due clausole sono più importanti della data. Un defaultMode configurato nel tuo file delle impostazioni personali rimane attivo dopo il cambiamento. Anche un'impostazione predefinita distribuita dalla tua organizzazione tramite impostazioni gestite rimane invariata. Il post dell'annuncio aggiunge che la modalità automatica resta facoltativa per i piani Enterprise e per gli account che usano l'API durante la prima fase del rilascio.

Se esegui Claude Code su un VPS (virtual private server), conviene leggere il cambiamento prima che venga applicato. Una richiesta di autorizzazione è un punto di controllo che richiede una persona davanti alla tastiera. Su un sistema remoto spesso non sei presente, quindi la modalità con cui una sessione viene avviata è quella che rimane attiva per ore.

Le modalità di autorizzazione di Claude Code, dal maggior livello di supervisione al minore

Esistono sei modalità. Il nome all'inizio di ogni riga è il valore da inserire nelle impostazioni o da passare a --permission-mode.

• default: Claude chiede conferma prima di ogni nuovo utilizzo di uno strumento. Le letture all'interno della directory di lavoro vengono comunque eseguite senza richiesta di conferma. La CLI (interfaccia a riga di comando) identifica questa modalità come Manual e accetta manual come alias a partire da Claude Code v2.1.200.
• plan: Claude legge i file ed esegue comandi per esplorare l'ambiente, senza modificare il codice sorgente. Le modifiche restano bloccate finché non approvi il piano.
• acceptEdits: le modifiche ai file vengono eseguite senza richiesta di conferma, insieme ai comandi del filesystem mkdir, touch, rm, rmdir, mv, cp e sed. Questo vale soltanto per i percorsi all'interno della directory di lavoro o di additionalDirectories. Per qualsiasi altro comando della shell viene comunque richiesta conferma.
• auto: tutto viene eseguito, dopo che il classifier ha verificato ogni azione. Le regole esplicite ask impongono comunque una richiesta di conferma.
• dontAsk: Claude Code rifiuta automaticamente qualsiasi operazione che avrebbe richiesto una conferma. Vengono eseguiti soltanto i comandi consentiti dalle regole allow, dai comandi Bash integrati in sola lettura e dalle chiamate approvate da un hook PreToolUse. La sessione non attende mai input.
• bypassPermissions: le richieste di conferma e i controlli di sicurezza vengono ignorati, comprese le scritture in percorsi protetti come .git e .claude.

Durante una sessione, premi Shift+Tab per passare ciclicamente da default a acceptEdits e quindi a plan. La barra di stato mostra la modalità selezionata, ad esempio ⏵⏵ auto mode on o una voce ⏸ manual mode on in grigio. Per impostazione predefinita, le altre modalità non fanno parte di questo ciclo. auto viene aggiunta quando il tuo account soddisfa i requisiti necessari. bypassPermissions viene aggiunta soltanto se la sessione è stata avviata con --permission-mode bypassPermissions o --dangerously-skip-permissions. dontAsk non compare mai nel ciclo; per impostarla, usa claude --permission-mode dontAsk.

La modalità automatica richiede inoltre un modello recente. Questo è il motivo più comune per cui non compare affatto. Ad agosto 2026 la documentazione elenca Claude Opus 4.6 o versioni successive, Sonnet 4.6 o versioni successive e Fable 5 sull'Anthropic API; specifica inoltre che i modelli meno recenti, come Sonnet 4.5, non sono supportati da alcun provider. Se Claude Code segnala che la modalità automatica non è disponibile, significa che uno di questi requisiti non è soddisfatto. Non si tratta di un'interruzione temporanea del servizio, quindi attendere non risolverà il problema.

Due controlli si applicano in ogni modalità, inclusa bypassPermissions: le regole deny e le regole esplicite ask. Sono i controlli che restano disponibili indipendentemente dalla modalità con cui viene avviata una sessione.

Cosa blocca il classificatore della modalità automatica

Il classificatore è un secondo modello che legge l'azione in attesa ed esamina se è coerente con ciò che hai richiesto. La documentazione ne descrive il compito in una frase:

Un modello classificatore separato esamina le azioni prima della loro esecuzione e blocca quelle che vanno oltre la richiesta, interessano infrastrutture non riconosciute o sembrano causate da contenuti ostili letti da Claude.

Per impostazione predefinita vengono bloccate le azioni che un amministratore di server incontra più spesso:

• Download ed esecuzione di codice, ad esempio curl | bash
• Deploy e migrazioni in produzione
• Force push
• Modifica dell'infrastruttura condivisa
• Apertura di un tunnel o di una reverse shell che rende un servizio locale raggiungibile da Internet pubblico
• Stampa di una credenziale o di un token attivo nel transcript o in un file

Per impostazione predefinita sono consentite:

• Operazioni sui file locali nella directory di lavoro
• Installazione delle dipendenze dichiarate nei lock file o nei manifest
• Richieste HTTP in sola lettura
• Push verso qualsiasi branch del repository in cui stai lavorando

Non basarti su un riepilogo come quello precedente. Esegui claude auto-mode defaults per stampare l'elenco completo delle regole in formato JSON e leggi quello fornito con la versione installata.

Prima di affidarti a questo meccanismo, considera due limiti documentati. Innanzitutto, il classificatore vede i tuoi messaggi, le chiamate agli strumenti e il contenuto CLAUDE.md, mentre i risultati degli strumenti vengono rimossi; di conseguenza, il testo contenuto in un file o in una pagina web letta da Claude non può rivolgersi direttamente al classificatore. Inoltre, quando il classificatore blocca un'azione 3 volte consecutive o 20 volte nella stessa sessione, la modalità automatica viene sospesa e Claude Code torna a chiederti conferma. Queste soglie non sono configurabili. Nella modalità non interattiva con il flag -p non c'è nessuno a cui chiedere conferma, quindi i blocchi ripetuti interrompono invece la sessione.

È questo il comportamento che crea problemi su un sistema remoto. Un'esecuzione automatica che raggiunge il limite si interrompe e attende una persona che non sta osservando il terminale. Limitare le attività che l'agente deve eseguire è l'altra parte della soluzione; una skill che indirizza l'agente verso la modifica minima necessaria impedisce alla sessione di estendersi alle azioni troppo ampie che il classificatore blocca.

Dove sono definite le modalità in settings.json

Tutto quanto descritto sopra è un unico oggetto in un file di impostazioni.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Le regole vengono valutate nell’ordine seguente: deny, poi ask, infine allow. La prima corrispondenza in questo ordine determina l’esito; una regola più specifica non prevale su una regola più generale che compare prima. Una regola deny per Bash(aws *) blocca aws s3 ls anche se hai consentito esplicitamente quel comando. Una regola deny non può quindi avere eccezioni.

ask è il tipo di regola che dimostra la sua utilità nella modalità auto. La modalità auto elimina la richiesta di conferma ordinaria, mentre una regola ask la reintroduce per il comando specifico che vuoi sottoporre all’approvazione di una persona. Il comando di deploy va inserito in questa categoria. Lo stesso vale per Bash(git push *) se vuoi un controllo prima che il codice lasci il server. Conservare i file delle credenziali in deny completa questa configurazione e si integra con tenere le credenziali fuori dalla portata dell’agent fin dall’inizio.

I file di impostazioni stessi, dal livello di precedenza più basso a quello più alto:

• ~/.claude/settings.json: le impostazioni dell’utente, applicate a ogni progetto.
• .claude/settings.json: le impostazioni del progetto, salvate nel repository.
• .claude/settings.local.json: le tue impostazioni per un singolo repository, escluse da git tramite git-ignored.
• Impostazioni gestite, distribuite da un amministratore. Su Linux, il file è /etc/claude-code/managed-settings.json. Nessun elemento può sovrascrivere una regola di autorizzazione gestita, incluso un flag della riga di comando.

Qui c’è un caso particolare con una causa documentata. defaultMode: "auto" viene ignorato quando proviene da .claude/settings.json o .claude/settings.local.json, a partire da Claude Code v2.1.142, in modo che un repository non possa abilitare autonomamente la modalità auto distribuendo un file di impostazioni. Se lo imposti in quel file, la sessione viene avviata in modalità default senza stampare alcun errore. Sposta la riga in ~/.claude/settings.json. Esegui /permissions per elencare ogni regola attiva insieme al file da cui proviene.

I due switch che disattivano una modalità

Gli amministratori hanno a disposizione due interruttori di emergenza. Entrambi richiedono la stringa "disable", non un valore booleano.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

La documentazione specifica con precisione dove inserirli:

Per impedire l'uso della modalità bypassPermissions o auto, impostare permissions.disableBypassPermissionsMode o permissions.disableAutoMode su "disable" in un qualsiasi file delle impostazioni. Sono particolarmente utili nelle impostazioni gestite, dove non possono essere sovrascritti.

disableAutoMode rimuove auto dal ciclo Shift+Tab e rifiuta --permission-mode auto all'avvio. disableBypassPermissionsMode svolge la stessa funzione per la modalità bypass e opera da qualsiasi ambito. È quindi possibile impostarlo nel proprio ~/.claude/settings.json per impedirsi di accedere a una modalità che si preferirebbe non attivare alle 2 di notte su un server in produzione. Su un sistema utilizzato da altre persone, inserire invece entrambi in /etc/claude-code/managed-settings.json, perché il file delle impostazioni dell'utente appartiene all'utente, mentre quello gestito no.

Perché la modalità automatica su un VPS richiede un confine di isolamento

Il classificatore valuta un'azione alla volta. Non limita ciò che un'azione approvata esegue in seguito. La documentazione è chiara:

Il classificatore è un controllo per singola azione, non un confine di isolamento. Un confine di isolamento aggiunge quindi un ulteriore livello di difesa per le esecuzioni non presidiate e non è richiesto come lo è per --dangerously-skip-permissions.

Su un sistema remoto, quindi, l'approccio corretto è usare la modalità automatica insieme a un ambiente che si è disposti a perdere, non bypassPermissions e la speranza. La modalità bypass è documentata soltanto per gli ambienti isolati: container, macchine virtuali o dev container senza accesso a Internet, nei quali Claude Code non può danneggiare il sistema host. Un VPS che esegue il database e il reverse proxy non rientra in nessuna di queste categorie.

Su un server, tre misure sono le più importanti. Eseguire Claude Code come utente normale, mai come root. Assegnare a questo utente una directory di lavoro e nessun altro contenuto che valga la pena leggere. Ricreare il sistema invece di ripararlo: questo è il motivo per usare una VM temporanea da eliminare dopo ogni job. I dettagli dell'hardening, dalla creazione dell'utente alle regole del firewall, sono descritti in la procedura completa per eseguire Claude Code in sicurezza su un VPS e non vengono ripetuti qui.

Claude Code applica direttamente la regola relativa a root. Su Linux e macOS rifiuta di avviarsi in modalità bypass con sudo o come root:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Il controllo viene ignorato all'interno di una sandbox riconosciuta. Per questo, per il lavoro autonomo in un container, la documentazione indica un dev container che esegue Claude Code come utente non root. Se si controlla l'agente da un telefono o da un laptop tramite SSH, lo stesso ragionamento vale per una sessione di Claude Code mantenuta attiva in tmux: durante l'esecuzione della sessione, nessuno controlla il prompt.

Configurare la sandbox Bash su un VPS Ubuntu

La sandbox integrata limita l'accesso al filesystem e alla rete di ogni comando Bash eseguito da Claude, e il sistema operativo applica le stesse restrizioni anche ai processi figli. Su Linux sono necessari 2 pacchetti.

sudo apt-get install bubblewrap socat

Avvia Claude Code ed esegui /sandbox. Si apre il pannello con una scheda Mode e una scheda Overrides, oltre a una scheda Dependencies che elenca gli elementi mancanti. Il controllo delle dipendenze viene eseguito all'avvio. Dopo aver installato i pacchetti, riavvia Claude Code; in caso contrario il pannello continuerà a indicarli come assenti.

Su Ubuntu 24.04 e versioni successive, il criterio AppArmor predefinito impedisce a bubblewrap di creare gli user namespace necessari. Di conseguenza, la sandbox non si avvia. Verifica se questo vale anche per il tuo server:

sysctl kernel.apparmor_restrict_unprivileged_userns

Un 0, oppure un errore che indica che la chiave non esiste, significa che non devi eseguire altre operazioni. Un 1 significa che bwrap richiede un profilo dedicato:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

Il profilo si applica direttamente a bwrap, non ai comandi che esegue all'interno della sandbox. Ora restringi il perimetro nelle impostazioni:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Questo blocco deve essere inserito nel file .claude/settings.json del progetto, perché . viene risolto nella directory root del progetto soltanto nelle impostazioni del progetto. Inserisci le stesse righe in ~/.claude/settings.json: in questo caso . viene risolto in ~/.claude, quindi la regola denyRead continua a impedire l'accesso ai file del progetto e ogni comando non riesce a leggere il codice che dovrebbe modificare.

È importante sapere cosa non viene coperto. La sandbox limita Bash e i relativi processi figli. Gli strumenti integrati per i file vengono eseguiti all'interno del processo Claude Code, mentre i server MCP (model context protocol) e gli hook sono processi separati che vengono eseguiti senza restrizioni sull'host. Per collocarli tutti dietro un unico perimetro, esegui l'intero processo Claude Code all'interno di un container, una macchina virtuale oppure del pacchetto @anthropic-ai/sandbox-runtime, che al momento della redazione è un'anteprima di ricerca beta.

Quale modalità è adatta a ciascuna configurazione?

Un singolo repository sul proprio laptop

Usare auto, con regole ask per le azioni che si desidera controllare prima dell'esecuzione. Si lavora direttamente dalla tastiera, il fallback del classificatore può raggiungere l'utente e i danni sono limitati a una macchina sotto il proprio controllo. È il caso per cui è stato definito il comportamento predefinito del 14 August.

Un VPS condiviso

Usare auto per ogni utente, configurandolo nel rispettivo ~/.claude/settings.json, su una macchina in cui l'account che esegue Claude Code non è root e non può leggere il lavoro degli altri utenti. Distribuire disableBypassPermissionsMode come "disable" in /etc/claude-code/managed-settings.json, insieme alle regole di negazione che proteggono i percorsi condivisi. Una macchina condivisa è il caso più evidente in cui bypassPermissions è errato, perché il confine di isolamento presupposto da quella modalità non esiste: gli altri tenant si trovano al suo interno.

CI e sessioni non interattive

Usare dontAsk con un elenco allow esplicito dei comandi necessari al job. Il rifiuto automatico è il comportamento corretto in caso di errore quando nessuna persona vedrà mai una richiesta di conferma. La modalità automatica funziona anche in modo non interattivo, ma i blocchi ripetuti del classificatore interrompono una sessione -p. Di conseguenza, un job che li incontra fallisce a metà, lasciando il lavoro parzialmente eseguito. Mantenere bypassPermissions per un container o una macchina virtuale ricostruiti da un'immagine, e non usarlo su host che eseguono anche componenti importanti.

FAQ

Quando la modalità automatica diventa quella predefinita in Claude Code?

Dal 14 agosto 2026, per le nuove sessioni nei piani Pro, Max e Team. La documentazione specifica che è possibile cambiare modalità in qualsiasi momento, che un'impostazione predefinita configurata manualmente rimane attiva salvo accettare la richiesta di passaggio una tantum e che un'impostazione predefinita gestita dall'organizzazione non cambia. L'annuncio precisa che la modalità automatica resta facoltativa per i piani Enterprise e per gli account che usano l'API durante la prima fase del rilascio. Per verificare la modalità effettiva della sessione, controllare la barra di stato, che in modalità automatica mostra ⏵⏵ auto mode on.

Devo usare la modalità automatica o bypassPermissions su un VPS?

La modalità automatica, abbinata a un confine di isolamento. Il classificatore esamina ogni azione prima dell'esecuzione, ma la documentazione chiarisce che si tratta di un controllo per singola azione e non di un confine di isolamento. Anche un'esecuzione senza supervisione richiede quindi un container, una macchina virtuale o un sistema che si sia disposti a ricreare. bypassPermissions salta completamente i controlli ed è documentato solo per gli ambienti isolati. Su Linux, Claude Code rifiuta di avviarsi in questa modalità come root e visualizza --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

Come impedisco a chiunque sul mio server di usare la modalità automatica o la modalità bypass?

Impostare permissions.disableAutoMode e permissions.disableBypassPermissionsMode sulla stringa "disable" in /etc/claude-code/managed-settings.json. Le impostazioni gestite hanno priorità su tutti gli altri ambiti. Nessun file di impostazioni dell'utente e nessun flag della riga di comando può quindi sovrascriverle. disableAutoMode rimuove auto dal ciclo Shift+Tab e rifiuta --permission-mode auto all'avvio. Anche disableBypassPermissionsMode funziona da qualsiasi ambito, quindi un singolo utente può impostarlo nel proprio ~/.claude/settings.json.

Perché l'impostazione defaultMode: "auto" viene ignorata?

Perché si trova nel file errato. A partire da Claude Code v2.1.142, defaultMode: "auto" viene ignorato quando proviene da .claude/settings.json o .claude/settings.local.json. In questo modo un repository non può concedersi la modalità automatica distribuendo un file di impostazioni. La sessione viene avviata in modalità default e non visualizza alcun errore. Spostare l'impostazione in ~/.claude/settings.json, quindi eseguire /permissions per verificare da quale file proviene ogni regola attiva. Se la modalità automatica non è ancora disponibile, controllare il requisito relativo al modello: i modelli meno recenti, come Sonnet 4.5, non sono supportati da alcun provider.