SpyBara
Go Premium

permission-modes.md 2026-09-17 05:00 UTC to 2026-09-18 23:58 UTC

This page contains 37 additions and 28 deletions.

2026
Wed 9 22:58 Sat 12 03:02 Sun 13 21:00 Fri 18 23:58 Sat 19 23:57 Tue 22 23:59 Fri 25 23:58

Scegli una modalità di autorizzazione

Controlla se Claude chiede prima di agire. Cambia le modalità di autorizzazione con Shift+Tab nella CLI, l'indicatore di modalità in VS Code, o il selettore di modalità in Desktop.

Una modalità di autorizzazione imposta quali azioni Claude può intraprendere in una sessione senza chiederti prima. In modalità Manual, Claude Code si ferma e ti chiede prima della maggior parte delle azioni che modificano file, eseguono comandi shell, o raggiungono la rete. In modalità auto, un secondo modello, il classificatore, esamina le azioni al tuo posto; come il classificatore valuta le azioni elenca quali azioni esamina e quali le saltano.

Sui piani Pro, Max e Team, la modalità di autorizzazione iniziale integrata è la modalità auto. Quale modalità inizia una sessione copre le superfici e le impostazioni che cambiano la modalità di autorizzazione iniziale. Puoi anche cambiare la modalità di autorizzazione di una sessione in esecuzione in qualsiasi momento.

Modalità disponibili

Ogni modalità fa un diverso compromesso tra comodità e controllo. La tabella seguente mostra cosa Claude può fare senza una richiesta di autorizzazione in ogni modalità. La modalità Manual appare sotto il suo valore di configurazione, default.

Modalità Cosa viene eseguito senza chiedere Migliore per
default Solo letture Revisionare ogni azione voi stessi, lavoro sensibile
acceptEdits Letture, modifiche di file e comandi comuni del filesystem (mkdir, touch, mv, cp, ecc.) Iterare sul codice che state revisionando
plan Letture, più comandi approvati dal classificatore quando la modalità auto è disponibile Esplorare una codebase prima di modificarla
auto Tutto, con controlli di sicurezza in background Attività lunghe, ridurre l'affaticamento da prompt
dontAsk Letture e strumenti pre-approvati; qualsiasi cosa che comporterebbe una richiesta viene negata CI bloccato e script
bypassPermissions Tutto Solo container e VM isolati

La modalità che esamina ogni azione è denominata Manual nella CLI, in claude --help, nelle estensioni VS Code e JetBrains, e nell'app desktop. Il suo valore di configurazione è default, che è quello utilizzato da hooks e integrazioni SDK. La CLI accetta manual come alias ovunque digitate il valore, ad esempio claude --permission-mode manual o "defaultMode": "manual". L'etichetta Manual e l'alias manual richiedono Claude Code v2.1.200 o successivo. L'etichetta dell'app desktop non dipende dalla vostra versione CLI.

Le scritture su percorsi protetti non vengono mai auto-approvate tranne in modalità bypassPermissions e in sessioni in modalità plan dove le autorizzazioni di bypass sono disponibili, il che significa sessioni avviate in modo da mettere bypassPermissions nel ciclo di modalità.

Le modalità impostano la linea di base. Sovrapponete regole di autorizzazione su top per pre-approvare o bloccare strumenti specifici. Le regole di negazione bloccano in ogni modalità, inclusa bypassPermissions. Le regole di negazione e richiesta non si applicano a EndConversation finché Claude ha ancora almeno uno strumento che può chiamare. Le regole allow non hanno effetto in bypassPermissions.

Azioni che nessuna modalità auto-approva

Claude Code non auto-approva quanto segue in nessuna modalità, inclusa bypassPermissions. Ogni punto collega alla sezione che dice cosa succede invece in ogni modalità:

  • Strumenti corrispondenti a una regola ask esplicita

  • Strumenti connector che la vostra organizzazione ha impostato su ask, in sessioni dove quella impostazione raggiunge Claude Code

  • Strumenti che richiedono interazione dell'utente: lo strumento integrato AskUserQuestion e strumenti MCP contrassegnati requiresUserInteraction

  • Rimozioni rm e rmdir che prendono di mira un percorso critico, che nessuna regola allow o hook PreToolUse "allow" approva

  • Le protezioni di messaggistica cross-sessione

  • Letture al di fuori delle directory di lavoro mentre permissions.blockReadsOutsideWorkingDirectories è attivo: comandi Bash riconosciuti che leggono file e qualsiasi retry non sandboxato che necessita di approvazione per eseguire al di fuori del sandbox anche in modalità auto e modalità bypassPermissions. Richiede Claude Code v2.1.257 o successivo.

    Un comando che il parser della shell non riesce a tracciare, come uno che cambia directory più di una volta o esegue una subshell, richiede lo stesso modo anche quando non nomina alcun percorso esterno. Questo prompt non si applica quando il comando viene eseguito nella sandbox e la sandbox applica il blocco.

Configurazioni comuni

Le modalità di autorizzazione decidono se Claude chiede prima di un'azione, e la sandbox Bash e i confini di isolamento esterni decidono cosa un'azione può raggiungere una volta che viene eseguita. Ogni riga seguente abbina un obiettivo ai flag o alle impostazioni che ti portano lì e all'isolamento di cui ha bisogno, come punto di partenza. Modalità disponibili elenca cosa viene eseguito senza un prompt in ogni modalità.

Vuoi Inizia con Isolamento necessario Note
Revisionare ogni azione tu stesso Modalità Manual: claude --permission-mode default Nessuno Lavoro sensibile, codice non familiare
Iterare localmente con meno prompt, senza un classificatore Modalità Manual più la sandbox Bash in modalità auto-allow: claude --permission-mode default, quindi esegui /sandbox e seleziona auto-allow La sandbox Bash integrata, su macOS, Linux e WSL2 Le regole di negazione si applicano comunque, e le regole di richiesta che nominano un comando, come Bash(git push *), richiedono comunque un prompt. Per attivare la sandbox da un file di impostazioni, imposta sandbox.enabled su true
Esplorare prima di modificare qualsiasi cosa claude --permission-mode plan Nessuno Claude Code blocca le modifiche finché non approvi un piano
Lavorare senza intervento in modalità auto claude --permission-mode auto, la modalità di autorizzazione iniziale integrata su Pro, Max e Team Nessuno; una sandbox o un container aggiunge difesa in profondità Richiede un modello supportato, e la tua organizzazione può disattivare la modalità auto
Eseguire in CI con una lista di autorizzazione esatta claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" Nessuno oltre a quello che il tuo runner CI fornisce Cloud sessions ignora dontAsk dai file di impostazioni
Eseguire completamente senza intervento dentro un container claude -p "<prompt>" --dangerously-skip-permissions Richiesto: un container, VM, o il runtime sandbox; su Linux e macOS, eseguilo come utente non root Cloud sessions ignora questa modalità dai file di impostazioni. In questa esecuzione -p, le poche chiamate che richiederebbero comunque un prompt vengono negate invece

La sandbox Bash e la modalità auto funzionano indipendentemente e si combinano, con le eccezioni elencate in Modalità sandbox. Per l'interazione completa, vedi Come il sandboxing si relaziona alle autorizzazioni e alle modalità di autorizzazione e Come l'isolamento si relaziona alle modalità di autorizzazione.

Quale modalità inizia una sessione

Quando avvii una nuova sessione in un terminale, Claude Code prende la modalità di autorizzazione dal primo di questi che si applica:

  1. Il flag --permission-mode, o --dangerously-skip-permissions

  2. permissions.defaultMode in un file di impostazioni

    Se imposti "auto" in .claude/settings.json o .claude/settings.local.json, il valore non ha effetto, e Claude Code utilizza invece l'impostazione predefinita integrata piuttosto che un defaultMode da ~/.claude/settings.json. Se imposti "bypassPermissions" in questi due file, non ha effetto nemmeno, e la sessione inizia in modalità Manual. Gli altri valori si applicano da qualsiasi file di impostazioni.

  3. L'impostazione predefinita integrata

