Vai al contenuto principale
Auto mode consente a Claude Code di funzionare senza prompt di autorizzazione instradando ogni chiamata di strumento attraverso un classificatore che blocca qualsiasi cosa irreversibile, distruttiva o rivolta al di fuori del tuo ambiente. Utilizza il blocco di impostazioni autoMode per comunicare al classificatore quali repository, bucket e domini la tua organizzazione ritiene affidabili, in modo che smetta di bloccare le operazioni interne di routine. Immediatamente disponibile, il classificatore si fida solo della directory di lavoro e dei remote configurati del repository corrente. Azioni come il push verso l’organizzazione di controllo del codice sorgente della tua azienda o la scrittura in un bucket cloud del team vengono bloccate finché non le aggiungi a autoMode.environment. Per informazioni su come abilitare la modalità auto e cosa blocca per impostazione predefinita, consulta Permission modes. Questa pagina è il riferimento di configurazione. Questa pagina spiega come:

​
Where the classifier reads configuration

Il classificatore legge lo stesso contenuto CLAUDE.md che Claude stesso carica, quindi un’istruzione come “non forzare mai il push” nel CLAUDE.md del tuo progetto guida sia Claude che il classificatore contemporaneamente. Inizia da lì per le convenzioni del progetto e le regole comportamentali. Per le regole che si applicano tra i progetti, come l’infrastruttura affidabile o le regole di negazione a livello di organizzazione, utilizza il blocco di impostazioni autoMode. Il classificatore legge autoMode dai seguenti ambiti:
AmbitoFileUtilizzare per
Un sviluppatore~/.claude/settings.jsonInfrastruttura affidabile personale
Un progetto, uno sviluppatore.claude/settings.local.jsonBucket o servizi affidabili per progetto, gitignored
A livello di organizzazioneManaged settingsInfrastruttura affidabile distribuita a tutti gli sviluppatori
Flag --settings o Agent SDKJSON inlineOverride per invocazione per l’automazione
Il classificatore non legge autoMode dalle impostazioni di progetto condivise in .claude/settings.json, quindi un repository archiviato non può iniettare le proprie regole di autorizzazione. Le voci di ogni ambito vengono combinate. Uno sviluppatore può estendere environment, allow e soft_deny con voci personali ma non può rimuovere le voci fornite dalle impostazioni gestite. Poiché le regole di autorizzazione agiscono come eccezioni alle regole di blocco all’interno del classificatore, una voce allow aggiunta da uno sviluppatore può sostituire una voce soft_deny dell’organizzazione: la combinazione è additiva, non un confine di politica rigida.
Il classificatore è una seconda porta che si esegue dopo il sistema di autorizzazioni. Per le azioni che non devono mai essere eseguite indipendentemente dall’intento dell’utente o dalla configurazione del classificatore, utilizza permissions.deny nelle impostazioni gestite, che blocca l’azione prima che il classificatore venga consultato e non può essere ignorato.

​
Define trusted infrastructure

Per la maggior parte delle organizzazioni, autoMode.environment è l’unico campo che devi impostare. Comunica al classificatore quali repository, bucket e domini sono affidabili: il classificatore lo utilizza per decidere cosa significa “esterno”, quindi qualsiasi destinazione non elencata è un potenziale bersaglio di esfiltrazione. L’impostazione di environment sostituisce l’elenco di ambiente predefinito, che include la voce che si fida del repository di lavoro e dei suoi remote. Esegui claude auto-mode defaults per stampare i valori predefiniti, quindi includili insieme alle tue voci in modo da estendere l’elenco piuttosto che restringerlo. 
{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}
Le voci sono prosa, non regex o pattern di strumenti. Il classificatore le legge come regole in linguaggio naturale. Scrivile come descriveresti la tua infrastruttura a un nuovo ingegnere. Una sezione di ambiente completa copre:
  • Organizzazione: il nome della tua azienda e per cosa Claude Code viene utilizzato principalmente, come sviluppo software, automazione dell’infrastruttura o ingegneria dei dati
  • Controllo del codice sorgente: ogni organizzazione GitHub, GitLab o Bitbucket verso cui i tuoi sviluppatori eseguono il push
  • Provider cloud e bucket affidabili: nomi di bucket o prefissi che Claude dovrebbe essere in grado di leggere e scrivere
  • Domini interni affidabili: nomi host per API, dashboard e servizi all’interno della tua rete, come *.internal.example.com
  • Servizi interni chiave: CI, registri di artefatti, indici di pacchetti interni, strumenti di gestione degli incidenti
  • Contesto aggiuntivo: vincoli del settore regolamentato, infrastruttura multi-tenant o requisiti di conformità che influiscono su ciò che il classificatore dovrebbe trattare come rischioso
