Configurare la modalità auto

• Aggiungere un checkpoint umano per push e pull request con permissions.ask
• Definire l’infrastruttura affidabile con autoMode.environment
• Generare voci di ambiente con /auto-mode-setup
• Esaminare i rifiuti in modo da sapere cosa aggiungere successivamente

​

Confini comuni

​

Aggiungere un checkpoint umano

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

​

Dove il classificatore legge la configurazione

​

Definire l’infrastruttura affidabile

• Context slots: descrivono la tua organizzazione, stack e postura di sicurezza in modo che il classificatore legga le altre regole nel tuo contesto. Ognuno predefinito è None configured o all’assunzione conservativa denominata accanto ad esso:
  • Organization
  • Primary use of Claude Code: predefinito per lo sviluppo software
  • Cloud provider(s)
  • Repository visibility: un repository è assunto privato a meno che il suo host remoto e il nome non indichino diversamente, o il classificatore legga un controllo di visibilità precedente nella conversazione che mostra che è pubblico. Nelle richieste del classificatore inviate da Claude Code stesso, il classificatore legge i tuoi messaggi e i comandi che Claude esegue, non il loro output. L’evidenza deve essere qualcosa che il classificatore può leggere, come il tuo stesso messaggio che nomina il repository come pubblico; l’output di un gh repo view da solo non lo raggiunge.
  • Internal sharing / snippet hosting: i servizi di paste e gist pubblici sono trattati come esterni al confine di fiducia finché non ne nomini uno
  • Org-specific CLIs
  • Secrets management
  • CI/CD deploy targets
  • Network posture
  • Host containment: predefinito a una macchina sviluppatore ordinaria o runner CI con internet aperto. Se Claude Code viene eseguito in un container, VM o pod con un allow-list di uscita o vicini che non deve toccare, nomina gli host consentiti, se l’endpoint dei metadati cloud dovrebbe essere raggiungibile e quale progetto cloud, cluster o registro il compito utilizza e sotto quale identità. Finché questa voce non nomina quell’identità, il classificatore blocca le richieste per le credenziali dell’host stesso. Richiede Claude Code v2.1.257 o successivo
  • Protected deployment namespaces / environments: ricade all’euristica Sensitive remote targets finché non li nomini
  • Data retention / declassification
• Trust slots: denominano ciò che il classificatore tratta come interno al tuo confine. Gli slot sono Trusted repo, Source control, Trusted internal domains, Trusted cloud buckets, Key internal services e Internal package registry. 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. La visibilità di un repository limita solo il materiale confidenziale: un repository privato è una destinazione accettabile per il materiale confidenziale, ma rendere un repository privato non cancella mai i segreti o i dati personali o affidati in esso, e il classificatore tratta il contenuto trasportato, reindirizzato o letto per la prima volta dall’esterno del repository di lavoro come non il lavoro proprio di quel repository.
• Sensitivity slots: denominano ciò che le regole protettive trattano come ad alto rischio. Gli slot sono Sensitive data locations & audiences, Sensitive remote targets e Protected IaC scopes. 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.

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

• Organization: il nome della tua azienda e per cosa Claude Code viene utilizzato principalmente, come sviluppo software, automazione dell’infrastruttura o ingegneria dei dati
• Source control: ogni organizzazione GitHub, GitLab o Bitbucket verso cui i tuoi sviluppatori eseguono il push
• Cloud providers and trusted buckets: nomi di bucket o prefissi che Claude dovrebbe essere in grado di leggere e scrivere
• Trusted internal domains: nomi host per API, dashboard e servizi all’interno della tua rete, come *.internal.example.com
• Key internal services: CI, registri di artefatti, indici di pacchetti interni, strumenti di gestione degli incidenti
• Internal package registry: 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
• Sensitive data locations & audiences: i bucket, i database o i percorsi che contengono dati personali, dati aziendali confidenziali, credenziali, dati regolamentati o materiale simile sensibile, e i destinatari con cui i dati in ogni posizione possono essere condivisi, in modo che il classificatore protegga quelle posizioni invece di indovinare dal contenuto.
• Sensitive remote targets: 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
• Protected IaC scopes: le risorse di infrastruttura il cui apply o destroy dovrebbe sempre richiedere di denominare il cambiamento
• Additional context: vincoli del settore regolamentato, infrastruttura multi-tenant o requisiti di conformità che influiscono su ciò che il classificatore dovrebbe trattare come rischioso

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