Le conversazioni che l'estensione VS Code avvia seguono il proprio elenco dell'estensione in Cambia modalità di autorizzazione. Per la modalità di autorizzazione in cui Claude Code avvia una sessione ripresa, vedi modalità di autorizzazione al ripristino.

L'impostazione predefinita integrata auto richiede Claude Code v2.1.228 o successivo su macOS, Linux e WSL, e v2.1.233 o successivo su Windows nativo. Su versioni precedenti, l'impostazione predefinita integrata è Manual.

L'impostazione predefinita integrata dipende da come esegui Claude Code, dal tuo piano, e da se Claude Code potrebbe recuperare i suoi flag di funzionalità. La prima riga che corrisponde alla tua sessione si applica. La tabella copre le sessioni che avvii in un terminale o tramite l'estensione VS Code; per l'app desktop e claude.ai, vedi le schede Desktop e Web in Cambia modalità di autorizzazione.

Come esegui Claude Code Modalità di autorizzazione iniziale integrata
Un file di impostazioni imposta disableAutoMode su "disable" default
Il recupero dei flag di funzionalità è disattivato default
La tua prima sessione dopo aver installato Claude Code o aggiornato a una versione che aggiunge questa impostazione predefinita, a meno che, dopo un'installazione pulita, Claude Code recuperi i flag in tempo default
claude -p o l'Agent SDK default
Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, Claude Platform su AWS, o una sessione gateway app Claude con accesso default
Un piano Pro, Max o Team, in un terminale o tramite l'estensione VS Code auto
Un piano Enterprise o una chiave API Claude Console default

Quando il recupero dei flag di funzionalità è disattivato, o in una prima sessione dopo un'installazione o aggiornamento dove i flag non sono ancora arrivati, l'estensione VS Code ignora ogni file di impostazioni quando sceglie la modalità di autorizzazione iniziale.

Quando il flag, un file di impostazioni, o l'impostazione predefinita integrata seleziona auto ma la modalità auto non è disponibile per la sessione, Claude Code avvia la sessione in Manual invece. La modalità auto non è disponibile quando la sessione non soddisfa i requisiti di disponibilità, come un file di impostazioni che la disattiva o un modello che non la supporta, o quando Anthropic l'ha temporaneamente disattivata lato server.

La prima volta che l'impostazione predefinita integrata avvia una delle tue sessioni in modalità auto, Claude Code mostra un avviso che collega a questa pagina:

  • In un terminale, una volta, in cima alla sessione
  • Nell'estensione VS Code, come una scheda nella schermata di nuova conversazione che rimane finché non la chiudi

Sui piani Pro, Max e Team, se il tuo ~/.claude/settings.json imposta un defaultMode diverso da auto e nessun altro file di impostazioni ne imposta uno, le tue sessioni continuano a iniziare in quella modalità. Claude Code chiede una volta, nel terminale o nell'estensione VS Code, se cambiare l'impostazione in modalità auto. Se rifiuti, la tua impostazione rimane come è.

Inizia in una modalità di autorizzazione diversa

Puoi impostare la modalità di autorizzazione iniziale per una sessione, o come impostazione predefinita per ogni sessione su una macchina, in un progetto, o in un'organizzazione. Quando più di un file di impostazioni imposta permissions.defaultMode, la precedenza delle impostazioni decide, quindi un valore di progetto o gestito supera ~/.claude/settings.json. Per cambiare la modalità di autorizzazione di una sessione già in esecuzione, vedi Cambia modalità di autorizzazione.

Per impostare la modalità di autorizzazione iniziale per Fai questo
Una sessione che stai per avviare Passa la modalità di autorizzazione come flag, ad esempio claude --permission-mode default
Ogni sessione di terminale che avvii su questa macchina Imposta permissions.defaultMode in ~/.claude/settings.json. Per quello che l'estensione VS Code legge, vedi Cambia modalità di autorizzazione
Ogni sessione di terminale che avvii in un progetto Imposta permissions.defaultMode nel .claude/settings.json del progetto. Le sessioni che avvii in un terminale rispettano ogni valore tranne auto e bypassPermissions; le sessioni che l'estensione VS Code avvia non leggono le impostazioni del progetto per la modalità di autorizzazione iniziale
Ogni sessione di terminale nella tua organizzazione Imposta permissions.defaultMode nelle impostazioni gestite. Le sessioni di terminale iniziano in quella modalità e le persone possono comunque passare alla modalità auto; per quello che l'estensione VS Code legge, vedi Cambia modalità di autorizzazione. Per rimuovere la modalità auto in modo che nessuno possa selezionarla, imposta permissions.disableAutoMode su "disable" invece

Questo esempio fa sì che ogni sessione di terminale sulla tua macchina inizi in modalità Manual, il cui valore di configurazione è default. Salvalo in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

La prossima sessione che avvii mostra ⏸ manual mode on nella barra di stato.

Cambiare le modalità di autorizzazione

Ogni interfaccia ha il proprio controllo per cambiare le modalità di autorizzazione durante una sessione e il proprio modo di scegliere la modalità di autorizzazione con cui iniziano le nuove sessioni. Seleziona la tua interfaccia per vedere i suoi controlli.

Durante una sessione: premi Shift+Tab per ciclo attraverso le modalità di autorizzazione. Da auto, il primo pressione passa a default, e il ciclo quindi esegue default → acceptEdits → plan → ritorno a default. Le modalità opzionali, descritte di seguito, si inseriscono dopo plan. La barra di stato mostra la modalità attiva come ⏸ manual mode on grigio per default, oppure come ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on, o ⏵⏵ bypass permissions on.

Non tutte le modalità sono nel ciclo predefinito:

  • auto: appare quando auto mode è disponibile; il ciclo ad essa passa le modalità di autorizzazione senza un prompt di conferma
  • bypassPermissions: appare dopo che inizi con --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions, o permissions.defaultMode: "bypassPermissions" in impostazioni utente, --settings, o impostazioni gestite. La variante --allow- aggiunge la modalità di autorizzazione al ciclo senza attivarla
  • dontAsk: non appare mai nel ciclo; impostala con --permission-mode dontAsk

Le modalità opzionali abilitate si inseriscono dopo plan, con bypassPermissions per primo e auto per ultimo. Se hai entrambe abilitate, ciclerai attraverso bypassPermissions sulla strada verso auto.

Da un prompt di autorizzazione Bash: nelle modalità di autorizzazione Manual e acceptEdits, quando auto mode è disponibile, Claude Code aggiunge Yes, and switch to auto mode al prompt di autorizzazione di un comando Bash. Selezionalo per approvare il comando e passare la sessione alla modalità auto. I prompt dello strumento PowerShell non offrono l'opzione. Richiede Claude Code v2.1.247 o successivo.

Claude Code non aggiunge l'opzione ai prompt forzati da una delle tue regole ask o da un hook, perché la modalità auto ti mostra comunque quei prompt, quindi il passaggio non li rimuoverebbe.

All'avvio: passa la modalità di autorizzazione come flag.

claude --permission-mode plan

Come predefinito: imposta permissions.defaultMode nell'ambito che desideri, come descritto in Inizia in una modalità di autorizzazione diversa.

Lo stesso flag --permission-mode funziona con -p per esecuzioni non interattive.

Auto-approva le modifiche ai file con la modalità acceptEdits

La modalità acceptEdits consente a Claude di creare e modificare file nella tua directory di lavoro senza richiedere conferma. La barra di stato mostra ⏵⏵ accept edits on mentre questa modalità è attiva.

Oltre alle modifiche ai file, la modalità acceptEdits auto-approva i comuni comandi Bash del filesystem: mkdir, touch, rm, rmdir, mv, cp e sed. Questi comandi vengono anche auto-approvati quando preceduti da variabili di ambiente sicure come LANG=C o NO_COLOR=1, o da wrapper di processi come timeout, nice o nohup. Come per le modifiche ai file, l'auto-approvazione si applica solo ai percorsi all'interno della tua directory di lavoro o additionalDirectories. I percorsi al di fuori di questo ambito, le scritture su percorsi protetti, le rimozioni rm e rmdir che prendono di mira un percorso critico, e tutti gli altri comandi Bash tranne il set di sola lettura integrato richiedono comunque conferma.

