Claude Code: la modalità automatica è il nuovo default

Cosa cambia con la modalità automatica il 14 agosto 2026

La modalità automatica di Claude Code esegue le chiamate agli strumenti senza interrompersi per chiederti conferma e invia prima ogni azione a un modello classificatore separato per la revisione. Dal 14 agosto 2026 è diventata la modalità con cui iniziano le nuove sessioni nei piani Pro, Max e Team. Dall'11 ottobre 2026 la documentazione è ancora più esplicita: con Claude Code v2.1.283 o versioni successive, la modalità automatica è la modalità iniziale integrata per le sessioni interattive nel terminale e in VS Code, su ogni piano e provider. Puoi cambiare modalità in qualsiasi momento e un'impostazione predefinita che avevi già configurato per il tuo account non viene sovrascritta.

La documentazione descrive ora il cambiamento in questo modo:

Con Claude Code v2.1.283 o versioni successive, la modalità automatica è la modalità iniziale integrata per le sessioni interattive nel terminale e in VS Code. Nelle versioni precedenti, è la modalità iniziale integrata soltanto nei piani Pro, Max e Team.

Nella stessa pagina ci sono due regole più importanti del numero di versione. Un defaultMode che imposti nel tuo ~/.claude/settings.json resta invariato: Claude Code può chiederti una volta se vuoi passare alla modalità automatica e mantiene la tua impostazione se rifiuti. Anche una configurazione predefinita distribuita dalla tua organizzazione tramite le impostazioni gestite resta invariata. Il post dell'annuncio specificava che inizialmente la modalità automatica sarebbe rimasta facoltativa nei piani Enterprise e per Claude API. Dalla v2.1.283 la documentazione non prevede più questa eccezione per le sessioni nel terminale e in VS Code, anche se un'organizzazione a cui è applicata la configurazione HIPAA continua ad avviare le sessioni in modalità manuale.

Se esegui Claude Code su un VPS (server privato virtuale), il cambiamento è più rilevante rispetto a un laptop. Una richiesta di autorizzazione è un punto di controllo che richiede una persona alla tastiera. Su un server remoto spesso non sei presente, quindi la modalità con cui inizia una sessione è quella che mantiene per ore. Le esecuzioni non interattive di claude -p seguono una regola diversa: continuano ad avviarsi in default a meno che tu non passi una modalità, tranne che con un provider di terze parti o con la telemetria disattivata; in questi casi, dalla v2.1.285 in poi si avviano in auto.

Modalità di autorizzazione di Claude Code, dal massimo al minimo controllo

Sono disponibili sei modalità. Il nome all’inizio di ogni riga è il valore da inserire nelle impostazioni o da passare a --permission-mode. Tutte e sei sono applicate direttamente da Claude Code e non dal modello, perché stabilire cosa può fare una chiamata a uno strumento è compito dell’harness che circonda il modello.

• default: Claude chiede conferma prima di ogni nuovo utilizzo di uno strumento. Le letture all’interno della directory di lavoro vengono comunque eseguite senza 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, ma non modifica il codice sorgente. Le modifiche restano bloccate finché non approvi il piano.
• acceptEdits: le modifiche ai file vengono eseguite senza conferma, insieme ai comandi del filesystem mkdir, touch, rm, rmdir, mv, cp e sed. Questa modalità si applica soltanto ai percorsi all’interno della directory di lavoro o del tuo additionalDirectories. Per ogni altro comando della shell viene comunque richiesta conferma.
• auto: tutto viene eseguito, dopo che il classificatore ha verificato ogni azione. Le regole esplicite ask richiedono comunque una conferma.
• dontAsk: Claude Code nega automaticamente qualsiasi operazione che avrebbe richiesto una conferma. Vengono eseguite soltanto le letture dei file all’interno delle directory di lavoro, le regole allow, i comandi Bash incorporati di sola lettura e le 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 da default a acceptEdits e poi a plan. Da auto, la prima pressione passa a default. La barra di stato mostra la modalità risultante, ad esempio ⏵⏵ auto mode on o un ⏸ manual mode on grigio. Per impostazione predefinita, le altre modalità non fanno parte di questo ciclo. auto viene aggiunta quando il tuo account soddisfa i requisiti. bypassPermissions viene aggiunta soltanto se la sessione è stata avviata con --permission-mode bypassPermissions, --dangerously-skip-permissions o --allow-dangerously-skip-permissions, oppure con defaultMode: "bypassPermissions" nelle impostazioni utente, --settings o gestite. 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. Al 11 ottobre 2026, la documentazione elenca Claude Opus 4.6 o versioni successive, Sonnet 4.6 o versioni successive, Haiku 5.5 oppure un modello Fable sull’API Anthropic. Per Amazon Bedrock, Google Cloud e Microsoft Foundry l’elenco è più breve. La documentazione 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, controlla prima questi requisiti e qualsiasi impostazione disableAutoMode. Anthropic può anche disabilitare la modalità automatica lato server. Una sessione che riceve questa risposta mantiene la modalità automatica disabilitata fino al termine. Avvia quindi una nuova sessione in un secondo momento, invece di attendere nella sessione precedente.

