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.

VS Code

Durante una sessione: fai clic sull'indicatore di modalità nella parte inferiore della casella del prompt. Utilizza queste etichette per le modalità in questa pagina:

Come predefinito: per fissare la modalità di autorizzazione con cui iniziano le conversazioni, imposta claudeCode.initialPermissionMode nelle impostazioni utente di VS Code su default, manual, acceptEdits, plan, o bypassPermissions. L'impostazione non accetta auto; per iniziare in Auto, lasciala non impostata e seleziona Auto dall'indicatore di modalità una volta, come descrive l'elemento 2 di seguito. L'estensione inizia ogni nuova conversazione nel primo di questi che si applica:

1. claudeCode.initialPermissionMode
2. La modalità che hai selezionato per ultimo dall'indicatore di modalità, se era Manual, Edit automatically, o Auto. Selezionare Plan o Bypass permissions si applica solo a quella conversazione
3. permissions.defaultMode da impostazioni gestite o ~/.claude/settings.json
4. Il predefinito incorporato per il tuo piano, provider e impostazioni dell'organizzazione

L'estensione non legge mai il .claude/settings.json o .claude/settings.local.json di un progetto per la modalità di autorizzazione iniziale. Quando claudeCode.claudeProcessWrapper è impostato, gli elementi 3 e 4 non si applicano: quelle conversazioni iniziano in Manual a meno che l'elemento 1 o l'elemento 2 non imposti una modalità di autorizzazione.

Prima di v2.1.283, l'elemento 3 si applicava solo su piani Pro, Max e Team in sessioni che recuperano feature flag.

Auto appare nell'indicatore di modalità quando auto mode è disponibile.

Bypass permissions richiede l'interruttore Allow dangerously skip permissions nelle impostazioni dell'estensione. Senza di esso, la modalità di autorizzazione non appare nell'indicatore, e un valore bypassPermissions dall'elemento 1 o dall'elemento 3 inizia la conversazione in Manual invece. Auto da qualsiasi elemento allo stesso modo inizia la conversazione in Manual quando la modalità auto non è disponibile.

Vedi la guida VS Code per i dettagli specifici dell'estensione.

JetBrains

Il plugin JetBrains esegue Claude Code nel terminale dell'IDE, quindi il cambio delle modalità di permesso funziona come nella CLI: premi Shift+Tab per scorrerle ciclicamente, o passa --permission-mode al lancio.

Desktop

Durante una sessione: nella scheda Code, utilizza il selettore di modalità nella riga sotto la casella del prompt. Non tutte le modalità appaiono nel selettore:

• Auto: appare quando auto mode è disponibile
• Bypass permissions: richiede l'interruttore Allow bypass permissions mode nelle impostazioni Desktop su piani Pro e Max; su piani Team e Enterprise, la politica dell'organizzazione la controlla invece

Cowork non utilizza queste modalità. Ha le sue proprie modalità di permesso, abilitate separatamente, e non mostra alcun selettore di modalità finché una modalità oltre quella predefinita non viene abilitata per il tuo account. Vedi la documentazione Cowork.

Per i dettagli specifici del desktop, vedi Scegli una modalità di autorizzazione nella guida Desktop.

Come predefinito: imposta defaultMode in impostazioni. L'app desktop legge gli stessi file di impostazioni della CLI e applica la modalità di autorizzazione alle nuove sessioni locali.

Una modalità che scegli nel selettore di modalità viene ricordata per cartella e ha la precedenza su defaultMode per quella cartella. Plan è l'eccezione: selezionarla si applica solo alla sessione corrente.

Per sapere dove va defaultMode in un file di impostazioni, consulta l'esempio in Inizia in una modalità di permesso diversa.

Web and mobile

Su claude.ai/code, utilizza il menu a discesa della modalità nella riga sotto la casella del prompt. Nell'app mobile, tocca il pulsante + nella casella del prompt, poi Permission. Le sessioni cloud e le sessioni Remote Control offrono modalità di permesso diverse:

• Sessioni cloud: Accept edits, Plan e Auto. Accept edits corrisponde alla modalità default: le sessioni cloud pre-approvano le modifiche ai file indipendentemente dalla modalità, quindi il menu a discesa mostra Accept edits invece di Manual. Le sessioni cloud rispettano comunque defaultMode: "acceptEdits" dalle impostazioni. La modalità auto appare solo quando la tua organizzazione la consente e il modello selezionato la supporta. Bypass permissions non è disponibile.
• Sessioni Remote Control sulla tua macchina locale: Manual, Accept edits, Plan e Auto per una sessione che hai avviato tu stesso, e non puoi selezionare Bypass permissions dall'app. Per usare Auto, la sessione deve soddisfare i requisiti di disponibilità della modalità auto. Per un thread di progetto in esecuzione sul tuo computer, consulta Esegui un thread sul tuo computer.
  • Ad eccezione di Bypass permissions, il menu a discesa mostra la modalità di permesso in cui si trova la sessione locale, inclusa una impostata dal terminale. Si aggiorna quando la modalità di permesso cambia nell'app o nel terminale.
  • Le sessioni ospitate dall'app desktop o dall'estensione VS Code segnalano i cambiamenti della modalità di permesso a claude.ai man mano che avvengono, come le sessioni ospitate in un terminale.

Per Remote Control, la macchina locale che esegue la sessione deve essere connessa con il tuo account claude.ai; le chiavi API non sono supportate. Puoi anche impostare la modalità di autorizzazione iniziale al lancio di quella sessione locale:

claude remote-control --permission-mode acceptEdits

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. Ad eccezione di touch, questi comandi vengono anche auto-approvati quando preceduti da variabili d'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.

Questi richiedono comunque conferma:

• I percorsi al di fuori di tale ambito
• Le scritture su percorsi protetti
• Le rimozioni di percorsi critici riconosciute con rm e rmdir
• touch con qualsiasi elemento oltre a semplici percorsi di file, ad esempio un'opzione, un glob o un prefisso come timeout 5 o LANG=C
• Tutti gli altri comandi Bash tranne il set di sola lettura integrato

Ogni percorso passa anche attraverso il controllo dei collegamenti simbolici, quindi nemmeno una scrittura che si risolve al di fuori di tale ambito viene auto-approvata.

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 di terminale interattivo con autorizzazioni di bypass disponibili, le modifiche rimangono bloccate finché non approvi il piano.

Cosa accade a un comando shell durante la pianificazione dipende dalla sessione, e il primo di questi casi che corrisponde si applica:

• Sessioni di terminale interattive 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ì.
• Modalità auto disponibile e l'impostazione useAutoModeDuringPlan attiva, che è l'impostazione predefinita: il classificatore esamina i comandi shell diversi da rimozioni critiche invece di richiedere conferma. I comandi approvati vengono eseguiti, e quelli rifiutati vengono bloccati.
• Modalità auto non disponibile, o useAutoModeDuringPlan disattivata: i comandi al di fuori del set di sola lettura integrato richiedono approvazione, incluso quando la modalità auto-allow della sandbox è abilitata.

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. Se la modalità auto non è disponibile per la tua sessione, ad esempio perché la tua organizzazione l'ha disattivata, 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 le richieste di permesso con la modalità auto

La modalità auto consente a Claude di eseguire senza richieste di permesso di routine. Un modello classificatore separato esamina le azioni prima che vengano 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 una richiesta di permesso.

Con Claude Code v2.1.283 o successivo, la modalità auto è la modalità di permesso iniziale integrata per le sessioni di terminale interattivo e VS Code su ogni piano e provider. Nelle versioni precedenti, è la modalità di permesso iniziale integrata solo sui piani Pro, Max e Team.

Il classificatore esamina anche ogni messaggio che Claude invia a un altro agente con SendMessage, sia testo semplice che un messaggio strutturato di 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.

