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.
Auto mode è disponibile a tutti gli utenti dell’API Anthropic. Su Amazon Bedrock, Google Cloud Vertex AI e Microsoft Foundry, devi prima impostare CLAUDE_CODE_ENABLE_AUTO_MODE. Se Claude Code segnala che la modalità auto non è disponibile per il tuo account, controlla i requisiti completi, che coprono anche i modelli supportati e l’abilitazione dell’amministratore sui piani Team ed Enterprise.
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:

​
Dove il classificatore legge la configurazione

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, soft_deny e hard_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 morbido 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.

​
Definire l’infrastruttura affidabile

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’elenco di ambiente predefinito si fida del repository di lavoro e dei suoi remote configurati. Per aggiungere le tue voci insieme a quel valore predefinito, includi la stringa letterale "$defaults" nell’array. Le voci predefinite vengono inserite in quella posizione, quindi le tue voci personalizzate possono andare prima o dopo di esse. 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "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": [
      "$defaults",
      "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.

​
Sostituisci le regole di blocco e autorizzazione

Tre campi aggiuntivi ti permettono di sostituire gli elenchi di regole incorporati del classificatore: autoMode.hard_deny per i confini di sicurezza incondizionati, autoMode.soft_deny per le azioni distruttive che l’intento dell’utente può annullare, e autoMode.allow per le eccezioni. Ognuno è un array di descrizioni in prosa, lette come regole in linguaggio naturale. Per i blocchi duri basati su pattern di strumenti che vengono eseguiti prima del classificatore, utilizza permissions.deny. All’interno del classificatore, la precedenza funziona in quattro livelli:
  • Le regole hard_deny bloccano incondizionatamente. L’intento dell’utente e le eccezioni allow non si applicano.
  • Le regole soft_deny bloccano successivamente. L’intento dell’utente e le eccezioni allow possono ignorare questi blocchi.
  • Le regole allow quindi sostituiscono i blocchi soft_deny corrispondenti come eccezioni.
  • L’intento esplicito dell’utente ignora i blocchi soft rimanenti: 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ì. Per allentare, 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 distruttivi specifici del tuo ambiente che i valori predefiniti non coprono, o a hard_deny per i confini di sicurezza che non devono mai essere superati. Per mantenere le regole incorporate mentre aggiungi le tue, includi la stringa letterale "$defaults" nell’array. Le regole predefinite vengono inserite in quella posizione, quindi le tue regole personalizzate possono andare prima o dopo di esse, e continui a ereditare gli aggiornamenti mentre l’elenco incorporato cambia tra le versioni. 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "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": [
      "$defaults",
      "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"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}
L’impostazione di uno qualsiasi di environment, allow, soft_deny o hard_deny senza "$defaults" sostituisce l’intero elenco predefinito per quella sezione. Un array soft_deny senza "$defaults" scarta ogni regola di blocco soft incorporata, inclusi force push, curl | bash e distribuzioni di produzione. Un array hard_deny senza "$defaults" scarta le regole incorporate di esfiltrazione dei dati e di bypass dei controlli di sicurezza.
Ogni sezione viene valutata indipendentemente, quindi l’impostazione di environment da sola lascia intatti gli elenchi predefiniti allow, soft_deny e hard_deny. Ometti "$defaults" solo quando intendi assumere la piena proprietà dell’elenco. Per farlo 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.

​
Ispeziona i valori predefiniti e la tua configurazione effettiva

Tre sottocomandi CLI ti aiutano a ispezionare e convalidare la tua configurazione. Stampa le regole environment, allow, soft_deny e hard_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, soft_deny e hard_deny personalizzate: 
claude auto-mode critique
Esegui claude auto-mode config dopo aver salvato le tue impostazioni per confermare che le regole effettive sono quelle che ti aspetti, con "$defaults" espanso al suo posto. Se hai scritto regole personalizzate, claude auto-mode critique le esamina e contrassegna le voci che sono ambigue, ridondanti o probabilmente causeranno falsi positivi. Se hai bisogno di rimuovere o riscrivere una regola incorporata piuttosto che aggiungerne una accanto ad essa, salva l’output di claude auto-mode defaults in un file, modifica gli elenchi e incolla il risultato nel tuo file di impostazioni al posto di "$defaults".

​
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