Due controlli restano attivi in tutte le modalità, compresa 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 e decide se è coerente con ciò che hai richiesto. La documentazione ne descrive il compito in una frase:

Un modello classificatore separato esamina le azioni prima che vengano eseguite e blocca quelle che vanno oltre la richiesta, prendono di mira infrastrutture non riconosciute o sembrano essere indotte 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 gli elenchi completi delle regole in formato JSON e leggi l'insieme fornito con la versione installata.

Prima di fare affidamento su questo comportamento, considera due limiti documentati. Primo, nelle richieste al classificatore che Claude Code invia autonomamente, il classificatore vede i tuoi messaggi, le chiamate agli strumenti e i contenuti CLAUDE.md; 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. Secondo, 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. L'approvazione dell'azione richiesta riprende la modalità automatica. Queste soglie non sono configurabili. Un'esecuzione non interattiva con il flag -p e senza --permission-prompt-tool non ha nessuno a cui chiedere conferma. La documentazione specifica che Claude Code non interrompe l'esecuzione: l'azione bloccata non viene eseguita e Claude continua a lavorare.

È proprio questo secondo comportamento a creare problemi su un server remoto, in due modi diversi. Una sessione interattiva lasciata in esecuzione che raggiunge il limite si ferma davanti a una richiesta di conferma e attende una persona che non sta guardando il terminale. Un'esecuzione -p non attende mai, quindi un job può terminare lasciando incompleti i passaggi bloccati. Una seconda sessione di Claude Code sullo stesso server non sostituisce quella persona: il testo inviato da una sessione all'altra non viene mai considerato come un tuo consenso e non può rispondere a una richiesta di autorizzazione in sospeso. Una sessione sospesa davanti a una richiesta richiede quindi comunque una risposta umana. Limitare ciò che l'agent deve fare è l'altra parte della soluzione. Una skill che indirizza l'agent verso la modifica minima funzionante evita che una sessione si estenda verso azioni ampie che il classificatore bloccherebbe. Una skill guida una singola attività, mentre uno stile di output modifica direttamente il system prompt: di conseguenza, uno stile che richiede modifiche piccole e mirate si applica a ogni turno della sessione, non soltanto al job per cui lo hai attivato.

Dove sono definite le modalità in settings.json

Tutto quanto riportato sopra è un unico oggetto in un file di configurazione.

