Passa al contenuto principale

Permessi e modalità di permesso

Intermedio
What you'll learn
  • Cosa significano i tre verdetti di permesso (allow / ask / deny)
  • Come le regole di permesso abbinano uno strumento a un pattern
  • Le sei modalità di permesso e quando usare ciascuna
  • Perché auto è ora la modalità iniziale delle sessioni interattive — e come disattivarla
  • Come la modalità auto sostituisce le richieste con un classificatore di sicurezza
  • Come costruire una allowlist iniziale sensata che riduce le richieste senza perdere sicurezza
  • Dove salvare le regole di permesso di progetto e quelle personali

I permessi decidono cosa Claude Code può fare senza fermarsi a chiederti conferma. Se li regoli bene ottieni flusso senza perdere il controllo; se li regoli male o approvi tutto a occhi chiusi, o affoghi nelle richieste.

I tre verdetti​

Ogni azione possibile si risolve in uno di questi:

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 di solito uno strumento a un pattern, ad esempio allow Bash(npm run test:*) o deny Read(./.env).

Consenti uno strumento + pattern

Bash(npm run test:*)

Nega uno strumento + pattern

Read(./.env)

Modalità di permesso​

Una modalità definisce l'atteggiamento generale di una sessione. Ce ne sono sei. Passa in rassegna quelle più comuni con Shift+Tab, oppure imposta permissions.defaultMode nelle impostazioni.

ModalitàEsegue senza chiedereQuando usarla
default (mostrata come Manual)Solo lettureLavoro quotidiano, modifiche delicate
acceptEditsLetture, modifiche ai file, comandi comuni del filesystemUna sessione di editing fidata e ben delimitata
planLetture, più i comandi approvati dal classificatore quando la modalità auto è disponibile; non modifica mai il tuo codice sorgenteTask grandi o rischiosi — vedi Plan Mode
auto (la modalità iniziale delle sessioni interattive dalla v2.1.283)Tutto, filtrato da un classificatore di sicurezzaTask lunghi in cui il vero rischio è la stanchezza da conferme
dontAskLetture di file nelle tue directory di lavoro e strumenti pre-approvati; tutto ciò che richiederebbe conferma viene negatoCI e script blindati
bypassPermissionsTutto, senza controlliSolo sandbox/container — mai su una macchina con segreti

La modalità auto ora è quella predefinita di Claude Code​

Dalla versione v2.1.283 di Claude Code, auto è la modalità iniziale integrata per le sessioni interattive da terminale e VS Code su ogni piano e provider. Nelle versioni precedenti era il default per le nuove sessioni solo sui piani Pro, Max e Team, dal 14 agosto 2026. La motivazione di Anthropic (dai suoi test su oltre 1.000 utenti paganti): il classificatore ha intercettato l'89% delle azioni dannose contro il 13,6% della revisione manuale — perché gli utenti, ormai abituati, accettavano circa il 97% delle richieste manuali senza leggerle.

Due eccezioni preservano l'intenzione:

  • Se tu imposti permissions.defaultMode nelle tue impostazioni utente, resta com'è a meno che tu non accetti una singola richiesta di passaggio nell'app.
  • Se la tua organizzazione gestisce il default (impostazioni gestite Team/Enterprise), non cambia nulla in automatico.

Puoi sempre cambiare modalità durante la sessione con Shift+Tab. Una modifica correlata già in vigore su quei piani: le chiamate al classificatore effettuate dalla modalità auto non contano più nei tuoi limiti d'uso.

Attivala in anticipo (prima del 14 ago) — imposta auto come predefinita

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "auto"
}
}

Mantieni il vecchio comportamento con le conferme dopo il 14 ago

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "default"
}
}

Come funziona davvero la modalità auto​

auto è la via di mezzo tra chiedere conferma per tutto e disattivare la sicurezza. Invece di chiedere a te, 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 che Claude ha appena letto. Le regole ask esplicite continuano a fermarsi e a chiederti conferma.

Blocca cose come curl | bash, force push, deploy e migrazioni in produzione, rm -rf su variabili non risolte, manomissioni della trascrizione, comandi git distruttivi che scartano lavoro non committato e l'invio di segreti a endpoint esterni — lasciando passare il lavoro di routine (modifiche locali, installazione di dipendenze dichiarate, HTTP in sola lettura, push sul tuo branch). Se blocca la stessa azione ripetutamente, la modalità auto si ferma e ti restituisce la gestione delle richieste.

La modalità auto non è una garanzia di sicurezza: riduce le richieste, ma non elimina la necessità di rivedere le operazioni delicate. La disponibilità dipende dal piano, dal modello e (su Team/Enterprise) da un interruttore dell'amministratore. Se lavori in modo davvero non presidiato (cron, sessioni cloud, CI), abbinala a Hardening Autonomous Runs — auto non equivale comunque a bypassPermissions.

Watch out
  • bypassPermissions va usato in una sandbox. Lavorare con tutte le richieste disattivate sulla tua macchina reale è il modo in cui un agente finisce per toccare qualcosa che non doveva. Riservalo ad ambienti usa e getta — se quello che vuoi davvero è meno richieste, usa invece la modalità auto. Vedi Hardening Autonomous Runs su /docs/security/hardening-autonomous-runs.

Una allowlist iniziale sensata​

L'obiettivo: pre-autorizzare le cose sicure e ripetitive; lasciare quelle distruttive su ask o deny.

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

Salva le regole di progetto in settings.json (condiviso) e le preferenze personali in settings.local.json.

Pro tip
  • Lascia che impari dalle tue richieste: approva lo stesso comando sicuro un paio di volte e saprai esattamente cosa aggiungere alla tua allowlist — trasformando le conferme 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 a un pattern, come Bash(npm run test:*) o Read(./.env).
  • Sei modalità definiscono l'atteggiamento della sessione: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
  • Dalla v2.1.283, auto è la modalità iniziale delle sessioni interattive da terminale e VS Code su ogni piano; un defaultMode impostato da te resta al suo posto e i default gestiti dall'organizzazione non vengono toccati.
  • La modalità auto filtra ogni azione con un classificatore di sicurezza invece di chiederti conferma — è lo strumento contro la stanchezza da richieste, non bypassPermissions.
  • Costruisci una allowlist: allow per ciò che è sicuro e ripetitivo, ask per il rischio medio, deny per il distruttivo.
  • Le regole condivise vanno in settings.json; le preferenze personali in settings.local.json.

Verifica te stesso

0/6
  1. Cosa fa il verdetto predefinito 'ask' per un'azione non esplicitamente consentita né negata?
  2. Quale modalità di permesso è sicura SOLO in sandbox o container, mai su una macchina con segreti?
  3. Vuoi molte meno richieste di permesso in un task lungo, ma vuoi comunque una rete di sicurezza. Quale modalità?
  4. Dove vanno salvate le regole di permesso condivise di progetto rispetto alle preferenze personali?
  5. Quale di queste va nella lista 'deny' di una allowlist iniziale sensata?
  6. Il 14 agosto 2026, cosa succede su un piano Pro se avevi già impostato permissions.defaultMode su 'default' nelle tue impostazioni utente?

Prossimo​