Hook e permessi di Claude Code: le regole che valgono sempre

Quali sono le modalità dei permessi?

Sono il livello di partenza: decidono quanto Claude può fare senza fermarsi. Durante una sessione si cambiano con Maiusc+Tab.

Modalità	Che cosa fa da solo	Quando usarla
Manual	Legge; per il resto chiede	Lavori delicati, per capire che cosa fa
Edit automatically (acceptEdits)	Legge, modifica i file ed esegue i comandi comuni sui file, come mkdir, touch, mv e cp; gli altri li chiede	Lavoro normale, sotto i tuoi occhi
Plan	Studia e propone, senza modificare	Prima di una decisione
Auto	Quasi tutto, con un controllo automatico	Compiti lunghi su cartelle con backup
dontAsk	Solo ciò che è già consentito; il resto è negato	Script con un elenco esatto
Bypass	Salta i controlli	Solo in un ambiente isolato

Rispondere «sì, e non chiedermelo più» non vale sempre allo stesso modo: per un comando del terminale o un dominio web diventa una regola salvata per quel repository, per la modifica dei file vale solo fino alla fine della sessione.

Ricontrollato l’8 novembre 2026 su Claude Code 2.1.319.

Come si scrivono le regole dei permessi?

In un file di impostazioni, con tre elenchi. L’ordine è sempre lo stesso, deny poi ask poi allow, e quanto è specifica una regola non cambia l’ordine: un divieto generale batte un permesso preciso.

{
  "permissions": {
    "allow": ["Bash(python test/verifica.py)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Edit(./input/**)"]
  }
}

File	Vale per	In git
~/.claude/settings.json	Te, ovunque	No
.claude/settings.json	Chi lavora al progetto	Sì
.claude/settings.local.json	Te, in quel progetto	No

Fra un valore e l’altro vince il file più specifico, ma le liste come permissions.allow si sommano: ogni file aggiunge voci senza togliere quelle degli altri. Su Windows i percorsi completi si scrivono in forma Unix: C:\Dati diventa //c/Dati/**.

Una regola sui comandi confronta il testo del comando: lo stesso programma lanciato in un altro modo può sfuggire. Per i file più delicati, come chiavi e password, il modo più sicuro resta non tenerli nella cartella di lavoro.

Che cos’è un hook?

Un comando che Claude Code lancia da solo quando succede qualcosa. Si scrive nel file di impostazioni e non dipende dal modello: se l’evento accade, l’hook parte.

Evento	Quando	Esempio d’uso
PreToolUse	Prima di usare uno strumento	Bloccare la modifica di una cartella
PostToolUse	Dopo aver usato uno strumento	Formattare il file modificato
Stop	Quando Claude sta per fermarsi	Non lasciarlo finire se le prove falliscono
SessionStart	All’avvio della sessione	Mettere nel contesto lo stato del progetto
Notification	Quando Claude ti cerca	Avvisarti con una notifica

Un esempio inventato: a ogni modifica di un file, parte la verifica del feed.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "python test/verifica.py" }
        ]
      }
    ]
  }
}

Oltre ai comandi esistono altri tipi di hook: http, prompt, agent, che affida il controllo a un sotto-agente, e mcp_tool, che chiama lo strumento di un server MCP.

Come fa un hook a bloccare un’azione?

Con il suo esito: il codice di uscita dice a Claude Code come proseguire. L’errore più comune è pensare che valga allo stesso modo per ogni evento.

Esito	Che cosa succede
Codice 0	Tutto bene. Ciò che scrive sull’uscita degli errori Claude non lo vede
Codice 2	Dipende dall’evento: su PreToolUse blocca lo strumento e l’errore torna a Claude; su Stop gli impedisce di fermarsi
Altri codici	Errore che non blocca: l’azione prosegue, a meno che l’hook abbia “onFailure“: “block” (dalla 2.1.295). Su Windows senza Git Bash un hook PreToolUse che fallisce può invece bloccare

Alcuni eventi non possono bloccare nulla: con PermissionRequest, per esempio, il codice 2 non viene considerato. Prima di fidarti di un hook di protezione, fallo scattare apposta su un file di prova. Un hook che non blocca dà la stessa sensazione di sicurezza di uno che funziona.

Su Windows, prima della versione 2.1.316, un hook PowerShell poteva non bloccare con il codice 2 quando il comando cominciava, per esempio, con param o con un cast di tipo. Anche per questo va provato.

Un hook sbagliato può anche fermare ogni modifica, o girare a ogni passo rallentando tutto: meglio aggiungerne uno alla volta. Se un hook non sembra partire, altri rimedi sono nella guida agli errori comuni.

Quando usare che cosa?

La domanda da farsi è: se la regola non viene rispettata una volta, che cosa succede? Se un danno vero, non basta scriverla in un testo.

Regola	Dove	Perché
Il file delle chiavi non si legge	deny	Nessuna eccezione
Le prove partono dopo ogni modifica	Hook	Non deve ricordarselo nessuno
I costi sono IVA esclusa	CLAUDE.md	È un’informazione, non un divieto
Il rapporto settimanale segue cinque passi	Skill	Serve solo quando serve

Le protezioni contano soprattutto quando nessuno guarda: la guida al lavoro in automatico spiega perché in uno script la modalità va sempre scritta.

Per chi lavora sui dati di un negozio, tre regole semplici valgono quasi sempre: i file di partenza non si modificano, le credenziali non stanno dove Claude lavora, niente va caricato su Merchant Center o sul sito senza che una persona lo decida. Su quali dati dare a un modello, e con quali cautele, c’è la pagina su Claude per e-commerce.

Domande frequenti

Fonti

• Claude Code: Permissions
• Claude Code: Permission modes
• Claude Code: Hooks reference
• Claude Code: Settings
• Claude Code: changelog (2.1.316)