Permessi e modalità dei permessi

Intermedio

Ultima verifica: 2026-07-14.

La sintassi esatta delle regole e i nomi delle modalità evolvono — verifica rispetto alla documentazione ufficiale di Claude Code su permessi e modalità dei permessi.

Conferma confrontando con la fonte ufficiale.

What you'll learn

• Cosa significano i tre verdetti dei permessi (allow / ask / deny)
• Come una regola di permesso abbina uno strumento più un pattern
• Le sei modalità dei permessi e quando usare ciascuna
• Come la modalità auto sostituisce le richieste con un classificatore di sicurezza
• Come costruire una allowlist iniziale sensata che riduca le richieste senza perdere sicurezza
• Dove memorizzare le regole dei permessi di progetto rispetto a quelle personali

I permessi decidono cosa Claude Code può fare senza fermarsi a chiederti il consenso. Regolali bene e ottieni fluidità senza perdere il controllo; regolali male e finisci per approvare tutto a scatola chiusa oppure per annegare nelle richieste.

I tre verdetti

Ogni azione potenziale si risolve in uno tra:

Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.

1 / 3

Le regole abbinano tipicamente uno strumento più un pattern, ad es. consenti Bash(npm run test:*) o nega Read(./.env).

Consenti uno strumento + pattern

Bash(npm run test:*)

Nega uno strumento + pattern

Read(./.env)

Modalità dei permessi

Una modalità imposta la postura complessiva per una sessione. Sono sei. Scorri quelle più comuni con Shift+Tab, oppure imposta permissions.defaultMode nelle impostazioni.

Modalità	Esegue senza chiedere	Usala quando
default (mostrata come Manual)	Solo letture	Lavoro quotidiano, modifiche sensibili
acceptEdits	Letture, modifiche ai file, comandi comuni sul filesystem	Una sessione di editing fidata e ben circoscritta
plan	Solo letture; propone, non modifica mai	Task grandi/rischiosi — vedi Modalità Plan
auto	Tutto, filtrato da un classificatore di sicurezza	Task lunghi in cui il vero rischio è la stanchezza da richieste
dontAsk	Solo gli strumenti preautorizzati; tutto il resto è negato	CI e script blindati
bypassPermissions	Tutto, nessun controllo	Solo sandbox/container — mai su una macchina con segreti

Modalità auto

auto è la via di mezzo tra chiedere conferma per tutto e disattivare la sicurezza. Invece di chiederti il consenso, un modello classificatore separato esamina ogni azione prima che venga eseguita e blocca tutto ciò che va oltre quanto hai chiesto, tocca infrastrutture che non riconosce o sembra guidato da contenuti ostili appena letti da Claude. Le regole ask esplicite continuano a fermarsi e a chiederti il consenso.

Blocca cose come curl | bash, force push, deploy e migrazioni in produzione e l'invio di segreti a endpoint esterni — lasciando invece passare direttamente il lavoro di routine (modifiche locali, installazione di dipendenze dichiarate, HTTP in sola lettura, push sul tuo branch). Se blocca ripetutamente la stessa azione, la modalità auto si mette in pausa e restituisce a te il compito di decidere.

La modalità auto non è una garanzia di sicurezza — riduce le richieste, non elimina la necessità di rivedere le operazioni sensibili. La disponibilità dipende dal tuo piano, dal modello e (su Team/Enterprise) da un'opzione dell'amministratore.

Watch out

• bypassPermissions va in una sandbox. Eseguire con tutte le richieste disattivate sulla tua macchina reale è il modo in cui un agente finisce per toccare qualcosa che non dovrebbe. Riservalo agli ambienti usa e getta — se quello che vuoi davvero sono meno richieste, usa invece la modalità auto. Vedi Rendere robuste le esecuzioni autonome su /docs/security/hardening-autonomous-runs.

Una allowlist iniziale sensata

L'obiettivo: preautorizzare le cose sicure e ripetitive; tenere le cose distruttive su ask o deny.

Guided walkthrough1 of 3

1. Leggere file, eseguire i tuoi comandi di test/lint/build, git status/diff.

Conserva le regole di progetto in settings.json (condivise) e gli override personali in settings.local.json.

Pro tip

• Lascia che impari dalle tue richieste: approva lo stesso comando sicuro alcune volte e saprai esattamente cosa aggiungere alla tua allowlist — trasformando richieste ripetute in una regola una tantum.

Key takeaways

• Tre verdetti: allow (nessuna richiesta), ask (predefinito — fermati e conferma), deny (mai).
• Le regole abbinano uno strumento più un pattern, come Bash(npm run test:*) o Read(./.env).
• Sei modalità impostano la postura della sessione: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
• La modalità auto filtra ogni azione attraverso un classificatore di sicurezza invece di chiederti conferma — è questo lo strumento contro la stanchezza da richieste, non bypassPermissions.
• Costruisci una allowlist: consenti ciò che è sicuro + ripetitivo, chiedi per il rischio medio, nega ciò che è distruttivo.
• Le regole condivise vanno in settings.json; gli override personali in settings.local.json.

Mettiti alla prova

0/5

1. 1Cosa fa il verdetto predefinito 'ask' per un'azione che non è esplicitamente consentita o negata?
2. 2Quale modalità dei permessi è sicura SOLO in sandbox o container, mai su una macchina con segreti?
3. 3Vuoi molte meno richieste di permesso durante un task lungo, ma vuoi comunque una rete di sicurezza. Quale modalità?
4. 4Dove dovresti memorizzare le regole dei permessi di progetto condivise rispetto agli override personali?
5. 5Quale di queste appartiene alla lista 'deny' in una allowlist iniziale sensata?

Avanti

• settings.json: il sistema di configurazione
• Hooks — imponi le regole in modo deterministico, oltre ad allow/deny
• Sicurezza e uso responsabile