Per impostazione predefinita, il classificatore non esamina le rimozioni rm e rmdir riconosciute che prendono di mira un percorso critico, come rm -rf / o rm -rf ~. Percorsi critici copre cosa succede loro in ogni modalità di permesso.

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 una skill si basa esplicitamente su di esse. Per un comportamento più autonomo in una modalità che ti chiede comunque conferma, imposta invece lo stile di output Proactive.

[!WARNING]

La modalità auto riduce le richieste di permesso ma non garantisce la sicurezza. Usala per attività in cui ti fidi della direzione generale, non come sostituto della revisione su operazioni sensibili.

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

• Piano: Tutti i piani.
• Organizzazione: su Team ed 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, Haiku 5.5, o un modello Fable. Su Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry e sessioni gateway di app Claude con accesso, solo Claude Sonnet 5 o successivo, Opus 4.7 o successivo, Haiku 5.5 e i modelli Fable. I modelli più vecchi, inclusi Sonnet 4.5, Opus 4.5, Haiku 4.5 e i 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 di 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, oppure 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 fino al termine della sessione, 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 non è riuscita. Questo errore è solitamente transitorio, ma su Amazon Bedrock può ripetersi fino a quando il tuo account non può invocare il modello indicato. 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. Spostala in ~/.claude/settings.json. Per una conversazione che l'estensione VS Code ha avviato, controlla invece l'elenco proprio dell'estensione in Cambia modalità di permesso.

Modalità auto su Bedrock, Agent Platform o Foundry

Su Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry e sessioni gateway di app Claude con accesso, la modalità auto è disponibile per impostazione predefinita. Se lì non imposti una modalità di permesso, le sessioni interattive iniziano in modalità auto, e le esecuzioni claude -p o Agent SDK iniziano in modalità Manual, il cui valore di configurazione è default:

• Sessioni di terminale interattivo e VS Code: per avviarle in una modalità di permesso diversa da auto, imposta permissions.defaultMode come descrive Inizia in una modalità di permesso diversa, o scegline una dall'indicatore di modalità dell'estensione VS Code. In quale modalità inizia una sessione elenca le versioni di Claude Code che le avviano in modalità auto.
• Esecuzioni claude -p e Agent SDK: per avviarne una in modalità auto, passa --permission-mode auto a claude -p, oppure passa permissionMode: "auto" in TypeScript o permission_mode="auto" in Python. Se non passi alcuna modalità di permesso, vedi Chiamate agli strumenti negate nelle esecuzioni claude -p e Agent SDK, che copre anche le versioni precedenti di Claude Code.

Solo Claude Sonnet 5 o successivo, Opus 4.7 o successivo, Haiku 5.5 e i modelli Fable sono supportati su questi provider. Su qualsiasi altro modello, la sessione inizia invece in Manual. La modalità auto con Haiku 5.5 su questi provider richiede Claude Code v2.1.293 o successivo.

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 invece in Manual. Una sessione già in esecuzione in modalità auto la lascia quando l'impostazione raggiunge quella sessione da una fonte distribuita dall'amministratore, e mostra auto mode disabled by settings. Prima della v2.1.251, una sessione in esecuzione manteneva la modalità auto fino al termine.

Revisione del classificatore lato server

In modalità auto, Claude Code può chiedere al server di controllare le azioni che l'ordine decisionale invia per la revisione, come parte delle richieste al modello della sessione, al posto di inviare le proprie richieste del classificatore. Queste sessioni chiedono:

• Una connessione diretta all'API Anthropic: nelle sessioni di terminale interattivo e nelle sessioni -p, Agent SDK, estensione VS Code e app desktop, indipendentemente dal tuo piano o tipo di account, man mano che Anthropic lo distribuisce. Nelle sessioni di terminale interattivo, questo richiede Claude Code v2.1.271 o successivo sui piani Pro, Max e Team, e v2.1.278 o successivo sui piani Enterprise e sugli account Claude API. Nelle sessioni -p, Agent SDK, estensione VS Code e app desktop, questo richiede Claude Code v2.1.281 o successivo. Dalla v2.1.282, una sessione che non recupera i feature flag, ad esempio perché hai disattivato la telemetria, chiede al server per impostazione predefinita in qualsiasi tipo di sessione.
• Un provider cloud, o un gateway LLM o proxy: su Claude Platform su AWS, Amazon Bedrock, Google Cloud's Agent Platform e Microsoft Foundry, e ogni volta che punti ANTHROPIC_BASE_URL a un gateway LLM o proxy, indipendentemente dal tuo piano. Chiedere per impostazione predefinita richiede Claude Code v2.1.278 o successivo.
• Una sessione gateway di app Claude con accesso: richiede Claude Code v2.1.280 o successivo
• Una sessione cloud in un ambiente ospitato da Anthropic: indipendentemente dal tuo piano, quando la avvii dal web, dall'app mobile o dall'app desktop con Cloud selezionato. Le sessioni avviate da un'attività pianificata cloud chiedono al server man mano che Anthropic lo distribuisce.

Dove il server esamina le azioni, sono i suoi verdetti a deciderle. Sono possibili altri due risultati:

• Il server non esamina la sessione: una risposta si completa senza risultati di revisione, o il server risponde che non esamina questa sessione. Le cause più comuni sono un gateway LLM o proxy che elimina la richiesta di revisione o i risultati, e una piattaforma, regione o credenziale che non dispone ancora di controlli lato server. Claude Code ripiega sulle proprie richieste del classificatore. Una volta che questo fallback vale per il resto della sessione, mostra un avviso sugli addebiti delle richieste del classificatore sugli account in cui queste richieste vengono fatturate.
• Il server non dà un verdetto per un'azione: Claude Code nega l'azione piuttosto che eseguirla senza revisione. Su qualsiasi connessione, questo accade quando la risposta termina prima che arrivino i risultati della revisione o quando i risultati arrivano in una forma che Claude Code non può leggere. Un gateway LLM o proxy che tronca le risposte o riscrive i risultati può causare entrambi i casi. Su una connessione diretta all'API Anthropic, accade anche quando il controllo del server non riesce per l'azione, ad esempio per timeout. Il server non ha restituito un verdetto di sicurezza copre il messaggio di negazione, cosa succede quando le negazioni si ripetono, e cosa fare.

Per evitare di chiedere al server e usare sempre le richieste del classificatore di Claude Code, imposta CLAUDE_CODE_AUTO_MODE_SERVER=0. Su una connessione diretta all'API Anthropic, la variabile richiede Claude Code v2.1.281 o successivo. Impostarla su 1 in quel caso attiva la revisione del server in una sessione che non ce l'ha ancora, a meno che tu non abbia impostato anche CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. Se imposti CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 e lasci CLAUDE_CODE_AUTO_MODE_SERVER non impostata, anche Claude Code smette di chiedere al server, tranne nei casi descritti in Disabilita le funzionalità pre-rilascio.

Modello classificatore predefinito

Per impostazione predefinita, le richieste del classificatore vanno a Claude Sonnet 5. Se /status mostra Auto mode server come Enabled, vengono inviate solo per le chiamate al di fuori della revisione del server.

Trova la prima riga di questa tabella che corrisponde alla tua sessione. Ottieni il modello di quella riga al posto di Sonnet 5.

Se Sonnet 5 o il modello in ANTHROPIC_DEFAULT_SONNET_MODEL non è disponibile dal tuo provider o è escluso dalla policy sui modelli della tua organizzazione, Claude Code usa un modello di fallback. Si tratta del modello della tua sessione, oppure di un modello Opus in una sessione Fable.

Scegli il modello classificatore

Con Claude Code v2.1.302 o successivo, imposta CLAUDE_CODE_AUTO_MODE_MODEL su un ID di modello completo per eseguire il classificatore su un modello diverso da quello predefinito. Funzionano anche gli ID di modello completi del tuo provider cloud. Questo esempio di ~/.claude/settings.json imposta Claude Sonnet 4.6:

{
  "env": {
    "CLAUDE_CODE_AUTO_MODE_MODEL": "claude-sonnet-4-6"
  }
}

Quando il tuo modello non è quello che esamina

