Claude Code continua a chiedere l'autorizzazione? Risolvi senza --dangerously-skip-permissions
Approvare npm test per la quarantesima volta è solo rumore. Claude Code ha tutto quello che serve per zittire le richieste noiose e tenere quelle pericolose. È solo distribuito su tre file e sei modalità.
RISPOSTA BREVE
Metti i comandi che approvi sempre in permissions.allow (ad esempio Bash(npm run *)), quelli che devono fermarsi sempre in ask o deny, e scegli una modalità di autorizzazione adatta all'attività: acceptEdits per molte modifiche, auto per il lavoro di routine, plan per la lettura. Le regole vengono valutate nell'ordine deny → ask → allow, quindi un deny non può mai essere scavalcato. Usa /permissions per vedere da dove arriva ogni regola. Riserva --dangerously-skip-permissions ai container usa e getta.
Perché Claude Code chiede così spesso
Nella modalità predefinita (indicata come Manual nella CLI), Claude Code chiede conferma la prima volta che usa ciascuno strumento e la richiede di nuovo per ogni comando shell che non è ancora autorizzato a eseguire. La richiesta è il momento in cui puoi fermare un rm sbagliato o un git push accidentale, quindi vale la pena tenerla. Il problema è che compare anche per le centinaia di operazioni innocue che un agente svolge in una sessione.
Tre fattori decidono se vedi una richiesta: le regole nei file di impostazioni, la modalità di autorizzazione in cui ti trovi e le risposte date in precedenza con “Yes, and don't ask again”. Per ridurre il rumore devi regolare tutti e tre.
Dalla v2.1.283 in poi, Claude Code avvia le sessioni interattive nel terminale e in VS Code in modalità auto, con qualsiasi piano e provider. In modalità auto un classificatore in background confronta comandi e richieste di rete con ciò che hai chiesto, invece di chiederti conferma per le azioni di routine. Se vedi ancora una richiesta per ogni cosa, controlla la barra di stato: “⏸ manual mode on” significa che sei nella modalità predefinita.
Regole allow, ask e deny
Le regole si trovano sotto permissions in un file di impostazioni. Questo esempio viene direttamente dal riferimento delle impostazioni di Anthropic:
allow: viene eseguito senza chiedere.ask: chiede sempre, anche nelle modalità che altrimenti lo approverebbero.deny: non viene mai eseguito.
L'ordine è la parte importante: deny, poi ask, poi allow. Vince la prima corrispondenza, e una regola più specifica non cambia l'ordine. Una regola allow non può ritagliare un'eccezione in una regola deny, e se uno strumento è negato a un qualsiasi livello, nessun altro livello può consentirlo. Le regole sono applicate da Claude Code stesso, non dal modello, quindi scrivere “never push” in CLAUDE.md non ha lo stesso effetto di una regola deny.
Come scrivere una regola
| Regola | A cosa corrisponde |
|---|---|
Bash(npm run *) | npm run build, npm run test --watch, ma non npm install |
Bash(git log *) | Solo git log …. Confronta con Bash(git *), che consente qualsiasi comando git. |
Bash(ls:*) | Equivale a Bash(ls *): :* è un altro modo di scrivere un carattere jolly finale |
Read(./.env) | La lettura di quel file. Le regole Read ed Edit usano i pattern di gitignore |
Edit(//Users/alice/notes/**) | Un percorso assoluto. Una sola / iniziale è relativa al file di impostazioni, quindi i percorsi assoluti richiedono // |
WebFetch(domain:example.com) | Solo example.com. Aggiungi WebFetch(domain:*.example.com) per i sottodomini |
mcp__github__* | Tutti gli strumenti del server MCP github. Le regole con parentesi dopo mcp__ vengono ignorate |
Su Windows, le regole PowerShell hanno la stessa forma delle regole Bash.
Quale file di impostazioni usare
| Ambito | File | Da usare per |
|---|---|---|
| Utente | ~/.claude/settings.json (Windows: %USERPROFILE%\.claude\settings.json) | Le tue abitudini, in ogni progetto |
| Progetto, condiviso | .claude/settings.json | Regole che tutto il team deve ricevere (da committare) |
| Progetto, locale | .claude/settings.local.json | Le tue regole personali per un repository (non committate) |
| Gestito | managed-settings.json e altre origini gestite | Criteri aziendali; niente può sovrascriverli |
Precedenza, dalla più alta: gestito, riga di comando, progetto locale, progetto condiviso, utente. Le chiavi di tipo elenco come permissions.allow vengono unite tra i file, non sostituite. Due dettagli traggono spesso in inganno:
- I file di impostazioni sono JSON rigoroso: un commento
//o una virgola finale sono un errore di sintassi, e l'intero file viene ignorato. - Le regole allow in un file di progetto condiviso si applicano solo dopo che ogni membro del team ha considerato attendibile la cartella. Le regole deny e ask si applicano subito.
La maggior parte delle modifiche si applica alla sessione in corso senza riavvio, compresi permissions e hooks. Per vedere cosa è stato caricato davvero, esegui /status (riga Setting sources) oppure /permissions, che elenca ogni regola e il file da cui proviene.
Cosa salva davvero “Yes, and don't ask again”
Rispondere a una richiesta con “don't ask again” scrive una regola per te in .claude/settings.local.json, nella radice del repository git. Quanto dura dipende dallo strumento:
| Strumento | Memorizzato |
|---|---|
| Comandi Bash | In modo permanente, per repository e comando |
| Modifiche ai file | Fino alla fine della sessione |
| WebFetch | In modo permanente, per repository e dominio |
Quindi, se Claude continua a chiedere di modificare file a ogni nuova sessione, è voluto: le approvazioni delle modifiche ai file valgono per una sessione. Usa invece la modalità acceptEdits o una regola allow Edit(...). E se un comando continua a chiedere anche dopo “don't ask again”, cerca una regola ask in un file di progetto o gestito. Una regola allow nel tuo file locale non ha la precedenza su di essa.
Le modalità di autorizzazione e quando usarle
| Modalità | Cosa fa | Ideale per |
|---|---|---|
default (Manual) | Chiede al primo utilizzo di ciascuno strumento | Repository sconosciuti, lavoro rischioso |
acceptEdits | Accetta le modifiche ai file senza chiedere | Lunghi refactoring che rivedrai in git |
plan | Legge e pianifica, non modifica nulla | Esplorare una codebase, progettare una modifica |
auto | Nessuna richiesta di routine; un classificatore controlla prima comandi e richieste di rete | Il lavoro di tutti i giorni |
dontAsk | Non chiede | Script e automazione |
bypassPermissions | Salta le richieste, comprese le scritture in .git e .claude | Solo container o VM isolati |
Premi Shift+Tab per scorrere le modalità. Da auto, la prima pressione passa a default, poi default → acceptEdits → plan. Imposta la modalità iniziale con permissions.defaultMode; tieni presente che auto e bypassPermissions hanno effetto solo dalle impostazioni utente o gestite, non da un file di progetto.
Alcune cose chiedono sempre, in qualsiasi modalità compresa bypass: le regole ask esplicite, le domande che Claude ti rivolge e rm su percorsi critici, tra le altre. Gli amministratori possono disattivare le modalità rischiose impostando permissions.disableBypassPermissionsMode o permissions.disableAutoMode su "disable".
Su --dangerously-skip-permissions
--dangerously-skip-permissions equivale a --permission-mode bypassPermissions. La documentazione di Anthropic è chiara: usalo solo in ambienti isolati come container, VM o dev container senza accesso a Internet. Si rifiuta di funzionare come root su Linux e macOS e, una volta accettato l'avviso, imposta skipDangerousModePermissionPrompt nelle tue impostazioni utente.
Se quello che vuoi davvero è “smettila di chiedermi cose noiose”, la modalità auto più qualche regola allow ti porta lì senza rinunciare alle richieste che contano.
La sandbox: meno richieste, con una rete di sicurezza
Claude Code può eseguire i comandi shell in una sandbox. È disattivata per impostazione predefinita; attivala con /sandbox o sandbox.enabled: true. Una modalità della sandbox approva automaticamente i comandi eseguiti in sandbox, l'altra continua a chiedere. La sandbox copre solo i comandi shell: strumenti per i file, server MCP e hook vengono eseguiti fuori.
Funziona su macOS, Linux e WSL2. Su Windows nativo la sandbox non funziona e i comandi vengono eseguiti senza sandbox. È un motivo in più per tenere lì un breve elenco ask.
Una configurazione che funziona
Questo è un punto di partenza ragionevole per un progetto JavaScript. Adatta i comandi al tuo stack:
- Parti da un elenco allow di comandi di sola lettura e di test.
- Metti in
asktutto ciò che esce dalla tua macchina (push, publish, deploy). - Nega del tutto l'accesso ai segreti.
- Lavora in modalità auto o acceptEdits e passa alla modalità plan quando esplori.
- Ogni qualche giorno apri
.claude/settings.local.jsone sfoltisci le regole aggiunte da “don't ask again”.
Quando le richieste rimaste compaiono nel posto sbagliato
Dopo la messa a punto, dovresti ricevere domande solo su ciò che merita una decisione. Il problema che resta è dove compare la domanda: in una scheda del terminale dietro il browser, dove l'agente può aspettare venti minuti prima che te ne accorga.
Pet Island sposta queste domande su una piccola isola nella parte alta dello schermo. Quando Claude Code ha bisogno di un'autorizzazione, la richiesta compare lì con il comando o il diff, e puoi consentirla, negarla o consentirla sempre senza cambiare finestra. Anche le domande e i piani di Claude Code funzionano dall'isola, e se l'isola è chiusa Claude Code torna semplicemente a chiedere nel terminale.
FAQ
Come faccio a impedire a Claude Code di chiedere l'autorizzazione per ogni comando?
Aggiungi i comandi di cui ti fidi a permissions.allow in ~/.claude/settings.json, ad esempio "Bash(npm run *)", e usa la modalità auto o acceptEdits. Tieni i comandi rischiosi in permissions.ask, così continueranno a fermarsi.
Perché Claude Code chiede di nuovo per le modifiche ai file dopo che ho scelto “don't ask again”?
Le approvazioni delle modifiche ai file durano solo fino alla fine della sessione. Usa la modalità acceptEdits o una regola allow Edit(...) se vuoi che le modifiche restino approvate tra una sessione e l'altra.
Una regola allow può prevalere su una regola deny?
No. Le regole vengono valutate nell'ordine deny, poi ask, poi allow, e vince la prima corrispondenza. Uno strumento negato a un qualsiasi livello non può essere consentito altrove.
--dangerously-skip-permissions è sicuro?
Anthropic lo consiglia solo in ambienti isolati come container o VM senza accesso a Internet. Salta anche le richieste per le scritture in .git e .claude.
Dove salva la regola “Yes, and don't ask again”?
In .claude/settings.local.json, nella radice del repository git.
La sandbox di Claude Code funziona su Windows?
Non su Windows nativo, dove i comandi vengono eseguiti senza sandbox. Funziona su macOS, Linux e WSL2.
Fonti
Ogni impostazione e comportamento descritti in questa pagina sono stati verificati su queste pagine il 26 ottobre 2026. Gli agenti cambiano in fretta: se qualcosa non corrisponde più, fa fede la pagina ufficiale.
- Documentazione di Claude Code: Configure permissions
- Documentazione di Claude Code: Permission modes
- Documentazione di Claude Code: Settings
- Documentazione di Claude Code: Settings reference
- Documentazione di Claude Code: Sandboxing