​

Generare voci di ambiente con /auto-mode-setup

​

Cosa legge /auto-mode-setup

• Il CLAUDE.md, README.md, i file di configurazione e i remote git di questo progetto
• Le tue impostazioni autoMode e permissions.allow
• Gli host, i bucket e i nomi dei comandi dai comandi che Claude ha eseguito nelle tue sessioni recenti in questo progetto, mai i tuoi messaggi

• La prima parola di ogni comando nella tua cronologia della shell
• Gli host remoti e i nomi dei repository sotto la tua home directory

​

Esaminare e salvare la bozza

• Claude Code scrive la lista environment senza "$defaults", perché la bozza esplicita le voci incorporate che ha lasciato invariate
• Claude Code include "$defaults" in ognuno degli elenchi allow, soft_deny e hard_deny a cui la bozza aggiunge voci, a meno che tu non abbia già scritto un elenco allow senza di esso, quindi le regole incorporate che non hai sostituito rimangono in vigore
• Dopo il salvataggio, Claude Code offre di rimuovere le regole permissions.allow in ~/.claude/settings.json che la modalità auto ignora, come Bash(*), o che approvano automaticamente i comandi distruttivi

​

Disattivare /auto-mode-setup

{
  "skillOverrides": {
    "auto-mode-setup": "off"
  }
}

​

Sostituire le regole di blocco e autorizzazione

• 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

• 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.

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

​

Modificare le regole da /permissions

​

Instradare tutti i comandi shell attraverso il classificatore

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

​

Ispezionare i valori predefiniti e la tua configurazione effettiva

claude auto-mode defaults

claude auto-mode config

{
  "allow": [
    ...
    "Test Artifacts: Hardcoded test API keys, placeholder credentials in examples, or hardcoding test cases. Placeholder means authored as a placeholder — a file or value copied from a real secret or sensitive path is never a test artifact (see Sensitive-Source Provenance).",
    ...
  ],
  "soft_deny": [
    "Git Destructive [named+specifics — **must name:** the destructive operation and its target]: Force pushing (`git push --force`), deleting remote branches, tags, or releases, or rewriting remote history. Also `git commit --amend` when the commit being rewritten is not the agent's own unpushed work: either no prior `git commit` is visible (HEAD pre-dates the session), or a `git push` of the current branch is visible after the most recent commit (it has been pushed). Clears when the user asked to amend/reword/fixup, or when it is a message-only reword (`--amend -m …`, nothing newly staged) of a commit the agent visibly created this session.",
    ...
  ],
  "hard_deny": [...],
  "environment": [
    ...
    "**Trusted repo**: The git repository the agent started in (its working directory) and its configured remote(s). When the repo's public/private visibility is given — by the Repository visibility entry or the user's own message — use it to scope what is OK to commit or push there: confidential material is fine in a private repo; in a public one, only that repo's own work is — and content ported, repointed, or first read from outside this session's repo is not its own work, whoever directed the port. Visibility scopes confidential material only: secrets and sensitive data (personal & entrusted) are never cleared into any repo by its visibility (see Definitions).",
    ...
  ]
}

claude auto-mode critique

claude auto-mode reset

​

Esaminare i rifiuti

​

Correggere un rifiuto con una regola di autorizzazione, una voce di ambiente o un retry

• Una destinazione che Claude ha bisogno durante l’intero compito, come un registro di pacchetti, un dominio interno o un host di repository: aggiungilo a autoMode.environment.
• Un comando che desideri eseguire senza revisione da ora in poi: aggiungi una regola allow.
• Un’azione una tantum che intendevi: dichiara quell’intento nel tuo prossimo messaggio e lascia che Claude riprovi.

​

Correggere i rifiuti ripetuti

​

Vedi anche

• Permission modes: cos’è la modalità auto, cosa blocca per impostazione predefinita e quali sessioni iniziano in essa
• 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
• All settings: ogni chiave di impostazioni, inclusa autoMode