SpyBara
Go Premium

auto-mode-config.md 2026-06-29 23:02 UTC to 2026-06-30 23:02 UTC

61 added, 9 removed.

2026
Tue 30 23:02 Mon 29 23:02 Sat 27 01:01 Fri 26 23:00 Thu 25 23:58 Wed 24 22:02 Tue 23 22:00 Mon 22 23:59 Fri 19 22:58 Thu 18 22:00 Wed 17 17:02 Tue 16 21:57 Mon 15 23:02 Sat 13 21:59 Fri 12 22:00 Thu 11 23:01 Wed 10 23:57 Tue 9 06:34 Mon 8 06:52 Sat 6 06:24 Fri 5 06:45 Thu 4 06:52 Wed 3 06:53 Tue 2 06:51

Configurare la modalità auto

Comunica al classificatore della modalità auto quali repository, bucket e domini la tua organizzazione ritiene affidabili. Imposta il contesto dell'ambiente, sostituisci le regole di blocco e autorizzazione predefinite e ispeziona la tua configurazione effettiva con i sottocomandi CLI della modalità auto.

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. Le regole di negazione e richiesta esplicita vengono valutate prima del classificatore e continuano comunque a bloccare o richiedere. 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.

Per impostazione predefinita, 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:

Ambito File Utilizzare per
Un sviluppatore ~/.claude/settings.json Infrastruttura affidabile personale
Un progetto, uno sviluppatore .claude/settings.local.json Bucket o servizi affidabili per progetto
A livello di organizzazione Managed settings Infrastruttura affidabile distribuita a tutti gli sviluppatori
Flag --settings o Agent SDK JSON inline Override 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.

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.

A partire da Claude Code v2.1.195, claude auto-mode defaults stampa due tipi di voce di ambiente.

  • Trust slots: denominano ciò che il classificatore tratta come interno al tuo confine. Gli slot sono Repository affidabile, Controllo del codice sorgente, Domini interni affidabili, Bucket cloud affidabili, Servizi interni chiave e Registro di pacchetti interno. Le voci di repository e controllo del codice sorgente predefinite sono il repository di lavoro e i suoi remote configurati. Ogni altro slot di fiducia predefinito è None configured, quindi nient'altro è affidabile finché non lo aggiungi.
  • Sensitivity slots: denominano ciò che le regole protettive trattano come ad alto rischio. Gli slot sono Posizioni PII / dati regolamentati, Bersagli remoti sensibili e Ambiti IaC protetti. Ognuno predefinito è un'euristica ampia, come trattare qualsiasi host o namespace il cui nome contiene prod o production come bersaglio remoto sensibile, quindi le regole protettive sono attive prima di configurare qualsiasi cosa. Denominare bersagli concreti in uno slot di sensibilità fa sì che quelle regole si applichino ai bersagli denominati invece dell'euristica.

Le versioni precedenti a v2.1.195 stampano solo i primi cinque slot di fiducia.

Per aggiungere le tue voci insieme ai valori predefiniti, 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.

L'esempio seguente mantiene le voci predefinite e aggiunge i repository, i bucket, i domini e i servizi di un'organizzazione.

{
  "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
  • Registro di pacchetti interno: il registro npm, PyPI o altro privato attraverso il quale gli install dovrebbero instradare, in modo che gli install che lo bypassano per un registro pubblico vengano bloccati
  • Posizioni PII / dati regolamentati: i bucket, i database o i percorsi che contengono dati personali o regolamentati, in modo che il classificatore protegga quelle posizioni invece di indovinare dal contenuto
  • Bersagli remoti sensibili: gli spazi dei nomi, gli host o i container che contano come produzione, in modo che i shell remoti e i port-forward in essi richiedano la tua approvazione esplicita
  • Ambiti IaC protetti: le risorse di infrastruttura il cui apply o destroy dovrebbe sempre richiedere di denominare il cambiamento
  • Contesto aggiuntivo: vincoli del settore regolamentato, infrastruttura multi-tenant o requisiti di conformità che influiscono su ciò che il classificatore dovrebbe trattare come rischioso

Le voci Registro di pacchetti interno, Posizioni PII / dati regolamentati, Bersagli remoti sensibili e Ambiti IaC protetti richiedono Claude Code v2.1.195 o successivo. Le versioni precedenti le leggono ancora come contesto semplice ma non hanno le regole incorporate che le prendono di mira.

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.

Sostituire le regole di blocco e autorizzazione

Tre campi aggiuntivi ti permettono di sostituire gli elenchi di regole incorporate del classificatore:

  • autoMode.hard_deny: confini di sicurezza incondizionati
  • autoMode.soft_deny: azioni distruttive che l'intento dell'utente può annullare
  • autoMode.allow: eccezioni alle regole di blocco soft

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.

L'esempio seguente mantiene i valori predefiniti in tutti e quattro gli elenchi e aggiunge regole specifiche dell'organizzazione a ognuno.

{
  "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"
    ]
  }
}

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.

Instradare tutti i comandi shell attraverso il classificatore

Per impostazione predefinita, le regole di autorizzazione Bash e PowerShell strette come Bash(npm test) si trasportano nella modalità auto e si risolvono prima dell'esecuzione del classificatore. La modalità auto sospende solo le regole ampie che concedono l'esecuzione di codice arbitrario, come Bash(*) o interpreti con caratteri jolly. Ciò significa che una regola stretta può comunque far passare un argomento distruttivo senza che il classificatore lo veda, ad esempio un percorso di script o un flag che il prefisso della regola non ha anticipato.

Imposta autoMode.classifyAllShell su true per sospendere ogni regola di autorizzazione Bash e PowerShell mentre la modalità auto è attiva, in modo che il classificatore valuti ogni comando shell indipendentemente dal tuo elenco di autorizzazioni.

{
  "autoMode": {
    "classifyAllShell": true
  }
}

Questo scambia la latenza per la copertura: un comando che una regola di autorizzazione avrebbe approvato istantaneamente ora attende una decisione del classificatore, e ogni comando shell conta come una chiamata del classificatore.

L'impostazione si applica solo mentre la modalità auto è attiva, e le tue regole di autorizzazione si comportano normalmente in altre modalità di autorizzazione.

Ispezionare 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".

Esaminare i rifiuti

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.

In Claude Code v2.1.193 e successivo, il motivo del classificatore per ogni rifiuto appare accanto alla chiamata di strumento bloccata nella trascrizione, nella notifica di rifiuto e sotto ogni voce nella scheda Recently denied. Utilizza il motivo per decidere se la correzione è una voce environment, un'eccezione allow o un retry con intento esplicito nel tuo prossimo messaggio.

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.

Vedi anche

  • 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