Se si applicano più situazioni, fai riferimento alla prima elencata.

Verifica quale modello ha usato il classificatore

Dalla tua shell, avvia una sessione in modalità auto con --debug-file:

claude --permission-mode auto --debug-file classifier-debug.log

Fai eseguire a Claude un comando della shell che non sia di sola lettura, poi cerca nel log classifier_request_started:

• Il tuo modello dopo model=: la variabile ha avuto effetto
• Un modello diverso dopo model=: cerca nel log ignoring CLAUDE_CODE_AUTO_MODE_MODEL, che indica il motivo e l'eventuale passaggio da eseguire
• Nessuna riga del genere: leggi Auto mode server in /status al prompt di Claude Code:
  • Enabled: il server è impostato per esaminare le chiamate di questa sessione.
  • Disabled: assicurati che la modalità di permesso sia auto, poi fai eseguire a Claude un altro comando che non sia di sola lettura.

Cosa blocca il classificatore per impostazione predefinita

Il classificatore si fida della tua directory di lavoro e dei remote 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 fino a quando non configuri l'infrastruttura attendibile.

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 archiviazione cloud

• Concessione di permessi 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, quando viene eseguita, invierebbe segreti o dati sensibili al di fuori del repository, o amplierebbe ciò 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 setup che legge un archivio di segreti e invia i dati all'esterno, e una modifica di configurazione che amplia ciò che un deploy pubblica, come un'impostazione di registry, visibilità, artefatto o sourcemap. Il controllo si applica su qualsiasi branch, si applica anche quando il repository è pubblico, e scatta quando la modifica viene sottoposta a commit o push, indipendentemente dal fatto che quel commit o push attivi la pipeline; superarlo richiede di nominare l'effetto dell'esecuzione, non solo il commit o il push

• 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 sottoposte a commit

• git commit --amend quando il commit in HEAD non è stato creato in questa sessione

• Dalla v2.1.198, git commit --amend quando il commit in HEAD è già stato sottoposto a push. Una riscrittura solo del messaggio non è bloccata: --amend -m senza nulla di nuovo in staging, 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

• Scrittura in un gestore di segreti, o modifica di record DNS o certificati TLS

• Merge di una pull request che nessun umano ha approvato, approvazione della pull request di Claude stesso, o disabilitazione dei controlli CI

• Pubblicazione di un commento che è esso stesso un comando per l'automazione, come atlantis apply o il /deploy o /merge di un bot

• Attivazione, 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 del cluster

• Scritture in un cluster di calcolo condiviso che vanno oltre la risorsa che hai nominato, come un selettore di etichette o --all che coinvolge i job di altri utenti

• Creazione di risorse Kubernetes che vengono eseguite su ogni nodo o intercettano il traffico del cluster, come DaemonSet e webhook di ammissione

• Shell interattive o port-forward verso un target remoto sensibile

• Apertura di un tunnel o di una reverse shell che rende un servizio locale raggiungibile da Internet pubblico

• Stampa di una credenziale o di un token attivo nella trascrizione o in un file

• Accesso a una posizione elencata come posizione di dati sensibili nel tuo ambiente, copia di dati da una di esse, o invio di dati da una di esse a un pubblico che la voce esclude

• Instradamento di un'installazione di pacchetti aggirando il tuo registry di pacchetti interno verso un registry pubblico. Questo si applica quando un registry interno o un mirror è elencato nel tuo ambiente o quando hai detto a Claude nella conversazione che ne esiste uno

• Esecuzione di un comando con un flag che disattiva una protezione di sicurezza, come --insecure

• Avvio di un ciclo di agente autonomo che viene eseguito senza approvazione umana o sandbox, come uno avviato con --dangerously-skip-permissions o --no-sandbox. Questo include l'esecuzione di un agente di terze parti o di un harness di eval con isolamento e approvazione per azione disabilitati, come un runner avviato con --yes-always

• Azioni del browser di Claude in Chrome che potrebbero inviare contenuto della pagina, cookie o credenziali off-origin

• Eliminazione di file in /tmp, $TMPDIR, o un'altra directory di scratch o cache condivisa tramite wildcard, glob o filtro di età anziché tramite un percorso specifico indicato

• Inclusione di dettagli sensibili nel contenuto inviato, caricato, pubblicato o scritto ad altre persone o sistemi condivisi, quando il tuo 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 è al di fuori del confine di fiducia o è pubblico, inclusi i repository pubblici della tua organizzazione; i percorsi di file interni, i nomi in codice, i dati attivi di risposte API come email o identificatori di account, e gli identificatori di infrastruttura contano come dettagli sensibili. I dati personali attivi provenienti da una risposta API in un corpo di PR o issue, come un indirizzo email, un identificatore di account o di 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

• Invio di sequenze di tasti al pannello tmux di Claude Code stesso per pilotare la sua stessa interfaccia, che il classificatore tratta come Claude che modifica i propri permessi o la propria supervisione

• Commentare, eliminare o forzare il superamento di un test o di un'asserzione che protegge un comportamento di sicurezza, come autenticazione, controllo degli accessi, convalida dell'input o sandboxing

• Eliminazione o smantellamento di una risorsa con stato che Claude non ha creato nella sessione, quando non si applica nessuna regola di eliminazione più specifica e non hai nominato quella risorsa

• Reindirizzamento di un URL di base API, endpoint proxy, ricevitore webhook o mirror di registry verso un host di terze parti non adatto al compito, anche nei file di esempio come .env.example

• Modifica della destinazione dei 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 come pubblico, o push lì di materiale confidenziale che non fa parte del lavoro proprio di quel repository. L'argomento proprio di un repository di dotfiles è l'unica eccezione per i dati personali o affidati, e il contenuto di un repository privato che raggiunge qualsiasi superficie pubblica viene bloccato allo stesso modo. Quando la visibilità di un repository non è stabilita, il classificatore non blocca solo per questo motivo; valuta invece il contenuto rispetto alle altre regole

• Apertura di una pull request verso un repository o un'organizzazione diversi, fork con gh repo fork, o push a un repository di terze parti, a meno che tu non abbia nominato quel target esterno

• Contenuto proveniente da un archivio locale sensibile, o da un file il cui nome, percorso o tipo lo identifica come sensibile, che finisce in un commit, un push, il testo di una 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 nascoste di credenziali e configurazione come chiavi SSH, credenziali cloud, profili del browser e cronologia della shell, e gli export di dati utente contano tutti, e il fatto che il repository sia privato non rimuove il blocco