Quando lo strumento PowerShell è abilitato, la modalità acceptEdits auto-approva anche Set-Content, Add-Content, Clear-Content e Remove-Item su percorsi nell'ambito, insieme ai loro alias comuni. Si applicano le stesse regole di ambito e percorsi protetti, e Remove-Item ottiene il suo proprio controllo. Un argomento posizionale che contiene un carattere di virgolette, come l'apostrofo in Set-Content .\notes.txt "It's done", richiede comunque conferma anche su percorsi nell'ambito, perché Claude Code non può convalidare staticamente un argomento le cui letture tra virgolette e non virgolette differiscono. Passa il contenuto attraverso un parametro denominato come -Value per evitare il prompt.

Utilizza acceptEdits quando desideri revisionare le modifiche nel tuo editor o tramite git diff successivamente, piuttosto che approvare ogni modifica inline.

Premi Shift+Tab una volta dalla modalità Manual per accedervi, o inizia direttamente con essa:

claude --permission-mode acceptEdits

Analizza prima di modificare con la modalità plan

La modalità plan dice a Claude di ricercare e proporre modifiche senza apportarle. Claude legge i file, esegue comandi shell per esplorare e scrive un piano, ma non modifica il tuo codice sorgente. Ad eccezione delle sessioni con autorizzazioni di bypass disponibili, le modifiche rimangono bloccate finché non approvi il piano.

Quando la modalità auto è disponibile e l'impostazione useAutoModeDuringPlan è attiva, che è l'impostazione predefinita, il classificatore esamina i comandi shell durante la pianificazione invece di richiedere conferma. I comandi approvati vengono eseguiti, e quelli rifiutati vengono bloccati. Altrimenti, i comandi al di fuori del set di sola lettura integrato richiedono approvazione, incluso quando la modalità auto-allow della sandbox è abilitata. Nelle sessioni con autorizzazioni di bypass disponibili, né il classificatore né un prompt si applica ai comandi di pianificazione; Ignora tutti i controlli con la modalità bypassPermissions copre le poche cose che richiedono comunque prompt lì. Nella v2.1.212 attraverso v2.1.217, le sessioni senza autorizzazioni di bypass richiedevano conferma per ogni comando al di fuori del set di sola lettura, indipendentemente dal fatto che la modalità auto fosse disponibile.

Accedi alla modalità plan premendo Shift+Tab o anteponendo un singolo prompt con /plan. Puoi anche iniziare in modalità plan dalla CLI:

claude --permission-mode plan

Premi Shift+Tab di nuovo per uscire dalla modalità plan senza approvare un piano.

Rivedi e approva un piano

Quando il piano è pronto, Claude lo presenta e chiede come procedere. Da quel prompt puoi scegliere:

  • Sì, e utilizza la modalità auto: approva e inizia in modalità auto. Quando la modalità auto non è disponibile, questa opzione legge Sì, auto-accetta le modifiche. Se hai avviato la sessione con le autorizzazioni di bypass abilitate, l'opzione legge Sì, e passa a BYPASS PERMISSIONS (nessun ulteriore prompt) per questa sessione invece.
  • Sì, approva manualmente le modifiche: approva e rivedi ogni modifica individualmente.
  • No, continua a pianificare: rimani in modalità plan e dì a Claude cosa cambiare.

Approvare un piano esce dalla modalità plan e passa la sessione alla modalità di autorizzazione che ogni opzione di approvazione descrive, quindi Claude inizia a modificare. Per pianificare di nuovo, cicla di nuovo alla modalità plan con Shift+Tab, o anteponi il tuo prossimo prompt con /plan.

Premi Ctrl+G per aprire il piano proposto nel tuo editor di testo predefinito e modificarlo direttamente prima che Claude proceda. Quando showClearContextOnPlanAccept è abilitato, l'elenco guadagna una prima opzione che approva il piano e cancella il contesto di pianificazione.

Approvare un piano dà anche alla sessione un titolo generato basato sul piano, a meno che tu non abbia già nominato la sessione.

Imposta la modalità plan come impostazione predefinita

Per rendere la modalità plan l'impostazione predefinita per le sessioni di terminale di un progetto, imposta defaultMode su plan in .claude/settings.json, posizionato come l'esempio sotto Inizia in una modalità di autorizzazione diversa mostra. Le conversazioni che l'estensione VS Code avvia non leggono le impostazioni del progetto per la modalità di autorizzazione iniziale. Lì, imposta claudeCode.initialPermissionMode su plan nelle tue impostazioni utente di VS Code invece.

Elimina i prompt di autorizzazione con la modalità auto

La modalità auto consente a Claude di eseguire senza prompt di autorizzazione di routine. Un modello classificatore separato esamina le azioni prima che vengono eseguite, bloccando qualsiasi cosa che vada oltre la tua richiesta, che prenda di mira un'infrastruttura non riconosciuta, o che sembri guidata da contenuti ostili che Claude ha letto. Le regole ask esplicite forzano comunque un prompt.

Sui piani Pro, Max e Team, la modalità auto è la modalità di autorizzazione iniziale integrata.

Il classificatore esamina anche ogni messaggio che Claude invia a un altro agente con SendMessage, sia testo semplice che un messaggio strutturato team di agenti, prima che Claude Code lo consegni, sia in modalità auto che in modalità plan mentre il classificatore esamina i comandi; la revisione dell'invio richiede Claude Code v2.1.222 o successivo.

Il classificatore esamina e approva o blocca anche le rimozioni rm e rmdir che prendono di mira un percorso critico, come rm -rf / e rm -rf ~, incluso quando la rimozione si trova dentro la sostituzione di comando o di processo.

La modalità auto incoraggia anche Claude a continuare a lavorare senza fermarsi per domande di chiarimento, anche se Claude chiede comunque quando il tuo prompt o un skill lo richiedono esplicitamente. Per un comportamento più autonomo in una modalità che ti richiede comunque, imposta lo stile di output proattivo invece.

La modalità auto è disponibile solo quando il tuo account soddisfa tutti questi requisiti:

  • Piano: Tutti i piani.
  • Organizzazione: su Team e Enterprise, la modalità auto è disponibile per impostazione predefinita. Gli amministratori possono disattivarla per l'organizzazione impostando permissions.disableAutoMode su "disable" nelle impostazioni gestite.
  • Modello: sull'API Anthropic e Claude Platform su AWS, Claude Opus 4.6 o successivo, Sonnet 4.6 o successivo, o un modello Fable. Su Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry e sessioni gateway app Claude con accesso, solo Claude Sonnet 5, Opus 4.7 o successivo, e i modelli Fable. I modelli più vecchi, inclusi Sonnet 4.5, Opus 4.5, Haiku e modelli claude-3, non sono supportati su nessun provider.
  • Provider: disponibile per impostazione predefinita sull'API Anthropic, Claude Platform su AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry e sessioni gateway app Claude con accesso.

Se Claude Code segnala che la modalità auto non è disponibile, controlla prima questi requisiti e se un file di impostazioni imposta disableAutoMode. Anthropic potrebbe anche aver disattivato la modalità auto lato server, o il server potrebbe aver rifiutato la modalità auto per il tuo account. Una sessione che ha ricevuto una di queste risposte mantiene la modalità auto disattivata finché la sessione non termina, quindi avvia una nuova sessione in seguito.

Un messaggio separato che nomina un modello e dice che la modalità auto "non può determinare la sicurezza" di un'azione significa che una richiesta del classificatore ha fallito. Quel fallimento è solitamente transitorio, ma su Amazon Bedrock può ripetersi finché il tuo account non può invocare il modello nominato. Vedi il riferimento degli errori per le cause e cosa fare.

Se imposti defaultMode: "auto" nelle impostazioni e una sessione di terminale inizia in modalità Manual senza errore, l'impostazione è probabilmente in .claude/settings.json o .claude/settings.local.json. auto non ha effetto da questi file. Spostalo in ~/.claude/settings.json. Per una conversazione che l'estensione VS Code ha avviato, controlla il proprio elenco dell'estensione in Cambia modalità di autorizzazione invece.