{
  "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 in ordine: deny, quindi ask, quindi allow. Il primo criterio corrispondente in questo ordine determina il risultato; 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 avete consentito esattamente quel comando. Una regola deny non può quindi contenere eccezioni.

ask è il tipo di regola che rende utile la modalità auto. La modalità auto elimina la richiesta di conferma ordinaria, mentre una regola ask la reintroduce per il comando specifico che deve richiedere l'intervento di una persona. Il comando di deploy deve essere inserito qui. Lo stesso vale per Bash(git push *) se volete un punto di controllo prima che il codice lasci il server. Conservare i file delle credenziali in deny completa questa configurazione e si combina con tenere innanzitutto le credenziali fuori dalla portata di un agent.

I file di configurazione, elencati dal livello di precedenza più basso:

• ~/.claude/settings.json: le impostazioni dell'utente, applicate a ogni progetto.
• .claude/settings.json: le impostazioni del progetto, sottoposte a commit nel repository.
• .claude/settings.local.json: le impostazioni personali per un singolo repository, escluse da git.
• Impostazioni gestite, distribuite da un amministratore. In Linux il file è /etc/claude-code/managed-settings.json. Nessuna impostazione può sovrascrivere una regola di autorizzazione gestita, incluso un flag della riga di comando.

Qui esiste un caso particolare con una causa documentata. defaultMode: "auto" non ha effetto quando proviene da .claude/settings.json o .claude/settings.local.json, così un repository non può abilitare autonomamente la modalità auto distribuendo un file di configurazione. Anche bypassPermissions viene ignorato se proviene da uno di questi due file. Impostate auto in quei file e Claude Code utilizza il valore predefinito integrato, ignorando qualsiasi defaultMode in ~/.claude/settings.json, senza stampare alcun errore. Nelle versioni o nei piani in cui il valore predefinito integrato è Manual, la sessione viene avviata silenziosamente in modalità default. Spostate la riga in ~/.claude/settings.json. Eseguite /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 kill switch. Entrambi richiedono la stringa "disable", non un valore booleano.

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

La documentazione specifica esattamente dove inserirli:

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

disableAutoMode rimuove auto dal ciclo Shift+Tab. Una sessione avviata con --permission-mode auto viene invece avviata in modalità Manuale. disableBypassPermissionsMode svolge la stessa funzione per la modalità bypass e funziona da qualsiasi ambito. Puoi quindi impostarlo nel tuo ~/.claude/settings.json per impedirti di accedere a una modalità che preferiresti non raggiungere alle 2 di notte su un server in produzione. Su un sistema utilizzato da altre persone, inserisci entrambi in /etc/claude-code/managed-settings.json. Il file di configurazione dell'utente appartiene infatti all'utente, mentre quello gestito non gli appartiene.

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

Il classificatore esamina un'azione alla volta. Non limita ciò che un'azione approvata esegue in seguito. La documentazione traccia chiaramente il confine:

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 supervisionate e non è richiesto come lo è per --dangerously-skip-permissions.

Su un server remoto, quindi, la combinazione corretta è la modalità automatica con un ambiente che si è disposti a perdere, non bypassPermissions accompagnato dalla speranza. La modalità bypass è documentata solo per 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 quell'utente una directory di lavoro e nessun altro contenuto utile da leggere. Ricreare il server invece di ripararlo: è questo il motivo per usare una VM usa e getta da eliminare dopo ogni job. I dettagli dell'hardening, dalla creazione dell'utente alle regole del firewall, sono descritti in la guida completa alla sicurezza per eseguire Claude Code su un VPS, quindi 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

Questo controllo viene saltato all'interno di una sandbox riconosciuta. Per questo, per il lavoro autonomo nei container, la soluzione documentata è un dev container che esegue Claude Code come utente non root. Se si controlla l'agent 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. Nulla può iniziare finché l'accesso non funziona. Se il server rifiuta la connessione con Permission denied (publickey), l'output SSH dettagliato indicherà quale dei cinque problemi si è verificato.

Configurare la sandbox Bash su un VPS Ubuntu

La sandbox integrata limita l'accesso al file system e alla rete di ogni comando Bash eseguito da Claude. Il sistema operativo applica queste limitazioni anche ai processi figli. Su Linux sono necessari due pacchetti.

sudo apt-get install bubblewrap socat

Avvia Claude Code ed esegui /sandbox. Si apre il pannello con le schede Mode, Overrides e Config. Se manca un pacchetto richiesto, viene mostrata soltanto la scheda Dependencies, che elenca gli elementi da installare. 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, la policy AppArmor predefinita impedisce a bubblewrap di creare gli user namespace necessari. Di conseguenza, la sandbox non si avvia. Verifica se il problema riguarda il tuo sistema:

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 indica 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. Quindi restringi il perimetro nelle impostazioni:

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

Questo blocco deve trovarsi nel file .claude/settings.json del progetto, perché . viene risolto nella directory principale 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 mantiene bloccati i file del progetto e impedisce a ogni comando di leggere il codice che dovrebbe modificare.

Devi sapere che cosa non copre questa configurazione. La sandbox limita Bash e i relativi processi figli. Gli strumenti integrati per i file vengono eseguiti all'interno del processo Claude Code. I server MCP (model context protocol) e gli hook sono processi separati che vengono eseguiti sull'host senza restrizioni. Per applicare un unico perimetro a tutti questi componenti, 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 stesura è una versione beta di anteprima per la ricerca.

Quale modalità è adatta a ciascuna configurazione?

Un solo repository sul proprio laptop

Usate auto, con regole ask per le azioni che volete sottoporre a controllo. Avete la tastiera davanti, il fallback del classificatore può effettivamente raggiungervi e il danno è limitato a una macchina sotto il vostro controllo. Questo è il caso per cui è stato definito il comportamento predefinito del 14 August.

Un VPS condiviso

Usate auto per ogni utente, configurato nel relativo ~/.claude/settings.json, su un sistema in cui l'account che esegue Claude Code non sia root e non possa leggere il lavoro degli altri utenti. Distribuite disableBypassPermissionsMode come "disable" in /etc/claude-code/managed-settings.json, insieme alle regole di negazione che proteggono i percorsi condivisi. Un sistema condiviso è il caso più evidente in cui bypassPermissions è errato, perché il confine di isolamento presupposto da questa modalità non esiste: gli altri tenant si trovano al suo interno.

CI e sessioni non interattive

Usate dontAsk con un elenco allow esplicito dei comandi necessari al job. Il rifiuto automatico è il comportamento corretto quando nessuna persona vedrà mai una richiesta. Anche la modalità automatica viene eseguita in modo non interattivo, ma un'esecuzione -p che incontra ripetuti blocchi del classificatore non si interrompe: le azioni bloccate vengono saltate e Claude continua a lavorare, quindi un job può terminare lasciando incompleti alcuni passaggi. Riservate bypassPermissions a un container o a una macchina virtuale che ricostruite da un'immagine, e non usatela su host che eseguono anche componenti importanti.

FAQ

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

È diventata quella predefinita il 14 agosto 2026 per le nuove sessioni nei piani Pro, Max e Team. Dall'11 ottobre 2026, la documentazione indica che Claude Code v2.1.283 o versioni successive la usa come modalità iniziale integrata per le sessioni interattive nel terminale e in VS Code, su ogni piano e provider, tranne nelle organizzazioni con la configurazione HIPAA applicata. Le esecuzioni non interattive claude -p continuano ad avviarsi in default se non si specifica una modalità, tranne che con provider di terze parti e nelle sessioni con la telemetria disattivata su v2.1.285 o versioni successive. Un valore predefinito impostato personalmente resta attivo finché non si accetta la richiesta di conferma per il cambio una tantum. Un valore predefinito gestito dall'organizzazione non cambia. 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?

Usare la modalità automatica insieme a un confine di isolamento. Il classificatore analizza 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 non presidiata richiede quindi un container, una macchina virtuale o un server che si sia disposti a ricreare. bypassPermissions ignora completamente i controlli ed è documentato solo per gli ambienti isolati. Claude Code rifiuta di avviarsi in questa modalità come root su Linux e stampa --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 ogni altro ambito. Nessun file delle impostazioni utente e nessun flag della riga di comando può quindi sovrascriverle. disableAutoMode rimuove auto dal ciclo Shift+Tab, mentre una sessione avviata con --permission-mode auto parte in modalità Manual. disableBypassPermissionsMode funziona inoltre 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 sbagliato. defaultMode: "auto" non ha effetto quando proviene da .claude/settings.json o .claude/settings.local.json. In questo modo un repository non può abilitare la modalità automatica semplicemente includendo un file delle impostazioni. Claude Code usa invece il valore predefinito integrato, ignorando qualsiasi defaultMode nelle impostazioni utente, e non stampa errori. Quando il valore predefinito integrato è Manual, la sessione viene avviata in modalità default. Spostare l'impostazione in ~/.claude/settings.json, quindi eseguire /permissions per verificare da quale file proviene ogni regola attiva. Se la modalità automatica è ancora non disponibile, controllare il requisito relativo al modello: i modelli meno recenti, come Sonnet 4.5, non sono supportati da alcun provider.