• Scrittura nelle trascrizioni di sessione di Claude Code, i file di cronologia .jsonl sotto ~/.claude/projects/ o la directory di configurazione che hai configurato, direttamente o tramite un comando della shell. La regola copre anche le righe di metadati che Claude Code aggiunge a ogni voce della trascrizione per i propri 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 della shell non assegnata in nessun punto della conversazione che il classificatore vede, o un glob radicato in tale variabile. Il valore proveniva solo dall'output di un comando precedente, che il classificatore non riceve mai, quindi il classificatore non può verificare il target dell'eliminazione rispetto alle altre regole di eliminazione. Il blocco viene rimosso quando nomini il percorso esatto da eliminare, 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.

  Un glob direttamente sotto la variabile, come in rm -rf "$VAR"/*, è invece un percorso critico. I target di Remove-Item che sono un * isolato o terminano in /* o \* non raggiungono mai il classificatore: Claude Code li nega direttamente.

Diverse di queste categorie dipendono da voci di ambiente, come target remoti sensibili e ambiti IaC protetti, che puoi restringere a nomi concreti.

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

• Richiesta di credenziali all'endpoint dei metadati dell'istanza cloud, come 169.254.169.254, o autenticazione esplicita di una chiamata a cloud, cluster o registry con l'identità dell'account di servizio o del nodo della macchina stessa
• Raggiungimento di un host pubblico tramite un percorso diverso da una richiesta diretta, come un tunnel, una reverse shell, o una configurazione di resolver o proxy riscritta per puntare all'esterno
• Lettura di credenziali che appartengono all'host anziché al tuo compito, come i certificati del nodo o l'autenticazione del registry di container del nodo
• Connessione o scansione di container, pod o VM vicini che Claude non ha avviato, o del nodo sottostante al container

Se Claude Code viene eseguito in un contesto destinato a consentire una di queste azioni, descrivi quella configurazione in una voce Host containment in autoMode.environment.

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

• Pubblicazione o scrittura di un link a un servizio pubblico di paste, diagrammi o condivisione dati in un messaggio, nel testo di una PR o issue, in un documento, o in qualsiasi altro punto in cui il link verrà aperto o recuperato, quando l'URL stesso contiene il contenuto condiviso, a meno che tu non abbia nominato quel servizio

Consentito per impostazione predefinita:

• Operazioni sui 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 all'API corrispondente

• Richieste HTTP di sola lettura

• Push a qualsiasi branch del repository in cui stai lavorando, incluso il branch predefinito. Un branch non predefinito il cui nome lo identifica come target di deploy o pubblicazione, come production o gh-pages, non è coperto: il classificatore valuta un push lì in modo autonomo.

  Il contenuto di un push viene comunque controllato rispetto alle altre regole del classificatore, e le regole permissions.deny possono comunque bloccare i comandi push così come sono scritti in ogni modalità. La protezione dei branch del remote si applica comunque.

• Eliminazione dei job esatti che Claude ha creato in precedenza nella stessa sessione

• Lettura, revisione o scrittura di codice, configurazioni 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 solo il flusso di dati, non le operazioni distruttive o sulle credenziali sulla stessa infrastruttura

• Navigazione di Claude in Chrome verso un dominio interno attendibile, localhost, o un URL che hai nominato

I comandi in sandbox non ottengono accesso alla rete per impostazione predefinita. Claude indica sul comando stesso gli host di cui un comando ha bisogno, il classificatore li esamina insieme al comando, e un elenco approvato apre quegli host solo per quel comando. Domini consentiti per comando spiega cosa un elenco può e non può aprire e cosa succede quando un comando cerca di raggiungere un host non elencato.

Esegui claude auto-mode defaults per stampare gli elenchi completi delle regole 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 la modalità auto.

Il push a qualsiasi branch del repository in cui stai lavorando e la creazione di una pull request che corrisponde alla tua richiesta vengono eseguiti senza una richiesta di permesso, a meno che il push o la pull request non rientrino nell'elenco dei blocchi, come segreti o dati sensibili che lasciano il repository, o una pull request che ha come target un repository o un'organizzazione diversi. Per richiedere un checkpoint umano prima di questi comandi rimanendo in modalità auto, aggiungi regole permissions.ask, che corrispondono al comando così come è scritto: vedi Confini comuni.

La prima lettura al di fuori delle directory di lavoro

Mentre permissions.blockReadsOutsideWorkingDirectories è disattivata, le letture di file diverse dalle letture da percorsi di rete vengono eseguite senza una richiesta di permesso 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 chiede se consentire quella lettura.

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

Qualunque sia la tua risposta, Claude continua a lavorare:

• Sì, e continua a consentire qualsiasi lettura al di fuori delle directory di lavoro: 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 la richiesta non appaia di nuovo
• No, e blocca le letture al di fuori delle directory di lavoro da ora in poi: la lettura viene rifiutata, e Claude Code imposta permissions.blockReadsOutsideWorkingDirectories su true nelle tue impostazioni utente, il che fa sì che gli strumenti per i file rifiutino tali letture in ogni sessione successiva e in ogni modalità di permesso. Per consentire a Claude di leggere un tale percorso in seguito, aggiungi la sua directory con /add-dir o rimuovi l'impostazione.
• No, e chiedi di nuovo la prossima volta: la lettura viene rifiutata, e la prossima lettura al di fuori delle directory di lavoro chiede di nuovo
• Sì, ma chiedi di nuovo la prossima volta: la lettura viene eseguita, nulla viene salvato, e la prossima lettura al di fuori delle directory di lavoro chiede 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 fare push" o "aspetta che io abbia rivisto prima di fare il deploy", il classificatore blocca le azioni corrispondenti anche quando le regole predefinite le consentirebbero. Un confine rimane in vigore fino a quando non lo revochi in un messaggio successivo. Il giudizio di Claude che una condizione sia stata soddisfatta non lo revoca.

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

Approvazioni che dichiari nella conversazione

Se dici a Claude che un'azione bloccata è consentita, il classificatore lo interpreta come la tua approvazione e può rimuovere il blocco. Il modo in cui l'hai formulato decide se l'azione viene eseguita e fin dove arriva l'approvazione:

• Nomina l'azione e i suoi dettagli: il tuo messaggio deve nominare l'azione e l'elemento specifico che la rende pericolosa, come il branch di un force push. Nominare solo il verbo non rimuove nulla, quindi "puoi fare force-push" lascia il blocco in vigore.
• Aspettati che copra un'azione: un'approvazione copre l'azione distruttiva che hai nominato, quindi un'azione successiva viene bloccata di nuovo a meno che tu non abbia concesso l'approvazione come permanente. Per smettere di approvare uno schema di routine un'azione alla volta, aggiungilo a autoMode.allow.
• Alcuni blocchi rimangono in vigore: l'ordine di precedenza del classificatore stabilisce quali blocchi la tua approvazione può raggiungere. Per eseguire un passaggio che non verrà sbloccato, esci dalla modalità auto e rispondi alla richiesta di permesso.

Quando la modalità auto ripiega

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 ed elenca l'azione in /permissions nella scheda Recently denied, dove puoi premere r per riprovarla con un'approvazione manuale.
• 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 chiedere conferma. Approvare l'azione richiesta riattiva la modalità auto. Vedi Soglie di blocco ripetuto per come vengono contati i blocchi.
• Nessun verdetto dal classificatore: quando un controllo di sicurezza separato dalla modalità auto rifiuta la richiesta del classificatore stesso, o la risposta del classificatore non può essere analizzata, Claude Code nega l'azione senza la notifica o la voce Recently denied. Vedi Auto mode cannot determine the safety of an action per il messaggio mostrato in ciascun caso e cosa fare.
• Nessun verdetto dal server: con la revisione del classificatore lato server, Claude Code nega un'azione per cui il server non dà un verdetto, e interrompe il turno dopo dieci risposte di seguito senza verdetto. Vedi Il server non ha restituito un verdetto di sicurezza.
• Un cambio di modalità durante un controllo: se cambi modalità di permesso mentre un controllo del classificatore è in sospeso, Claude Code scarta un verdetto che la nuova modalità non avrebbe richiesto. Ti viene invece chiesta un'approvazione, oppure l'azione viene negata automaticamente in modalità dontAsk.

Soglie di blocco ripetuto

Le soglie di 3 blocchi di seguito e 20 blocchi totali non sono configurabili. Il contatore totale persiste per tutta la sessione e si azzera solo quando il suo limite attiva un fallback. Claude Code non conta una negazione per nessuna delle due soglie quando un controllo di sicurezza separato dalla modalità auto rifiuta la richiesta del classificatore stesso.

Un'esecuzione -p non interattiva senza un --permission-prompt-tool non ha una richiesta di permesso su cui ripiegare. Quando i blocchi ripetuti raggiungono una soglia, l'azione non viene eseguita e Claude continua a lavorare. Claude Code non interrompe l'esecuzione.

I blocchi ripetuti di solito significano che al classificatore manca il contesto sulla tua infrastruttura. Usa /feedback per segnalare falsi positivi, o chiedi a un amministratore di configurare l'infrastruttura attendibile.

Come la modalità auto valuta le azioni

Le sezioni seguenti descrivono l'ordine in cui Claude Code valuta un'azione, come il classificatore esamina il lavoro dei subagent, e cosa aggiungono le chiamate al classificatore in termini di costo e latenza.

Come il classificatore valuta le azioni

Ogni azione passa attraverso un ordine decisionale fisso. Prevale il primo passaggio corrispondente:

1. Le azioni che corrispondono alle tue regole allow, ask o deny vengono risolte immediatamente, con queste eccezioni:
   • Le scritture su percorsi protetti vengono inviate al classificatore anche quando corrisponde una regola allow. Quando il percorso protetto è il file a cui punta un file di impostazioni con collegamento simbolico, la scrittura può invece chiederti conferma, come descrive l'elenco dei percorsi protetti
   • Nessuna regola allow approva le rimozioni rm e rmdir riconosciute che prendono di mira un percorso critico
   • Gli strumenti MCP contrassegnati con requiresUserInteraction ti chiedono conferma direttamente anche quando corrisponde una regola allow, e lo stesso vale per gli strumenti dei connettori che la tua organizzazione ha impostato su ask nelle sessioni in cui quell'impostazione raggiunge Claude Code
   • Anche un comando della shell che include domini consentiti per comando viene inviato al classificatore anche quando corrisponde una regola allow, perché una regola approva il comando, non i suoi host
   • Le regole ask che corrispondono al contenuto di un comando, come Bash(git push *), ripiegano su una richiesta di permesso
   • Una scrittura che il controllo dei collegamenti simbolici risolve in un percorso protetto ti chiede conferma quando il percorso richiesto da Claude non è di per sé protetto
   • Una lettura da un percorso di rete ti chiede conferma anche quando corrisponde una regola allow
2. Le azioni di sola lettura e le modifiche ai file nella tua directory di lavoro vengono approvate automaticamente, tranne le scritture su percorsi protetti e la prima lettura al di fuori delle directory di lavoro, che ti chiede conferma
   • In una sessione con revisione del classificatore lato server, i comandi della shell di sola lettura e quelli in sandbox attendono quella revisione e vengono bloccati se li segnala
   • Una scrittura all'interno della tua directory di lavoro che il controllo dei collegamenti simbolici risolve in una posizione esterna a essa ti chiede conferma
   • Quando Claude legge un artefatto creato da qualcun altro, si applicano i casi di approvazione elencati in quella sezione
   • Una lettura da un percorso di rete ti chiede conferma
3. Tutto il resto va al classificatore, ad eccezione delle rimozioni di percorsi critici con la loro gestione predefinita. Nemmeno gli strumenti dei connettori e gli strumenti MCP con requiresUserInteraction che ti chiedono conferma direttamente nel passaggio 1 raggiungono mai il classificatore, quindi né un'approvazione richiesta dall'organizzazione né un passaggio di consenso vengono approvati automaticamente
4. Se il classificatore blocca, Claude riceve il motivo. Nella maggior parte delle sessioni il motivo indica la regola a cui il classificatore ha fatto corrispondere l'azione, come [Data Exfiltration], anziché fornire una spiegazione scritta; consulta Rivedi le negazioni

Anche un mod che installi e che gestisce tool.check può approvare un'azione. Per i casi in cui la sua approvazione non supera le tue regole e i tuoi hook, vedi Estendi i permessi con gli hook.

Per sapere come vengono approvate le azioni del browser di Claude in Chrome nell'estensione VS Code, vedi Richieste di permesso nelle sessioni VS Code.

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

• Bash(*) o PowerShell(*) generici
• Interpreti con wildcard come Bash(python*)
• Comandi di esecuzione del gestore di pacchetti
• Regole allow Agent
• Regole allow Monitor, perché Claude Code esegue i comandi Monitor tramite la shell

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

Claude Code esegue anche autonomamente git status prima di un comando che scarterebbe lavoro non sottoposto a commit, come git reset --hard o rm -rf, e mostra al classificatore se è presente lavoro in staging, modificato o non tracciato. 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 agli strumenti diverse dalle consultazioni di sola lettura come letture di file e ricerche, e il contenuto del tuo CLAUDE.md. I risultati degli strumenti vengono rimossi da quelle richieste, quindi il contenuto ostile in un file o in una pagina web non può manipolare direttamente il classificatore.

Puoi annotare il risultato di una chiamata con il campo classifierContext di un hook PostToolUse, che il classificatore legge come contesto fornito dall'applicazione. Il campo richiede Claude Code v2.1.236 o successivo.

Una sonda lato server separata analizza i risultati degli strumenti in arrivo e segnala il contenuto sospetto prima che Claude lo legga. Per ulteriori informazioni su come questi livelli funzionano insieme, vedi l'annuncio della modalità auto e l'approfondimento tecnico.

Come la modalità auto gestisce i subagent

Il classificatore controlla il lavoro dei subagent in tre punti:

1. Prima che un subagent si avvii, viene valutata la descrizione del compito delegato, quindi un compito che sembra pericoloso viene bloccato al momento della creazione.
2. Mentre il subagent è in esecuzione, ciascuna delle sue azioni passa attraverso lo stesso ordine decisionale della sessione padre, con le stesse regole di blocco e di consenso. Qualsiasi permissionMode nel frontmatter del subagent viene ignorato.
3. Quando il subagent termina, il classificatore esamina il suo lavoro e il suo rapporto finale prima che la sessione padre legga il rapporto. Quando il classificatore segnala il lavoro o il rapporto del subagent, o un controllo di sicurezza separato dell'API rifiuta la revisione, il rapporto viene comunque consegnato, preceduto da un avviso di sicurezza. Quando il classificatore non è disponibile per la revisione, il rapporto arriva con una nota che invita a verificare il lavoro del subagent prima di agire di conseguenza.

Costo e latenza

Le richieste del classificatore di Claude Code possono essere eseguite su un modello diverso da quello selezionato con /model. Vedi su quale modello vengono eseguite.

Sui piani Enterprise e sugli account che utilizzano l'API Claude, Claude Platform su AWS, Amazon Bedrock, Google Cloud's Agent Platform o Microsoft Foundry, le chiamate al classificatore contano nel 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 nella directory di lavoro al di fuori dei percorsi protetti saltano il classificatore, quindi l'overhead proviene principalmente dai comandi della shell e dalle operazioni di rete. Dove il server esamina le azioni come parte delle richieste al modello della sessione, non ci sono chiamate separate al classificatore da contare; vedi Revisione del classificatore lato server.

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

Consenti solo strumenti pre-approvati con la modalità dontAsk

Se imposti la modalità dontAsk, Claude Code nega automaticamente ogni chiamata a uno strumento che altrimenti ti chiederebbe conferma, anche se un mod che hai installato può comunque approvare alcune di quelle chiamate. Per verificare quali chiamate un mod può approvare, consulta Estendere i permessi con gli hook.

Claude esegue ancora le 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. Vengono eseguite anche 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 corrisponde alle tue regole allow, e fa lo stesso con gli strumenti dei connettori che la tua organizzazione ha impostato su ask nelle sessioni in cui quell'impostazione raggiunge Claude Code. Nega allo stesso modo gli strumenti MCP contrassegnati con _meta["anthropic/requiresUserInteraction"], perché la loro scheda di approvazione necessita di una risposta che questa modalità non raccoglie mai.

Una regola allow o un hook PreToolUse non può approvare queste azioni:

• Le rimozioni rm e rmdir riconosciute che riguardano percorsi critici, come rm -rf / e rm -rf ~
• Le letture da un percorso di rete

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.

Anche in modalità bypassPermissions, ciascuna delle azioni che nessuna modalità approva automaticamente riceve una richiesta di conferma o un rifiuto, anche se puoi disattivare la richiesta di conferma per i comandi rm pericolosi. La lettura di un artefatto pubblico di un'altra organizzazione richiede la tua approvazione, e questa modalità non la chiede, quindi Claude non può leggerne uno. Anche i blocchi di Remove-Item in PowerShell si applicano in questa modalità.

Due misure di protezione per la messaggistica tra sessioni si applicano comunque in questa modalità, e nelle sessioni di terminale interattivo in modalità plan 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 il bypass dei permessi disponibile, 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 chiedere. Le regole ask esplicite e le rimozioni rm e rmdir riconosciute che prendono di mira un percorso critico richiedono comunque una conferma.

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.

[!WARNING]

Utilizza questa modalità solo in ambienti isolati come container, VM o dev container senza accesso a Internet, dove Claude Code non può danneggiare il sistema host.

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 dei permessi:

• Se accetti: Claude Code imposta skipDangerousModePermissionPrompt su true in ~/.claude/settings.json, in modo che le sessioni successive saltino la finestra di dialogo. Per visualizzare di nuovo la finestra di dialogo, rimuovi la chiave da quel file o impostala su false. Il riferimento skipDangerousModePermissionPrompt elenca gli altri file di impostazioni dove tu o la tua organizzazione potete impostarla.
• Se rifiuti: Claude Code esce.

In modalità non interattiva nessuna finestra di dialogo viene mostrata.

Una sessione in background rispetta la tua accettazione quando è registrata nelle impostazioni utente o nelle impostazioni gestite:

• Se non è registrata alcuna accettazione, claude --bg --permission-mode bypassPermissions viene rifiutato. Accetta prima la finestra di dialogo in una sessione interattiva.

• Con skipDangerousModePermissionPrompt impostato solo in .claude/settings.local.json, la sessione in background si avvia con la richiesta di bypass ignorata:

  • Con --allow-dangerously-skip-permissions ignorato, bypassPermissions viene escluso dal suo ciclo Shift+Tab.
  • Con --permission-mode bypassPermissions o --dangerously-skip-permissions ignorati, la sessione si avvia invece in modalità Manual.

  Aggiungi "skipDangerousModePermissionPrompt": true a ~/.claude/settings.json, poi avvia una nuova sessione in background.

Su Linux e macOS, Claude Code rifiuta di avviarsi in modalità bypassPermissions 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.

Cloud sessions non rispettano 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à di autorizzazione mostrata nel menu a discesa della modalità. Vedi Cambia modalità di autorizzazione per le modalità offerte dalle sessioni cloud.

[!WARNING]

bypassPermissions non offre protezione contro l'iniezione di prompt o azioni indesiderate. Per i controlli di sicurezza di background con molti meno prompt di autorizzazione, utilizza invece la modalità auto. Gli amministratori possono bloccare questa modalità impostando permissions.disableBypassPermissionsMode su "disable" nelle impostazioni gestite.

Bypass dei permessi ignorato in una sessione in background

Questo avviso significa che la sessione in background non ha trovato la tua accettazione dell'avviso sul bypass dei permessi nelle impostazioni utente o nelle impostazioni gestite, quindi ha ignorato la richiesta di bypass effettuata al lancio:

Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true

Aggiungi "skipDangerousModePermissionPrompt": true a ~/.claude/settings.json, poi avvia una nuova sessione in background.

claude agents mostra l'avviso sul bypass dei permessi che le sessioni interattive saltano

Se claude agents mostra l'avviso sul bypass dei permessi nonostante le tue sessioni interattive lo saltino, verifica se skipDangerousModePermissionPrompt è impostato in .claude/settings.local.json o in un file --settings. Le sessioni interattive considerano la chiave presente lì come la tua accettazione dell'avviso, mentre claude agents no. Che tu la trovi lì o meno, accetta l'avviso per aggiungere la chiave a ~/.claude/settings.json, dove claude agents la cerca.

Percorsi protetti

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

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.

Nelle modalità che instradano le scritture su percorsi protetti al classificatore, una scrittura che il controllo dei symlink risolve in un percorso protetto richiede conferma quando il percorso richiesto da Claude non è esso stesso protetto.

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 nella cartella .claude/ del progetto o in ~/.claude/ può offrire una di queste opzioni con ambito di sessione:

• Per la cartella .claude/ del progetto: Sì, e consenti a Claude di modificare i file nella cartella .claude di questo progetto per questa sessione
• Per ~/.claude/: Sì, e consenti a Claude di modificare i file nella sua cartella ~/.claude per questa sessione

Directory protette:

• .git
• .config/git
• .vscode
• .idea
• .husky
• .cargo
• .devcontainer
• .yarn
• .mvn
• .claude, con alcune eccezioni, tra cui:
  • I git worktree di Claude in .claude/worktrees/
  • I file di piano della sessione corrente in ~/.claude/plans/, o nella plansDirectory che hai impostato
  • La directory temporanea di una sessione in background in ~/.claude/jobs/<id>/tmp/
  • I file markdown nella directory della memoria automatica del progetto, come ~/.claude/projects/<project>/memory/, in una sessione avviata senza --restricted
  • I file markdown in una directory di memoria dei subagent, come .claude/agent-memory/, in una sessione avviata senza --restricted
• Una directory caricata con --plugin-dir, perché Claude Code ricarica ed esegue il codice di un mod da essa quando un file cambia
• ~/.claude/dev-mods/, o dev-mods/ nella directory a cui punta CLAUDE_CONFIG_DIR, dove Claude salva i mod che scrive per te

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
• Un file che hai passato a --settings, --mcp-config o --agents quando hai avviato la sessione
• Il file a cui punta il tuo file di impostazioni utente, di progetto o locale quando il file di impostazioni è esso stesso un collegamento simbolico, ad esempio verso un repository di dotfile. Nelle modalità che instradano le scritture su percorsi protetti al classificatore, una scrittura su questo file richiede invece conferma, anche quando corrisponde una regola allow. Se il percorso del file stesso è anche quello di un file di impostazioni, come .claude/settings.json in un'altra cartella, la scrittura va al classificatore come le altre scritture su percorsi protetti

Percorsi critici

I percorsi critici sono le directory che Claude Code protegge dai comandi rm e rmdir, come la radice del filesystem, la tua directory home e la tua directory di lavoro. Claude Code controlla questi comandi prima che vengano eseguiti, e nessuna regola allow approva un comando il cui target viene riconosciuto come percorso critico. Il controllo può non rilevare alcuni comandi, quindi non sostituisce un controllo del sistema operativo come il sandboxing.

Una rimozione di percorso critico è un comando rm o rmdir il cui target Claude Code riconosce come percorso critico. Nemmeno un hook PreToolUse che restituisce "allow" può approvarla. Una regola allow o un hook PreToolUse non può approvarla nemmeno nelle modalità di permesso che saltano altri prompt.

[!WARNING]

Un comando che il controllo non rileva non riceve alcuna gestione speciale, quindi qualsiasi cosa approvi i comandi Bash nella tua sessione può approvarlo senza alcuna richiesta di conferma. Ciò include una regola allow, la modalità bypassPermissions e la modalità auto-allow della sandbox. Il controllo si applica a rm e rmdir, quindi anche altri comandi approvati possono eliminare percorsi critici.

Queste protezioni si applicano che il controllo riconosca o meno un comando:

• Regole deny: una regola deny che corrisponde al comando lo blocca, anche se un mod che hai installato può comunque approvare alcune di quelle chiamate
• Sandboxing: il sandboxing fa sì che il sistema operativo limiti i percorsi in cui i comandi Bash possono scrivere. I comandi in sandbox possono comunque eliminare la tua directory di lavoro
• Modalità sandbox rigorosa: per impostazione predefinita un comando in sandbox può essere riprovato fuori dalla sandbox, e una regola allow o la modalità bypassPermissions può approvare quel nuovo tentativo senza prompt. La modalità sandbox rigorosa disattiva il nuovo tentativo

Cosa succede a una rimozione che Claude Code riconosce dipende dalla tua modalità di permesso. Remove-Item e i built-in cmd per la rimozione hanno i loro propri controlli, trattati in Remove-Item in PowerShell.

Quali percorsi sono critici

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. Su Windows conta anche il suo nome breve 8.3, come C:\Users\LONGNA~1
• Radici di unità Windows e le loro directory di primo livello, come C:\ e C:\Windows. Grafie come \\?\C:\ e \\localhost\C$ contano come C:\
• 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

Per i percorsi di unità montate come /mnt/c o /Volumes/USB, consulta Il prompt per le unità montate.

I controlli sul nome breve 8.3 della directory home e sulle grafie \\?\C:\ e \\localhost\C$ richiedono Claude Code v2.1.292 o successivo.

Altri target che contano come percorsi critici

Claude Code tratta anche i seguenti target rm e rmdir come percorsi critici. L'ultima colonna dice perché ognuno conta.

Per disattivare il controllo su un target che è solo output di sostituzione di comando, imposta CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 nell'ambiente che avvia Claude Code.

Rimozioni dentro comandi annidati e script inline

Claude Code guarda anche dentro questi costrutti:

• Comandi annidati: una subshell con (...), un gruppo di parentesi graffe con { ...; }, sostituzione di comando con $(...) o backtick, o sostituzione di processo con <(...). 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.
• Script inline: uno script passato a sh, bash, zsh o a una shell POSIX simile con -c, come in bash -c 'rm -rf ~'.
  • Quando lo script è tra doppi apici, la shell che invoca espande le sue variabili prima che la shell interna riceva lo script. In find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \;, il comando si espande a una rimozione dalla radice del filesystem una volta per ogni corrispondenza, e Claude Code lo tratta come una rimozione di percorso critico.
  • Uno script tra apici singoli che lega $1 a un valore reale, come fa sh -c 'rm -rf "$1"/*' _ {}, non viene segnalato.

Per disattivare il controllo su un percorso critico digitato direttamente in uno script -c, come ~, imposta CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 nell'ambiente che avvia Claude Code.

Riscrivi un comando contrassegnato

Come riscrivere un comando in modo che passi il controllo dipende da quale dei altri target usa:

• Un glob o una barra finale sotto una variabile come $DIR: proteggi ogni espansione in modo che la shell si fermi con un errore quando la variabile non è impostata o è vuota, come in rm -rf "${DIR:?}"/*, oppure usa un percorso letterale. Una rimozione le cui espansioni sono tutte protette in questo modo passa questo controllo, quindi in modalità bypassPermissions viene eseguita senza un prompt a meno che un altro controllo critico-percorso non la contrassegni.
• Un glob o una barra finale sotto una variabile che è normalmente impostata, come $HOME: usa un percorso letterale.
• Una variabile assegnata da una sostituzione di stampa di directory: usa un percorso letterale. Una protezione "${D:?}" non cancella questo controllo, perché la variabile non è vuota.
• Un target che è solo output di sostituzione di comando: esegui la sostituzione da sola per prima, poi rimuovi i percorsi letterali che stampa. Il prompt dice a Claude di fare lo stesso.

Per un glob o una barra finale sotto una variabile, il prompt nomina il comando rm contrassegnato e dice come riscriverlo in modo che il controllo passi.

Il prompt Dangerous rm operation not ruled out

Il motivo completo è:

Dangerous rm operation not ruled out — the shell may read this command differently than it was parsed

Questo motivo significa che la shell potrebbe interpretare il comando in modo diverso da come lo ha fatto Claude Code, quindi una rimozione potrebbe trovarsi in una parte non controllata, anche senza alcun rm presente. In modalità auto o bypassPermissions, una negazione con questa frase proviene dallo stesso controllo:

This command could not be checked for dangerous rm operations: the shell may read it differently than it was parsed.

Ricevi il prompt o la negazione che riceve una rimozione di percorso critico nella tua modalità di permesso, bypassPermissions inclusa, anche se in modalità bypassPermissions puoi disattivare quel prompt. Non puoi approvare il comando con una regola allow Bash o Bash(*), con la modalità auto-allow della sandbox o con un hook PreToolUse che restituisce "allow". Leggi il comando, poi approva il prompt oppure, dopo una negazione, eseguilo nella tua shell.

Il prompt per le unità montate

Il prompt per le unità montate compare su macOS, Linux e WSL quando un rm ricorsivo prende di mira un percorso di unità montata elencato, come /mnt/c o /Volumes/USB/build. Il suo motivo è Dangerous rm operation on mounted drive path: <path>. Un target /* riceve il prompt anche senza il flag ricorsivo, poiché Claude Code interpreta rm /Volumes/USB/build/* come una rimozione di /Volumes/USB/build.

Anche con una regola allow per rm, Claude Code gestisce il comando come una rimozione di percorso critico: un prompt o una negazione a seconda della tua modalità di permesso. Approva il prompt per consentire l'esecuzione di rm, oppure disattiva il prompt.

Percorsi che ricevono il prompt per le unità montate

Confronta il target del tuo rm ricorsivo o della tua rimozione /* con queste forme di percorso, dove ogni segnaposto come <drive> o <name> rappresenta esattamente un segmento di percorso:

Per un rm ricorsivo o non ricorsivo su /Volumes, /media o /mnt stessi, vedi invece il motivo di percorso critico Dangerous rm operation on critical path: <path>.

Un target relativo viene calcolato a partire dalla tua directory di lavoro, quindi rm -rf build mentre lavori in /Volumes/USB prende di mira /Volumes/USB/build e riceve il prompt.

Disattiva il prompt per le unità montate

Per non ricevere più il prompt per le unità montate mantenendo i prompt dovuti ad altre cause, avvia Claude Code con CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1 nel suo ambiente. Ad esempio, imposta la variabile nella tua shell e avvia claude da lì:

export CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1
claude

In una sessione avviata in questo modo, il prompt per le unità montate smette di comparire per un'intera unità come /Volumes/USB e per gli altri percorsi elencati. Se consenti Bash(rm *), usi la modalità Manual e lavori in /Volumes/USB, allora rm -rf build viene eseguito senza prompt.

Un prompt che mostra ancora Dangerous rm operation on mounted drive path significa che la variabile non raggiunge la sessione:

• Variabile in un file di impostazioni: Claude Code ignora la variabile nel blocco env di un file di impostazioni, qualunque sia il tipo di file di impostazioni, quindi imposta invece la variabile dove avvii claude
• Sessione avviata senza la variabile: avvia di nuovo claude da un ambiente in cui la variabile è impostata, poiché una sessione in esecuzione non la rileva

Rimozioni che chiedono ancora conferma con il prompt per le unità montate disattivato

In modalità Manual con una regola allow per rm, un rm su un percorso di unità montata può ancora mostrare un prompt, senza il motivo Dangerous rm operation on mounted drive path:

• Target fuori dalle tue directory di lavoro: rm -rf /Volumes/USB/other mentre lavori in /Volumes/USB/project riceve un prompt. Per eliminare quel prompt, aggiungi alla sessione una directory che contiene il target
• Target con un *: rm -rf build/* riceve un prompt. Approva quel prompt per eseguire il comando, oppure chiedi a Claude di nominare ogni target senza *
• Target che è un percorso critico: /mnt stesso e la tua directory di lavoro stessa restano percorsi critici, quindi rm -rf su uno dei due riceve un prompt. Approva quel prompt per consentire l'esecuzione di rm

Rimozioni di percorsi critici in ogni modalità di autorizzazione

Cosa Claude Code fa con una rimozione di percorso critico dipende dalla tua modalità di autorizzazione:

Se una regola ask esplicita corrisponde al comando, Claude Code ti chiede invece, anche in modalità auto e senza un limite di tempo. Nelle modalità che chiedono, un hook PermissionRequest può rispondere al prompt.

Per eseguire queste rimozioni senza prompt in modalità bypassPermissions, consulta Disattiva il prompt di rimozione dei percorsi critici.

Limiti di tempo e negazioni in modalità auto e bypassPermissions

In modalità auto e bypassPermissions, il prompt del terminale per una rimozione di percorso critico mostra un conto alla rovescia di due minuti:

• Se il conto alla rovescia scade prima che tu rispondi, Claude Code nega il comando e dice a Claude cosa fare invece, in modo che una sessione incustodita continui a funzionare.
• Premi un tasto qualsiasi mentre il prompt è aperto per fermare il conto alla rovescia e mantenere il prompt in attesa della tua risposta.
• Dopo tre di questi prompt scaduti senza risposta in una sessione, Claude Code smette di mostrarli e nega ulteriori rimozioni di percorsi critici immediatamente. L'invio di un nuovo messaggio ricomincia il conteggio.

Il limite di tempo si applica in Claude Code v2.1.281 e successivi, così come la negazione in modalità auto fuori dal terminale.

Lontano dal terminale, non ricevi quel prompt:

Ovunque la rimozione venga negata, puoi leggere l'intero comando ed eseguirlo nella tua shell.

Per cambiare ciò che ottieni in ciascuna modalità, imposta CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT su 1:

• bypassPermissions: il prompt del terminale non ha limite di tempo e il pannello chat di VS Code ti chiede conferma
• auto: decide il classificatore, nel terminale, nel pannello chat di VS Code, nelle esecuzioni -p e nelle sessioni Agent SDK

Impostala nell'ambiente che avvia Claude Code, come la tua shell o l'opzione env dell'SDK, non in un file di impostazioni di Claude Code. Per il pannello chat, aggiungila a claudeCode.environmentVariables nel settings.json utente di VS Code stesso, poi avvia una nuova conversazione:

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT", "value": "1" }
  ]
}

Disattiva il prompt di rimozione dei percorsi critici in modalità bypassPermissions

Per eseguire senza prompt i comandi Bash rm e rmdir che prendono di mira percorsi critici in modalità bypassPermissions, avvia Claude Code con CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 nel suo ambiente. Questo richiede Claude Code v2.1.311 o successivo. Claude Code legge la variabile solo dall'ambiente di avvio e la ignora nel blocco env di un file di impostazioni. Ad esempio, impostala nella tua shell e avvia claude da lì:

macOS, Linux, WSL

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

Windows PowerShell

$env:CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS = "1"
claude --permission-mode bypassPermissions

Windows CMD

set CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

[!WARNING]

Con questa variabile impostata, perdi una richiesta di conferma di sicurezza per le eliminazioni distruttive: un comando come rm -rf ~ può essere eseguito senza chiederti nulla. Impostala solo in un ambiente isolato il cui contenuto puoi permetterti di perdere.

Le rimozioni vengono eseguite senza prompt solo nella modalità bypassPermissions stessa, non in plan mode, e solo per ciò che il controllo dei percorsi critici segnala negli strumenti Bash e Monitor. Ciò include i comandi che Claude Code non riesce ad analizzare completamente, che vengono anch'essi eseguiti senza prompt.

Avvisi all'avvio sul prompt di rimozione dei percorsi critici

Per verificare se CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS funziona, leggi la riga che Claude Code stampa all'avvio. In un'esecuzione -p, si trova su stderr. In un'app Agent SDK, passa l'opzione stderr per leggerla. La riga dice una di queste cose:

• is set, so dangerous rm commands can run without a prompt: le rimozioni possono essere eseguite senza prompt una volta caricati le impostazioni gestite e gli hook dei plugin. Se le rimozioni continuano a ricevere un prompt o una negazione, consulta Perché il prompt di rimozione dei percorsi critici resta attivo
• has no effect in this session: le rimozioni mantengono il loro consueto prompt o la loro consueta negazione per l'intera sessione. Per cambiare questa situazione, trova il tuo caso in Perché il prompt di rimozione dei percorsi critici resta attivo
• has no effect while the Windows registry cannot be read for managed settings: le rimozioni mantengono il loro consueto prompt o la loro consueta negazione, e la variabile ha effetto senza riavvio se una lettura successiva del registro di sistema riesce. Se le rimozioni continuano a ricevere un prompt o una negazione, consulta Perché il prompt di rimozione dei percorsi critici resta attivo

L'assenza della riga non significa che il prompt sia attivo: un'app Agent SDK senza opzione stderr non vede alcuna riga, e le rimozioni possono comunque essere eseguite senza prompt. Altrimenti, verifica di aver impostato la variabile nell'ambiente di avvio, che la sessione possa entrare in modalità bypassPermissions e che claude non si trovi dentro un'altra sessione. Alcune sessioni si avviano senza la variabile.

Se vedi una di queste righe e non hai impostato la variabile, trova dove è impostata, ad esempio nel profilo della tua shell, e rimuovila.

Perché il prompt di rimozione dei percorsi critici resta attivo

Se CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS non ha effetto e le rimozioni mantengono il loro consueto prompt o la loro consueta negazione, verifica cause come queste:

• Qualcos'altro gestisce le richieste di permesso: un --permission-prompt-tool o una callback canUseTool dell'Agent SDK senza --permission-prompts none, un hook PermissionRequest con qualsiasi matcher, o un mod che gestisce quell'evento. Rimuovi l'hook, il mod, lo strumento o la callback e riavvia claude
• La sessione è eseguita dal pannello chat dell'estensione VS Code o dall'app Desktop: avvia invece claude in un terminale, ad esempio il terminale integrato di un IDE
• Una regola riguarda Bash, Edit o Read: una regola deny o ask che prende di mira uno di questi strumenti, all'avvio o quando Claude Code la legge durante la sessione, anche se la rimuovi in seguito. Rimuovi la regola e riavvia claude. Per escludere uno strumento, usa --tools invece di una regola deny
• permissions.blockReadsOutsideWorkingDirectories è attivo: rimuovi l'impostazione da ogni file di impostazioni che la imposta su true, poi riavvia claude
• claude è in esecuzione dentro un'altra sessione: un claude avviato dallo strumento Bash di una sessione o da un hook, anche con la variabile sulla sua riga di comando. Avvia claude dalla tua shell. Non fare affidamento su questo limite delle sessioni annidate come confine di sicurezza
• Un hook PreToolUse risponde ask per una rimozione: cambia ciò che l'hook restituisce
• Claude Code avvia la sessione per te: le sessioni in background, i membri di un team di agenti in riquadri divisi e le sessioni create da un server Remote Control si avviano senza la variabile. Avvia claude dalla tua shell
• Le impostazioni gestite non possono essere lette: Claude Code non è riuscito a leggere le origini delle tue impostazioni gestite. Se le impostazioni gestite dal server continuano a non caricarsi, consulta Remote managed settings failed to load. Per qualsiasi altro errore che non sia una query del registro di sistema, chiedi a chi gestisce quell'origine di risolverlo
• Il registro di sistema di Windows non può essere interrogato: su Windows e in WSL, la variabile ha bisogno di una risposta dal registro di sistema, anche quando WSL non lo usa per le impostazioni. La query può fallire per tutta la sessione su un Windows non in inglese, in WSL con l'interoperabilità disattivata o in un container su un kernel WSL2. Se l'interoperabilità è disattivata, attivala. Altrimenti, esegui tu stesso quelle rimozioni

Remove-Item in PowerShell

Quando abiliti lo strumento PowerShell, Claude Code dà a Remove-Item e ai built-in cmd rd, rmdir, del, e erase i loro propri controlli, separati dall'elenco di percorsi critici rm. Per Remove-Item, 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.

Il caso dei percorsi di sistema si applica anche a rd, rmdir, del, e erase quando Claude li esegue attraverso cmd, come in cmd /c rd /s /q C:\Users. Per impostazione predefinita, Claude Code nega tale comando in ogni modalità, senza chiederti. Questo controllo cmd richiede Claude Code v2.1.283 o successivo.

Nel giudicare un target cmd, Claude Code tratta una variabile PowerShell che segue testo letterale come vuota. Questo rende cmd /c rd /s /q "C:\$name" una rimozione di C:\, quindi viene negata anche. Un wildcard finale conta come la cartella che svuota, quindi cmd /c del /q C:\* viene negato e cmd /c del /q dist\* nel tuo progetto non lo è.

Per disattivare il controllo cmd, imposta CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1 nell'ambiente che avvia Claude Code. Claude Code ignora questa variabile nel blocco env di un file di impostazioni. Remove-Item su un percorso di sistema rimane negato comunque.

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