Modalità auto su Bedrock, Agent Platform o Foundry

Su Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry e sessioni gateway app Claude con accesso, la modalità auto appare nel ciclo Shift+Tab per impostazione predefinita. L'apparizione nel ciclo non cambia la modalità di autorizzazione in cui una sessione inizia: su questi provider, le sessioni di terminale iniziano nel tuo defaultMode, che è Manual a meno che non lo modifichi, e le conversazioni nell'estensione VS Code iniziano in Manual a meno che claudeCode.initialPermissionMode o una modalità che hai scelto nell'estensione ne imposti una. Solo Claude Sonnet 5, Opus 4.7 o successivo, e i modelli Fable sono supportati su questi provider.

Per rendere la modalità auto la modalità di autorizzazione iniziale predefinita, imposta "permissions": {"defaultMode": "auto"} nelle impostazioni utente o gestite. Nelle sessioni che l'estensione VS Code avvia, seleziona Auto dall'indicatore di modalità invece. Cambia modalità di autorizzazione copre cosa supera quella scelta.

Il checkup /doctor propone questa impostazione utente su questi provider allo stesso modo che fa sull'API Anthropic.

Per impedire agli sviluppatori di utilizzare la modalità auto, imposta disableAutoMode su "disable" nelle impostazioni gestite. Questo rimuove auto dal ciclo Shift+Tab, e una sessione avviata con --permission-mode auto inizia in Manual invece. Una sessione già in esecuzione in modalità auto la lascia quando l'impostazione raggiunge quella sessione da una fonte distribuita da admin, e mostra auto mode disabled by settings. Prima della v2.1.251, una sessione in esecuzione manteneva la modalità auto finché non terminava.

Nella v2.1.158 attraverso v2.1.206, la modalità auto era disattivata su questi provider finché non impostavi CLAUDE_CODE_ENABLE_AUTO_MODE=1, e Claude Code ignorava defaultMode: "auto" su questi provider a meno che la variabile non fosse anche impostata. La variabile è ancora accettata per compatibilità e non ha effetto da v2.1.207 in poi.

Revisione del classificatore lato server

Su Amazon Bedrock, Google Cloud's Agent Platform e Microsoft Foundry, Claude Code esamina le azioni in modalità auto con le proprie richieste del classificatore per impostazione predefinita. Per fare in modo che il classificatore lato server della piattaforma esamini le azioni che vanno al classificatore come parte delle richieste del modello della sessione invece, imposta CLAUDE_CODE_AUTO_MODE_SERVER=1. Dove la piattaforma esegue il classificatore, i suoi verdetti decidono quelle azioni; dove non lo fa, Claude Code ricade alle proprie richieste del classificatore. Nella v2.1.271 e v2.1.272, chiedere alla piattaforma era l'impostazione predefinita su questi provider.

Cosa blocca il classificatore per impostazione predefinita

Il classificatore si fida della tua directory di lavoro e dei remoti che erano configurati per essa quando la sessione è iniziata. Un remote aggiunto o reindirizzato durante la sessione con git remote add o git remote set-url non è attendibile, e tutto il resto è trattato come esterno finché non configuri l'infrastruttura attendibile. Prima della v2.1.200, i remoti aggiunti a metà sessione erano anche attendibili.

Bloccato per impostazione predefinita:

  • Download ed esecuzione di codice, come curl | bash
  • Invio di dati sensibili a endpoint esterni
  • Deploy e migrazioni di produzione
  • Eliminazione di massa su cloud storage
  • Concessione di autorizzazioni IAM o repo
  • Modifica dell'infrastruttura condivisa
  • Distruzione irreversibile di file che esistevano prima della sessione
  • Force push
  • Commit o push di una modifica che invierebbe segreti o dati sensibili al di fuori del repository quando viene eseguito, o amplia quello che un deploy espone. Questo copre un workflow CI o una configurazione di deploy che passa un segreto a una destinazione che non lo riceve già, uno script o un passaggio di configurazione che legge un archivio di segreti e invia i dati fuori, e una modifica di configurazione che amplia quello che un deploy pubblica, come un registro, visibilità, artefatto o impostazione di sourcemap. Il controllo si applica su qualsiasi ramo, si applica anche quando il repository è pubblico, e si attiva quando la modifica arriva, indipendentemente dal fatto che quella atterraggio attivi la pipeline; cancellarlo richiede di nominare l'effetto di esecuzione, non solo il commit o il push. Prima della v2.1.211, questo controllo era limitato al ramo predefinito invece: un push lì era bloccato quando portava contenuto sensibile, modifiche nascoste o descritte erroneamente rispetto a quello che hai chiesto, contenuto portato dentro da fuori il repository, o instradato intorno a una revisione che hai chiesto
  • git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, o git stash clear, che il classificatore presume scarterebbero le modifiche non committate
  • git commit --amend quando il commit in HEAD non è stato creato in questa sessione
  • Da v2.1.198, git commit --amend quando il commit in HEAD è già stato pushato. Una riscrittura solo del messaggio non è bloccata: --amend -m senza nulla di nuovo in stage, su un commit che Claude ha creato durante questa sessione
  • terraform destroy, pulumi destroy, cdk destroy, o terragrunt destroy, e applicazione di un piano che distrugge risorse

Claude Code v2.1.195 e successivi bloccano più categorie per impostazione predefinita. Diversi dipendono da voci di ambiente, come target remoti sensibili e ambiti IaC protetti, che puoi restringere a nomi concreti.

  • Scrittura su un gestore di segreti, o modifica di record DNS o certificati TLS
  • Merge di una pull request che nessun umano ha approvato, approvazione della propria pull request di Claude, o disabilitazione dei controlli CI
  • Posting di un commento che è esso stesso un comando per l'automazione, come atlantis apply o il /deploy o /merge di un bot
  • Attivazione/disattivazione, ramping o eliminazione di un feature flag di produzione
  • Applicazione di modifiche all'infrastruttura a un ambito IaC protetto, o drenaggio e rimozione di nodi cluster
  • Scritture su un cluster di calcolo condiviso che vanno oltre la risorsa che hai nominato, come un selettore di etichette o --all che cattura i job di altri utenti
  • Creazione di risorse Kubernetes che vengono eseguite su ogni nodo o intercettano il traffico del cluster, come DaemonSets e webhook di ammissione
  • Shell interattive o port-forward in un target remoto sensibile
  • Apertura di un tunnel o reverse shell che rende un servizio locale raggiungibile da internet pubblico
  • Stampa di una credenziale o token live nella trascrizione o in un file
  • Accesso a una posizione elencata come posizione di dati sensibili nel tuo ambiente, o copia di dati da una. A partire da v2.1.198 questo blocca anche l'invio di dati da uno a un pubblico che la voce esclude
  • Instradamento di un'installazione di pacchetto intorno al tuo registro di pacchetti interno a un registro pubblico. A partire da v2.1.198, questo si applica anche quando hai detto a Claude che esiste un registro interno o uno specchio nella conversazione, non solo quando uno è elencato nel tuo ambiente
  • Esecuzione di un comando con un flag che disarma una guardia di sicurezza, come --insecure
  • Lancio di un loop di agente autonomo che viene eseguito senza approvazione umana o sandbox, come uno avviato con --dangerously-skip-permissions o --no-sandbox. A partire da v2.1.198 questo copre anche l'esecuzione di un agente di terze parti o di un harness eval con isolamento e approvazione per azione disabilitati, come un runner avviato con --yes-always
  • Azioni del browser Claude in Chrome che potrebbero inviare contenuto della pagina, cookie o credenziali off-origin

