SpyBara
Go Premium

auto-mode-config.md 2026-06-16 21:57 UTC to 2026-06-17 17:02 UTC

6 added, 4 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.

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:

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.

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

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.

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