Modalità automatica di Claude Code: come insegnarle il tuo ambiente

La modalità automatica di Claude Code è la modalità in cui l'agente esegue le azioni senza chiedere conferma a ogni passo, perché un secondo modello, il classificatore, le esamina prima che partano. Il changelog ufficiale di Claude Code alla versione 2.1.304 estende /auto-mode-setup, la procedura guidata che insegna alla modalità automatica come è fatto il tuo ambiente, alle sessioni su Bedrock, Vertex, Foundry, Claude apps gateway e a quelle con la telemetria disattivata.

Il punto che interessa a chi costruisce è un altro: la modalità automatica smette di essere fastidiosa solo quando il classificatore sa quali repository e servizi sono tuoi. Finché non lo sa, ti blocca azioni perfettamente normali, e a quel punto si torna a rispondere alle richieste di permesso una dopo l'altra.

Cos'è la modalità automatica di Claude Code e quando parte

Secondo la documentazione ufficiale sui permessi, con Claude Code dalla versione 2.1.283 la modalità automatica è la modalità di partenza delle sessioni interattive nel terminale e in VS Code, su ogni piano e su ogni provider. Si avvia esplicitamente con claude --permission-mode auto, oppure si imposta permissions.defaultMode su "auto" nel file ~/.claude/settings.json.

Il classificatore usa per impostazione predefinita Claude Sonnet 5. Le azioni in lettura e le modifiche ai file nella cartella di lavoro passano senza controllo, mentre tutto il resto va al classificatore, che blocca per esempio curl | bash, i deploy in produzione, il force push e l'invio di dati sensibili a indirizzi esterni.

Per capire dove questo si incastra nel lavoro di tutti i giorni, la guida su cos'è Claude Code e come funziona copre le basi, mentre qui interessa solo la parte che decide cosa passa e cosa no.

Perché il classificatore blocca azioni che per te sono normali

Il classificatore blocca azioni normali perché, per impostazione predefinita, si fida soltanto della cartella di lavoro e dei remote configurati del repository corrente. Lo dice la pagina di configurazione della modalità automatica: spingere sull'organizzazione GitHub della tua azienda o scrivere su un bucket di squadra viene bloccato finché quei posti non compaiono in autoMode.environment.

Non è un difetto. Dal punto di vista del classificatore, qualunque destinazione non elencata è un possibile punto di fuga dei dati, quindi la prudenza è voluta. Il costo, però, lo paghi tu: dopo 3 blocchi di fila o 20 in totale la modalità automatica si mette in pausa e Claude Code torna a chiedere conferma a ogni azione, che è esattamente la situazione da cui volevi uscire.

La soluzione non è abbassare le difese, ma dare al classificatore le informazioni che gli mancano.

Cosa legge /auto-mode-setup e cosa scrive

/auto-mode-setup è un comando di Claude Code che prepara una bozza delle voci di autoMode.environment leggendo il progetto e le sessioni recenti. Sempre secondo la documentazione, legge CLAUDE.md, README.md, i file di configurazione e i remote di git del progetto, le tue impostazioni autoMode e permissions.allow, e gli host, i bucket e i nomi dei comandi eseguiti da Claude nelle sessioni recenti di quel progetto. Non legge mai i tuoi messaggi.

Due scansioni aggiuntive sono facoltative e le sceglie chi usa il comando: la prima parola di ogni comando nella cronologia della shell, e gli host e i nomi dei repository sotto la cartella home. La bozza si accetta o si scarta per intero, quindi eventuali ritocchi alle singole voci si fanno dopo, a mano, in ~/.claude/settings.json, dove il comando scrive se accetti.

Dopo il salvataggio la verifica è una riga: claude auto-mode config mostra le regole effettive che il classificatore userà. Se lo lasci stare, Claude Code ti propone /auto-mode-setup da solo, con la finestra "Teach auto mode about your environment?", dopo che la modalità automatica ha bloccato diverse azioni e non hai ancora nessuna voce autoMode.environment.

Dove va scritta la configurazione della modalità automatica

La configurazione della modalità automatica va scritta in ~/.claude/settings.json, nelle impostazioni gestite dall'organizzazione o in un parametro --settings, e mai nei file di progetto. Il classificatore ignora autoMode dentro .claude/settings.json e .claude/settings.local.json, perché quei file vivono nel repository e un repository clonato da altri potrebbe altrimenti scriversi da solo le proprie regole di via libera.

Il classificatore legge anche lo stesso CLAUDE.md che legge Claude. In questo sito, per esempio, il file CLAUDE.md alla radice del repository descrive comandi e architettura ma non contiene nessun confine pensato per il classificatore, come "mai force push". È il primo posto dove aggiungerlo, prima ancora di toccare le impostazioni, e per scriverlo bene aiuta la guida su le quattro regole del CLAUDE.md.

Un esempio di autoMode.environment

Le voci sono prosa, non espressioni regolari: la documentazione le descrive come regole in linguaggio naturale, da scrivere come spiegheresti l'infrastruttura a un nuovo collega. La stringa "$defaults" tiene le voci predefinite e ci aggiunge le tue.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/tua-organizzazione e tutti i repo sotto di essa",
      "Trusted cloud buckets: s3://tua-organizzazione-build",
      "Key internal services: Jenkins su ci.tuodominio.it"
    ]
  }
}

L'avvertenza più importante della pagina ufficiale riguarda proprio quella stringa: impostare environment, allow, soft_deny o hard_deny senza "$defaults" sostituisce l'intera lista predefinita di quella sezione. Se lo fai su soft_deny, perdi le regole contro force push, curl | bash e deploy in produzione.

Come mettere un punto di controllo umano anche in modalità automatica

Un punto di controllo umano si mette con una regola permissions.ask, che viene valutata prima del classificatore e forza sempre la richiesta di conferma. La documentazione ufficiale fa l'esempio di Bash(git push *) e Bash(gh pr create *), e avverte che un push scritto in altro modo, come git -C <cartella> push, non corrisponde alla regola.

Per un limite che deve valere sempre si usa quindi una regola ask o deny, non una frase detta a Claude. Se serve un controllo che legga il testo intero del comando, la strada è un hook: ne parla la guida agli hook di Claude Code che bloccano un'azione. Lo stesso ragionamento sui confini vale per qualunque agente messo al lavoro in azienda, ed è il tema della consulenza sugli agenti AI.

Cosa fare per configurare la modalità automatica, in ordine

Il percorso più breve per una modalità automatica che non ti blocca a vuoto ha cinque passaggi, e il primo costa un minuto.

1. Aggiorna Claude Code e lancia claude auto-mode config per vedere le regole in uso adesso.
2. Esegui /auto-mode-setup, accetta la bozza solo dopo averla letta e controlla che nessuna voce apra a destinazioni che non vuoi fidate.
3. Rilancia claude auto-mode config e verifica che "$defaults" sia presente in ogni lista toccata.
4. Aggiungi regole permissions.ask per git push e gh pr create se vuoi un controllo umano sulle pubblicazioni.
5. Quando un'azione viene negata, apri /permissions, scheda Recently denied, e decidi se serve una voce environment o un solo nuovo tentativo con il tasto r.

Per chi lavora in contenitori o su macchine condivise, la guida a Claude Code in un container e quella sulle sandbox dei comandi con Kiro mostrano l'altro lato del problema, cioè limitare dove l'agente può arrivare a prescindere dal classificatore.

La mia lettura è semplice: la modalità automatica non si valuta dai permessi che toglie, ma da quanto bene descrivi il tuo ambiente. Cinque minuti dedicati a autoMode.environment valgono più di una giornata passata a confermare richieste di permesso.