Claude Code v2.1.198 e successivi bloccano anche questi per impostazione predefinita:

  • Eliminazione di file in /tmp, $TMPDIR, o un'altra directory di scratch o cache condivisa per wildcard, glob o filtro di età piuttosto che per un percorso nominato specifico
  • Inclusione di dettagli sensibili nel contenuto inviato, caricato, pubblicato o scritto ad altre persone o sistemi condivisi, quando il tuo stesso messaggio non ha autorizzato quei dettagli per quel destinatario. I corpi di PR e issue, i messaggi di commit e i commenti contano come questo tipo di contenuto in uscita quando il repository è fuori dal confine di fiducia o pubblico, inclusi i tuoi repository pubblici dell'organizzazione; i percorsi di file interni, i nomi in codice, i dati di risposta API live come email o identificatori di account e gli identificatori di infrastruttura contano come dettagli sensibili. Lo scoping di PR, issue e messaggio di commit richiede Claude Code v2.1.200 o successivo. I dati personali live da una risposta API in un corpo di PR o issue, come un indirizzo email, un identificatore di account o organizzazione, o una metrica di utilizzo, richiedono che tu nomini quei dettagli e il destinatario indipendentemente dalla visibilità del repository o dal confine di fiducia. Quel controllo richiede Claude Code v2.1.203 o successivo
  • Invio di pressioni di tasti alla propria pane tmux di Claude Code per guidare la sua stessa interfaccia, che il classificatore tratta come Claude che cambia le sue stesse autorizzazioni o supervisione

Claude Code v2.1.200 e successivi bloccano anche questi per impostazione predefinita:

  • Commento, eliminazione o force-pass di un test o asserzione che protegge il comportamento di sicurezza, come autenticazione, controllo di accesso, convalida dell'input o sandboxing
  • Eliminazione o smantellamento di una risorsa stateful che Claude non ha creato nella sessione, quando nessuna regola di eliminazione più specifica si applica e non hai nominato quella risorsa
  • Reindirizzamento di un URL di base API, endpoint proxy, ricevitore webhook o specchio di registro a un host di terze parti che non si adatta al compito, incluso nei file di esempio come .env.example
  • Modifica di dove vanno i push con git remote set-url o git remote add, a meno che tu non abbia nominato il nuovo remote
  • Push di segreti o dati personali o affidati a un repository noto per essere pubblico, o push di materiale confidenziale lì che non fa parte del lavoro proprio di quel repository. L'argomento proprio di un repository dotfiles è l'unica eccezione per dati personali o affidati, e il contenuto da un repository privato che raggiunge qualsiasi superficie pubblica è bloccato allo stesso modo; entrambi i perfezionamenti richiedono Claude Code v2.1.203 o successivo. Prima di v2.1.203, i dati personali erano raggruppati con materiale confidenziale e bloccati solo quando non facevano parte del lavoro proprio di quel repository. Quando la visibilità di un repository non è stabilita, il classificatore non blocca solo su quello; giudica il contenuto rispetto alle altre regole invece
  • Apertura di una pull request contro un repository o organizzazione diversa, fork con gh repo fork, o push a un repository di terze parti, a meno che tu non abbia nominato quel target esterno

Claude Code v2.1.203 e successivi bloccano anche questi per impostazione predefinita:

  • Contenuto da un archivio locale sensibile, o da un file il cui nome, percorso o tipo lo contrassegna come sensibile, che entra in un commit, un push, testo di PR o issue, un gist o paste, o una pubblicazione di pacchetto, a meno che tu non abbia nominato sia la fonte che la destinazione. Le trascrizioni di sessione e i log di conversazione, le cartelle dot di credenziali e configurazione come chiavi SSH, credenziali cloud, profili browser e cronologia shell, e gli export di dati utente contano tutti, e il fatto che il repository sia privato non lo esenta

Claude Code v2.1.205 e successivi bloccano anche questi per impostazione predefinita:

  • Scrittura nelle trascrizioni di sessione di Claude Code, i file di cronologia .jsonl sotto ~/.claude/projects/ o la tua directory di configurazione configurata, direttamente o tramite un comando shell. La regola copre anche le righe di metadati che Claude Code aggiunge a ogni voce di trascrizione per i suoi stessi controlli. La lettura di una trascrizione non è bloccata
  • Un'eliminazione forzata ricorsiva come rm -rf "$VAR" o Remove-Item -Recurse -Force $dir il cui target è una variabile shell, o un glob radicato in uno, che non è assegnato da nessuna parte nella conversazione che il classificatore vede. Il valore proveniva solo dall'output del comando precedente, che il classificatore non riceve mai, quindi il classificatore non può verificare il target di eliminazione rispetto alle altre regole di eliminazione. Il blocco si cancella quando nomini il percorso esatto che viene eliminato, o quando Claude riesegue l'eliminazione con il percorso letterale risolto scritto nel comando. Le eliminazioni il cui target il classificatore può risolvere non sono interessate. I target Remove-Item che sono un * nudo o terminano in /* o \* non raggiungono mai il classificatore: Claude Code li nega direttamente

Claude Code v2.1.257 e successivi bloccano anche questi per impostazione predefinita:

  • Richiesta di credenziali dall'endpoint dei metadati dell'istanza cloud, come 169.254.169.254, o autenticazione esplicita di una chiamata cloud, cluster o registro con l'identità dell'account di servizio o del nodo della macchina
  • Raggiungimento di un host pubblico da una rotta diversa da una richiesta diretta, come un tunnel, una reverse shell, o una configurazione di resolver o proxy riscritta per puntare al di fuori
  • Lettura di credenziali che appartengono all'host piuttosto che al tuo compito, come certificati di nodo o l'auth del registro di container del nodo
  • Connessione a o scansione di container, pod o VM fratelli che Claude non ha avviato, o il nodo sotto il container

Se Claude Code viene eseguito da qualche parte che intende consentire uno di questi, descrivi quella configurazione in una voce Host containment in autoMode.environment.

Claude Code v2.1.261 e successivi bloccano anche questi per impostazione predefinita:

  • Posting o scrittura di un link a un servizio pubblico di paste, diagramma o condivisione dati in un messaggio, testo di PR o issue, un documento, o ovunque il link verrà aperto o recuperato, quando l'URL stesso porta il contenuto condiviso, a meno che tu non abbia nominato quel servizio

Consentito per impostazione predefinita:

  • Operazioni di file locali nella tua directory di lavoro
  • Installazione di dipendenze dichiarate nei tuoi file di lock o manifest
  • Lettura di .env e invio di credenziali al loro API corrispondente
  • Richieste HTTP di sola lettura
  • Push a qualsiasi ramo del repository su cui stai lavorando, incluso il ramo predefinito. Un ramo non predefinito il cui nome lo contrassegna come target di deploy o pubblicazione, come production o gh-pages, non è coperto: il classificatore giudica un push lì sui suoi stessi termini. Il contenuto del push è ancora controllato rispetto alle altre regole, le regole permissions.deny possono comunque bloccare i comandi push come scritti in ogni modalità, e la protezione del ramo del remote si applica comunque. Prima della v2.1.211, solo i push al ramo su cui hai iniziato, i rami che Claude ha creato, e i push di routine al ramo predefinito erano consentiti per impostazione predefinita, e prima della v2.1.203 qualsiasi push diretto al ramo predefinito era bloccato

Claude Code v2.1.195 e successivi consentono anche questi per impostazione predefinita:

  • Eliminazione dei job esatti che Claude ha creato in precedenza nella stessa sessione
  • Lettura, revisione o scrittura di codice, config e modelli di minaccia relativi alla sicurezza come parte del tuo compito
  • Messaggi tra agenti che lavorano insieme nella stessa sessione multi-agente
  • Invio di dati ai domini, bucket e servizi attendibili che elenchi in environment. Questo copre il flusso di dati solo, non operazioni distruttive o di credenziali sulla stessa infrastruttura
  • Navigazione Claude in Chrome a un dominio interno attendibile, localhost, o un URL che hai nominato

I comandi in sandbox non ottengono accesso alla rete per impostazione predefinita. Claude nomina gli host che un comando necessita sul comando stesso, il classificatore li esamina con il comando, e un elenco approvato apre quegli host per quel solo comando. Domini consentiti per comando copre cosa un elenco può e non può aprire e cosa succede quando un comando raggiunge per un host non elencato.

Esegui claude auto-mode defaults per stampare gli elenchi di regole completi come JSON. Se le azioni di routine vengono bloccate, un amministratore può aggiungere repo, bucket e servizi attendibili tramite l'impostazione autoMode.environment: vedi Configura modalità auto.