Un modello di partenza utile: compila i campi tra parentesi e rimuovi le righe che non si applicano. 
{
  "autoMode": {
    "environment": [
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}
Più contesto specifico fornisci, meglio il classificatore può distinguere le operazioni interne di routine dai tentativi di esfiltrazione. Non è necessario compilare tutto in una volta. Un rollout ragionevole: inizia con i valori predefiniti e aggiungi l’organizzazione di controllo del codice sorgente e i servizi interni chiave, che risolvono i falsi positivi più comuni come il push verso i tuoi repository. Aggiungi successivamente i domini affidabili e i bucket cloud. Compila il resto man mano che emergono i blocchi.

​
Override the block and allow rules

Due campi aggiuntivi ti permettono di sostituire gli elenchi di regole incorporati del classificatore: autoMode.soft_deny controlla cosa viene bloccato e autoMode.allow controlla quali eccezioni si applicano. Ognuno è un array di descrizioni in prosa, lette come regole in linguaggio naturale. Non esiste un campo autoMode.deny; per bloccare duramente un’azione indipendentemente dall’intento, utilizza permissions.deny, che viene eseguito prima del classificatore. All’interno del classificatore, la precedenza funziona in tre livelli:
  • Le regole soft_deny bloccano per prime
  • Le regole allow quindi sostituiscono i blocchi corrispondenti come eccezioni
  • L’intento esplicito dell’utente sostituisce entrambi: se il messaggio dell’utente descrive direttamente e specificamente l’azione esatta che Claude sta per intraprendere, il classificatore la consente anche quando una regola soft_deny corrisponde
Le richieste generali non contano come intento esplicito. Chiedere a Claude di “pulire il repository” non autorizza il force-push, ma chiedere a Claude di “force-push questo ramo” sì.
L’impostazione di uno qualsiasi di environment, allow o soft_deny sostituisce l’intero elenco predefinito per quella sezione. Se imposti soft_deny con una singola voce, ogni regola di blocco incorporata viene scartata: force push, esfiltrazione di dati, curl | bash, distribuzioni di produzione e tutte le altre regole di blocco predefinite diventano consentite. Per personalizzare in modo sicuro, esegui claude auto-mode defaults per stampare le regole incorporate, copiale nel tuo file di impostazioni, quindi esamina ogni regola rispetto alla tua pipeline e tolleranza al rischio. Rimuovi solo le regole per i rischi che la tua infrastruttura già mitiga.
Per allentare: rimuovi le regole da soft_deny quando i valori predefiniti bloccano qualcosa che la tua pipeline già protegge con revisione PR, CI o ambienti di staging, oppure aggiungi a allow quando il classificatore contrassegna ripetutamente un pattern di routine che le eccezioni predefinite non coprono. Per stringere: aggiungi a soft_deny per i rischi specifici del tuo ambiente che i valori predefiniti non coprono, oppure rimuovi da allow per mantenere un’eccezione predefinita alle regole di blocco. In tutti i casi, esegui claude auto-mode defaults per ottenere gli elenchi predefiniti completi, quindi copia e modifica: non iniziare mai da un elenco vuoto. 
{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow",
      "...copy full default soft_deny list here first, then add your rules..."
    ]
  }
}
Ogni sezione sostituisce solo il suo valore predefinito, quindi l’impostazione di environment da sola lascia intatti gli elenchi predefiniti allow e soft_deny.

​
Inspect the defaults and your effective config

Poiché l’impostazione di uno qualsiasi dei tre array sostituisce i suoi valori predefiniti, inizia qualsiasi personalizzazione copiando gli elenchi predefiniti completi. Tre sottocomandi CLI ti aiutano a ispezionare e convalidare. Stampa le regole environment, allow e soft_deny incorporate come JSON: 
claude auto-mode defaults
Stampa ciò che il classificatore effettivamente utilizza come JSON, con le tue impostazioni applicate dove impostate e valori predefiniti altrimenti: 
claude auto-mode config
Ottieni feedback AI sulle tue regole allow e soft_deny personalizzate: 
claude auto-mode critique
Salva l’output di claude auto-mode defaults in un file, modifica gli elenchi per corrispondere alla tua politica e incolla il risultato nel tuo file di impostazioni. Dopo il salvataggio, esegui claude auto-mode config per confermare che le regole effettive sono quelle che ti aspetti. Se hai scritto regole personalizzate, claude auto-mode critique le esamina e contrassegna le voci che sono ambigue, ridondanti o probabilmente causeranno falsi positivi.

​
Review denials

Quando la modalità auto nega una chiamata di strumento, il rifiuto viene registrato in /permissions nella scheda Recently denied. Premi r su un’azione negata per contrassegnarla per il retry: quando esci dalla finestra di dialogo, Claude Code invia un messaggio al modello dicendogli che può riprovare quella chiamata di strumento e riprende la conversazione. I rifiuti ripetuti per la stessa destinazione di solito significano che il classificatore manca di contesto. Aggiungi quella destinazione a autoMode.environment, quindi esegui claude auto-mode config per confermare che ha avuto effetto. Per reagire ai rifiuti a livello di programmazione, utilizza l’hook PermissionDenied.

​
See also

  • Permission modes: cos’è la modalità auto, cosa blocca per impostazione predefinita e come abilitarla
  • Managed settings: distribuisci la configurazione autoMode in tutta la tua organizzazione
  • Permissions: regole di autorizzazione, richiesta e negazione che si applicano prima dell’esecuzione del classificatore
  • Settings: il riferimento completo delle impostazioni, inclusa la chiave autoMode