Il push a qualsiasi ramo del repository su cui stai lavorando e la creazione di una pull request che corrisponde alla tua richiesta vengono eseguiti senza un prompt, a meno che il push o la pull request non rientri nell'elenco bloccato, come segreti o dati sensibili che lasciano il repository, o una pull request che prende di mira un repository o organizzazione diversa. Per richiedere un checkpoint umano prima di queste azioni mentre rimani in modalità auto, aggiungi regole permissions.ask: vedi Confini comuni.

La prima lettura al di fuori delle directory di lavoro

Mentre permissions.blockReadsOutsideWorkingDirectories è disattivato, le letture di file vengono eseguite senza un prompt in modalità auto, incluse le letture al di fuori delle directory di lavoro. La prima volta che Claude utilizza lo strumento Read, Grep o Glob su un percorso al di fuori di esse, Claude Code ti chiede se continuare a consentire quelle letture.

Il prompt non appare nelle esecuzioni non interattive -p o nelle sessioni in background; le letture lì vengono eseguite come prima.

Qualunque cosa tu risponda, Claude continua a lavorare:

  • Continua a consentire: la lettura viene eseguita, le letture successive al di fuori delle directory di lavoro vengono eseguite come prima, e Claude Code registra la tua risposta in modo che il prompt non appaia di nuovo
  • Blocca da ora in poi: la lettura viene rifiutata, e Claude Code imposta permissions.blockReadsOutsideWorkingDirectories su true nelle tue impostazioni utente, che fa sì che gli strumenti di file rifiutino tali letture in ogni sessione successiva e in ogni modalità di autorizzazione. Per consentire a Claude di leggere tale percorso in seguito, aggiungi la sua directory con /add-dir o rimuovi l'impostazione.
  • Chiedi di nuovo la prossima volta: la lettura viene rifiutata, e la prossima lettura al di fuori delle directory di lavoro richiede di nuovo

Confini che dichiari nella conversazione

Il classificatore tratta i confini che dichiari nella conversazione come un segnale di blocco. Se dici a Claude "non pushare" o "aspetta che io riveda prima di deployare", il classificatore blocca le azioni corrispondenti anche quando le regole predefinite le consentirebbero. Un confine rimane in vigore fino a quando non lo sollevi in un messaggio successivo. Il giudizio proprio di Claude che una condizione era soddisfatta non lo solleva.

I confini non vengono archiviati come regole. Il classificatore li rilegge dalla trascrizione su ogni controllo, quindi un confine può andare perso se la compattazione del contesto rimuove il messaggio che lo ha dichiarato. Per una garanzia dura, aggiungi una regola deny invece.

Quando la modalità auto passa ai prompt manuali

Quando la modalità auto non può approvare le azioni della tua sessione, cosa succede dipende dal caso:

  • Un'azione bloccata: Claude Code mostra una notifica e elenca l'azione in /permissions sotto la scheda Recently denied, dove puoi premere r per ritentarla con un'approvazione manuale. Quando il classificatore produce nessun verdetto sull'azione, perché un controllo di sicurezza separato dalla modalità auto ha rifiutato la richiesta del classificatore o la sua risposta non è stata analizzata, Claude Code nega l'azione senza la notifica o la voce Recently denied.
  • Blocchi ripetuti: se il classificatore blocca un'azione 3 volte di seguito o 20 volte in totale, la modalità auto si mette in pausa e Claude Code riprende a richiedere. L'approvazione dell'azione richiesta riprende la modalità auto. Questi soglie non sono configurabili. Qualsiasi azione consentita ripristina il contatore consecutivo, mentre il contatore totale persiste per la sessione e si ripristina solo quando il suo limite attiva un fallback. Claude Code non conta un diniego verso nessuno dei due soglie quando un controllo di sicurezza separato dalla modalità auto rifiuta la richiesta del classificatore; la voce collegata copre come Claude Code gestisce quei dinieghi.
  • Sessioni che non possono richiedere: un'esecuzione non interattiva -p senza un --permission-prompt-tool non ha un prompt a cui ricorrere. Quando i blocchi ripetuti raggiungono una soglia, l'azione non viene eseguita e Claude continua a lavorare. Lo stesso si applica quando un controllo di sicurezza separato dalla modalità auto rifiuta la richiesta del classificatore. Claude Code non ferma l'esecuzione in nessuno dei due casi.
  • Un cambio di modalità durante un controllo: se cambi le modalità di autorizzazione mentre un controllo del classificatore è in sospeso, Claude Code scarta un verdetto che la nuova modalità non avrebbe richiesto piuttosto che applicarlo: sei richiesto per l'approvazione invece, o l'azione viene auto-negata in modalità dontAsk.

I blocchi ripetuti di solito significano che il classificatore manca di contesto sulla tua infrastruttura. Usa /feedback per segnalare falsi positivi, o fai in modo che un amministratore configuri l'infrastruttura attendibile.

Ogni azione passa attraverso un ordine di decisione fisso. Il primo passaggio corrispondente vince: 
1. Le azioni che corrispondono alle tue [regole allow, ask, o deny](/docs/it/permissions#manage-permissions) si risolvono immediatamente, con queste eccezioni:
   * Scritture su [percorsi protetti](#protected-paths) vengono instradate al classificatore anche quando una regola allow corrisponde, e così fanno le rimozioni `rm` e `rmdir` che prendono di mira un [percorso critico](#critical-paths) in Claude Code v2.1.218 e successivi
   * Gli strumenti MCP contrassegnati [`requiresUserInteraction`](/docs/it/mcp#require-approval-for-a-specific-tool) ti chiedono direttamente anche quando una regola allow corrisponde, e così fanno gli strumenti connector [che la tua organizzazione ha impostato su `ask`](/docs/it/mcp#organization-controls-on-connector-tools) in sessioni dove quella impostazione raggiunge Claude Code
   * Un comando shell che porta [domini consentiti per comando](/docs/it/sandboxing#per-command-allowed-domains-in-auto-mode) viene anche instradato al classificatore anche quando una regola allow corrisponde, perché una regola approva il comando, non i suoi host
   * Le regole ask che corrispondono sul contenuto di un comando, come `Bash(git push *)`, ricadono in un [prompt di autorizzazione](/docs/it/permissions#bash-rule-limits)
2. Le azioni di sola lettura e le modifiche di file nella tua directory di lavoro vengono auto-approvate, tranne le scritture su [percorsi protetti](#protected-paths) e [la prima lettura al di fuori delle directory di lavoro](#first-read-outside-the-working-directories), che ti richiede
3. Tutto il resto va al classificatore. Gli strumenti connector e gli strumenti MCP contrassegnati [`requiresUserInteraction`](/docs/it/mcp#require-approval-for-a-specific-tool) che ti chiedono direttamente nel passaggio 1 non raggiungono mai il classificatore, quindi un'approvazione richiesta dall'organizzazione o un passaggio di consenso non viene mai auto-approvato
4. Se il classificatore blocca, Claude riceve il motivo e prova un'alternativa. Nella maggior parte delle sessioni il motivo indica la regola a cui il classificatore ha trovato corrispondenza, ad esempio `[Data Exfiltration]`, invece di fornire una spiegazione scritta; vedi [Rivedi i dinieghi](/docs/it/auto-mode-config#review-denials)

Entrando in modalità auto, le regole allow ampie che concedono l'esecuzione arbitraria di codice vengono eliminate:

* Blanket `Bash(*)` o `PowerShell(*)`
* Interpreti con wildcard come `Bash(python*)`
* Comandi di esecuzione del gestore di pacchetti
* Regole allow `Agent`
* Regole allow [`Monitor`](/docs/it/tools-reference#monitor-tool), perché Claude Code esegue i comandi Monitor attraverso la shell

Le regole strette come `Bash(npm test)` vengono trasportate. Claude Code ripristina le regole eliminate quando esci dalla modalità auto. Prima della v2.1.236, Claude Code lasciava le regole allow `Monitor` in vigore in modalità auto, quindi una regola che corrispondeva all'intero strumento approvava i comandi Monitor senza revisione del classificatore.

Claude Code esegue anche `git status` stesso prima di un comando che scarterebbero il lavoro non committato, come `git reset --hard` o `rm -rf`, e mostra al classificatore se il lavoro in stage, modificato o non tracciato è presente. Claude Code segnala i file non tracciati in quel controllo anche quando la configurazione git del repository imposta `status.showUntrackedFiles=no`.

Nelle richieste del classificatore inviate da Claude Code stesso, il classificatore vede i messaggi dell'utente, le chiamate di strumenti diverse dalle ricerche di sola lettura come letture di file e ricerche, e il tuo contenuto CLAUDE.md. I risultati degli strumenti vengono rimossi, quindi il contenuto ostile in un file o pagina web non può manipolarlo direttamente. Puoi annotare il risultato di una chiamata con il campo `classifierContext` di un hook [PostToolUse](/docs/it/hooks#annotate-a-result-for-the-auto-mode-classifier), che il classificatore legge come contesto fornito dall'applicazione. Il campo richiede Claude Code v2.1.236 o successivo.

Una sonda separata lato server scansiona i risultati degli strumenti in arrivo e contrassegna il contenuto sospetto prima che Claude lo legga. Per ulteriori informazioni su come questi strati lavorano insieme, vedi l'[annuncio della modalità auto](https://claude.com/blog/auto-mode) e il [deep dive di ingegneria](https://www.anthropic.com/engineering/claude-code-auto-mode).
Come la modalità auto gestisce i subagent

Il classificatore controlla il lavoro dei subagent in tre punti:

  1. Prima che un subagent inizi, la descrizione del compito delegato viene valutata, quindi un compito che sembra pericoloso viene bloccato al momento dello spawn.
  2. Mentre il subagent viene eseguito, ognuna delle sue azioni passa attraverso il classificatore con le stesse regole della sessione padre, e qualsiasi permissionMode nel frontmatter del subagent viene ignorato.
  3. Quando il subagent finisce, il classificatore esamina il suo lavoro e il suo rapporto finale prima che il padre legga il rapporto. Quando il classificatore contrassegna il lavoro o il rapporto del subagent, o un controllo di sicurezza API separato rifiuta la revisione, il rapporto viene comunque consegnato, anteposto con un avviso di sicurezza. Quando il classificatore non è disponibile per la revisione, il rapporto arriva con una nota per verificare il lavoro del subagent prima di agire su di esso.

Il passaggio 1 richiede Claude Code v2.1.178 o successivo. Le versioni precedenti applicavano il classificatore ai passaggi 2 e 3, ma non valutavano la descrizione del compito prima che il subagent iniziasse.

Costo e latenza

Il classificatore viene eseguito su Claude Sonnet 5 per impostazione predefinita piuttosto che sulla tua selezione /model. Un modello classificatore che Anthropic configura lato server ha la precedenza su quella impostazione predefinita. Quando il modello della tua sessione è Claude Sonnet 4.6, o quando availableModels esclude Sonnet 5, il classificatore viene eseguito sul modello della sessione invece, o su un modello Opus quando la sessione viene eseguita su un modello Fable; su provider diversi dall'API Anthropic, quel fallback Opus è il modello Opus predefinito del provider.

La prima richiesta in modalità auto della sessione convalida l'impostazione predefinita di Sonnet 5: se la richiesta ha successo, Sonnet 5 rimane il modello classificatore della sessione, e se fallisce perché il modello non è disponibile, la sessione utilizza il fallback invece. Dopo che quella convalida si stabilizza, il modello del classificatore non cambia per la sessione.

Su piani Enterprise e su account che utilizzano l'API Claude, Claude Platform su AWS, Amazon Bedrock, Google Cloud's Agent Platform, o Microsoft Foundry, le chiamate del classificatore contano verso il tuo utilizzo di token. Ogni controllo invia una porzione della trascrizione più l'azione in sospeso, aggiungendo un round-trip prima dell'esecuzione. Le letture e le modifiche della directory di lavoro al di fuori dei percorsi protetti saltano il classificatore, quindi l'overhead proviene principalmente da comandi shell e operazioni di rete. Su Amazon Bedrock, Google Cloud's Agent Platform e Microsoft Foundry, puoi spostare la revisione nelle richieste del modello della sessione invece; vedi Revisione del classificatore lato server.

L'accesso alla rete in sandbox non aggiunge richieste del classificatore per connessione. Il classificatore giudica gli host che un comando nomina insieme al comando in una revisione, e Claude Code controlla ogni connessione rispetto all'elenco approvato senza chiamare il classificatore di nuovo.

Consenti solo strumenti pre-approvati con la modalità dontAsk

Se imposti la modalità dontAsk, Claude Code nega automaticamente ogni chiamata di strumento che altrimenti richiederebbe una richiesta. Claude esegue ancora azioni che non richiedono approvazione in modalità Manual, come le letture di file all'interno delle tue directory di lavoro e i comandi Bash di sola lettura, più le azioni che corrispondono alle tue regole permissions.allow e le chiamate approvate da un hook PreToolUse. Utilizza questa modalità per pipeline CI o ambienti limitati in cui pre-definisci cosa Claude può fare; la sessione non attende mai input. La barra di stato mostra ⏵⏵ don't ask on mentre questa modalità è attiva.

Claude Code nega le chiamate che corrispondono alle tue regole ask esplicite piuttosto che richiedere una conferma. Nega anche lo strumento integrato AskUserQuestion anche se le tue regole di autorizzazione lo corrispondono, e fa lo stesso agli strumenti connector che la tua organizzazione ha impostato su ask in sessioni dove quella impostazione raggiunge Claude Code. Nega gli strumenti MCP contrassegnati _meta["anthropic/requiresUserInteraction"] allo stesso modo, perché la loro scheda di approvazione necessita di una risposta che questa modalità non raccoglie mai; questo richiede Claude Code v2.1.199 o successivo.

Le rimozioni rm e rmdir che prendono di mira un percorso critico, come rm -rf / e rm -rf ~, vengono negate anche quando una regola allow le corrisponde o un hook PreToolUse le approva.

Le sessioni cloud su Claude Code sul web ignorano defaultMode: "dontAsk"; vedi bypassPermissions per i dettagli.

Impostalo all'avvio con il flag:

claude --permission-mode dontAsk

Ignora tutti i controlli con la modalità bypassPermissions

La modalità bypassPermissions disabilita i prompt di autorizzazione e i controlli di sicurezza in modo che le chiamate agli strumenti vengono eseguite immediatamente, incluse le scritture su percorsi protetti.

Le azioni che nessuna modalità auto-approva richiedono comunque un prompt in questa modalità.

Due protezioni di messaggistica cross-sessione si applicano comunque in questa modalità, e in sessioni in modalità plan interattive dove le autorizzazioni di bypass sono disponibili:

  • Il prompt di approvazione isolatePeerMachines per i messaggi alle tue sessioni oltre questa macchina appare comunque.
  • Quando nessun valore crossSessionInbound si applica, Claude Code tiene un messaggio in arrivo da un'altra delle tue sessioni per la tua approvazione, e consegna senza chiedere solo quando la sessione di invio si identifica come anche bypassando i prompt di autorizzazione. Se lasci la modalità di autorizzazione mentre i messaggi sono tenuti, Claude Code riapplica le regole in arrivo e consegna qualsiasi messaggio tenuto che ora accettano.

Nelle sessioni di terminale interattive con autorizzazioni di bypass disponibili, Claude Code inoltre non applica i blocchi della modalità plan. Claude è ancora istruito a pianificare senza modificare, ma una modifica di file o un comando shell che tenta durante la pianificazione viene eseguito senza richiedere. Le regole ask esplicite e le rimozioni rm e rmdir che prendono di mira un percorso critico richiedono comunque un prompt.

La modalità plan mantiene i suoi blocchi ovunque Claude Code viene eseguito senza un terminale interattivo, incluse le esecuzioni non interattive con -p, le sessioni Agent SDK, e le conversazioni nel pannello chat dell'estensione VS Code. Lì, --allow-dangerously-skip-permissions rende bypassPermissions selezionabile in seguito.

Non puoi accedere a bypassPermissions da una sessione che hai avviato senza di essa abilitata. Abilitala al lancio con permissions.defaultMode: "bypassPermissions" o con un flag di abilitazione:

claude --permission-mode bypassPermissions

Il flag --dangerously-skip-permissions è equivalente.

Claude Code rifiuta bypassPermissions in una sessione che avvii con --restricted. --restricted richiede Claude Code v2.1.248 o successivo.

La prima volta che avvii una sessione interattiva con questa modalità abilitata, Claude Code mostra una finestra di dialogo di avviso che ti chiede di accettare la responsabilità per le azioni intraprese senza controlli di autorizzazione. Claude Code salva la tua accettazione nelle impostazioni utente, quindi la finestra di dialogo appare solo una volta. Se rifiuti, Claude Code esce. In modalità non interattiva nessuna finestra di dialogo viene mostrata, e una sessione in background avviata con --bg viene rifiutata finché non hai accettato la finestra di dialogo in una sessione interattiva.

Su Linux e macOS, Claude Code rifiuta di avviarsi in questa modalità quando viene eseguito come root o sotto sudo:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Il controllo viene saltato automaticamente all'interno di una sandbox riconosciuta. Per eseguire in modo autonomo in un container, utilizza la configurazione dev container, che esegue Claude Code come utente non root.

Claude Code sul web non rispetta defaultMode: "bypassPermissions" o "dontAsk" dai file di impostazioni, quindi le impostazioni archiviate di un repository non possono avviare una sessione cloud in modalità bypass-permissions. L'impostazione viene ignorata silenziosamente e la sessione si avvia nella modalità mostrata nel menu a discesa della modalità. Vedi Cambia modalità di autorizzazione per le modalità offerte dalle sessioni cloud.

Percorsi protetti

Le scritture in un piccolo insieme di percorsi non vengono mai auto-approvate, tranne in modalità bypassPermissions e in sessioni in modalità plan dove le autorizzazioni di bypass sono disponibili. Ciò previene la corruzione accidentale dello stato del repository e della configurazione di Claude.

Modalità Scritture su percorsi protetti
default, acceptEdits Richiesta di conferma
plan Consentito in sessioni con autorizzazioni di bypass disponibili. Altrimenti, instradato al classificatore quando la modalità auto è disponibile durante la pianificazione, e richiesto quando non lo è
auto Instradato al classificatore
dontAsk Negato
bypassPermissions Consentito

In una sessione avviata con --restricted, che richiede Claude Code v2.1.248 o successivo, il classificatore non può approvare le scritture su percorsi protetti.

Le regole permissions.allow nei file di impostazioni non pre-approvano le scritture su percorsi protetti. Il controllo di sicurezza viene eseguito prima che Claude Code valuti le regole allow dalle impostazioni, quindi una voce come Edit(.claude/**) in ~/.claude/settings.json o .claude/settings.json non modifica il risultato per modalità nella tabella precedente. Nelle modalità che richiedono conferma, il prompt per una scrittura .claude/ offre Sì, e consenti a Claude di modificare le proprie impostazioni per questa sessione, che approva le successive scritture .claude/ in quella sessione senza richiedere di nuovo la conferma.

Directory protette:

  • .git
  • .config/git
  • .vscode
  • .idea
  • .husky
  • .cargo
  • .devcontainer
  • .yarn
  • .mvn
  • .claude, ad eccezione di .claude/worktrees dove Claude memorizza i propri git worktrees

File protetti:

  • .gitconfig, .gitmodules
  • .bashrc, .bash_profile, .bash_login, .bash_aliases, .bash_logout, .zshrc, .zprofile, .zshenv, .zlogin, .zlogout, .profile, .envrc
  • .npmrc, .yarnrc, .yarnrc.yml, .pnp.cjs, .pnp.loader.mjs, .pnpmfile.cjs, bunfig.toml, .bunfig.toml
  • .bazelrc, .bazelversion, .bazeliskrc
  • .pre-commit-config.yaml, lefthook.yml, lefthook.yaml, .lefthook.yml, .lefthook.yaml
  • gradle-wrapper.properties, maven-wrapper.properties
  • .devcontainer.json
  • .ripgreprc, pyrightconfig.json
  • .mcp.json, .claude.json

Percorsi critici

Claude Code non consente mai a una regola permissions.allow o a un hook PreToolUse che restituisce "allow" di approvare un comando rm o rmdir che prende di mira un percorso critico, anche in modalità che saltano altri prompt. Questo interruttore di circuito protegge contro l'errore del modello. Una regola di negazione corrispondente blocca comunque il comando completamente.

Cosa succede invece dipende dalla tua modalità di autorizzazione:

Modalità Cosa Claude Code fa con una rimozione di percorso critico
default, acceptEdits Ti chiede di approvarlo
plan Ti chiede di approvarlo. Con la modalità auto disponibile durante la pianificazione e nessuna autorizzazione di bypass disponibile, lo invia al classificatore invece
auto Lo invia al classificatore
dontAsk Lo nega
bypassPermissions Ti chiede di approvarlo

Se una regola ask esplicita corrisponde al comando, Claude Code ti chiede anche in modalità auto. Nelle modalità che chiedono, un hook PermissionRequest può rispondere al prompt come risponde a qualsiasi altro.

Claude Code tratta un target rm o rmdir come un percorso critico quando è uno dei seguenti:

  • La radice del filesystem
  • Directory di primo livello, il che significa qualsiasi figlio diretto della radice, come /usr, /etc, o /data
  • La tua directory home
  • Radici di unità Windows e le loro directory di primo livello, come C:\ e C:\Windows
  • La tua directory di lavoro e i suoi genitori
  • Le tue directory di lavoro aggiuntive e i loro genitori, ma solo quando la rimozione è un glob sotto uno di essi, come rm -rf <dir>/*. rm -rf <dir> sulla directory stessa non attiva questo controllo

Claude Code tratta anche un glob o una barra finale direttamente sotto una variabile shell, come rm -rf "$DIR"/*, come una rimozione di percorso critico, perché il comando diventa una rimozione dalla radice del filesystem quando la variabile è vuota.

Nascondere la rimozione dentro una subshell con (...), un gruppo di parentesi graffe con { ...; }, la sostituzione di comando con $(...) o backtick, o la sostituzione di processo con <(...), non salta il controllo. Claude Code trova una rimozione di percorso critico indipendentemente dal fatto che si trovi dentro la forma annidata, come in (rm -rf ~) o echo "$(rm -rf ~)", o altrove nello stesso comando.

Remove-Item in PowerShell

Quando abiliti lo strumento PowerShell, Claude Code dà a Remove-Item il suo proprio controllo, separato dall'elenco di percorsi critici rm. Il risultato dipende dal target, e il primo caso corrispondente si applica:

  • Percorsi di sistema: la radice del filesystem e le sue directory di primo livello, le radici di unità e le loro directory di primo livello, e la tua directory home. Claude Code nega il comando in ogni modalità, senza chiederti.
  • Wildcard: un * nudo, o qualsiasi target che termina in /* o \*, incluso un glob sotto una variabile shell come $dir/*. Claude Code nega il comando in ogni modalità, senza chiederti, prima che il classificatore lo veda.
  • La tua directory di lavoro o uno dei suoi genitori, con -Recurse: Claude Code tratta il comando come qualsiasi altro che necessita di approvazione nella tua modalità di autorizzazione, quindi ti chiede nelle modalità che chiedono, lo invia al classificatore in modalità auto, e lo nega in modalità dontAsk. La modalità bypassPermissions salta questo controllo.

Vedi anche

  • Permissions: regole allow, ask e deny; politiche gestite
  • Configure auto mode: comunica al classificatore quale infrastruttura la tua organizzazione ritiene affidabile
  • Hooks: logica di autorizzazione personalizzata tramite hook PreToolUse e PermissionRequest
  • Security: protezioni e best practice
  • Sandboxing: isolamento del filesystem e della rete per i comandi Bash
  • Non-interactive mode: esegui Claude Code con il flag -p