Configurare le autorizzazioni

Controlla cosa Claude Code può accedere e fare con regole di autorizzazione granulari, modalità e criteri gestiti.

Claude Code supporta autorizzazioni granulari in modo che Lei possa specificare esattamente cosa l'agente è autorizzato a fare e cosa non può fare. Le impostazioni di autorizzazione possono essere archiviate nel controllo della versione e distribuite a tutti gli sviluppatori della Sua organizzazione, nonché personalizzate dai singoli sviluppatori.

Sistema di autorizzazione

Claude Code utilizza un sistema di autorizzazione a livelli per bilanciare potenza e sicurezza:

Tipo di strumento	Esempio	Approvazione richiesta	Comportamento "Sì, non chiedere più"
Sola lettura	Letture di file, Grep	No	N/A
Comandi Bash	Esecuzione shell	Sì	Permanentemente per directory di progetto e comando
Modifica di file	Edit/Write di file	Sì	Fino alla fine della sessione

Gestire le autorizzazioni

Potete visualizzare e gestire le autorizzazioni degli strumenti di Claude Code con /permissions. Questa interfaccia utente elenca tutte le regole di autorizzazione e il file settings.json da cui provengono.

Le regole Allow consentono a Claude Code di utilizzare lo strumento specificato senza approvazione manuale.
Le regole Ask richiedono una conferma ogni volta che Claude Code tenta di utilizzare lo strumento specificato.
Le regole Deny impediscono a Claude Code di utilizzare lo strumento specificato.

Le regole vengono valutate in ordine: deny -> ask -> allow. La prima regola corrispondente vince, quindi le regole deny hanno sempre la precedenza.

Modalità di autorizzazione

Claude Code supporta diverse modalità di autorizzazione che controllano come gli strumenti vengono approvati. Vedi Permission modes per quando utilizzare ciascuna. Impostate defaultMode nei vostri file di impostazioni:

Modalità	Descrizione
`default`	Comportamento standard: richiede l'autorizzazione al primo utilizzo di ogni strumento
`acceptEdits`	Accetta automaticamente le modifiche ai file e i comandi comuni del filesystem (`mkdir`, `touch`, `mv`, `cp`, ecc.) per i percorsi nella directory di lavoro o `additionalDirectories`
`plan`	Plan Mode: Claude può analizzare ma non modificare file o eseguire comandi
`auto`	Auto-approva le chiamate di strumento con controlli di sicurezza in background che verificano che le azioni si allineino con la Sua richiesta. Attualmente un'anteprima di ricerca
`dontAsk`	Nega automaticamente gli strumenti a meno che non siano pre-approvati tramite `/permissions` o regole `permissions.allow`
`bypassPermissions`	Salta i prompt di autorizzazione. Le rimozioni che hanno come destinazione la radice del filesystem o la directory home, come `rm -rf /` e `rm -rf ~`, richiedono comunque un prompt come interruttore di protezione contro gli errori del modello

Per prevenire che la modalità bypassPermissions o auto venga utilizzata, impostate permissions.disableBypassPermissionsMode o permissions.disableAutoMode su "disable" in qualsiasi file di impostazioni. Questi sono più utili nelle impostazioni gestite dove non possono essere ignorati.

Sintassi delle regole di autorizzazione

Le regole di autorizzazione seguono il formato Tool o Tool(specifier).

Corrispondere a tutti gli utilizzi di uno strumento

Per corrispondere a tutti gli utilizzi di uno strumento, utilizzate solo il nome dello strumento senza parentesi:

Regola	Effetto
`Bash`	Corrisponde a tutti i comandi Bash
`WebFetch`	Corrisponde a tutte le richieste di web fetch
`Read`	Corrisponde a tutte le letture di file

Bash(*) è equivalente a Bash e corrisponde a tutti i comandi Bash.

Utilizzare gli specificatori per il controllo granulare

Aggiungete uno specificatore tra parentesi per corrispondere a utilizzi specifici dello strumento:

Regola	Effetto
`Bash(npm run build)`	Corrisponde al comando esatto `npm run build`
`Read(./.env)`	Corrisponde alla lettura del file `.env` nella directory corrente
`WebFetch(domain:example.com)`	Corrisponde alle richieste di fetch a example.com

Modelli con caratteri jolly

Le regole Bash supportano modelli glob con *. I caratteri jolly possono apparire in qualsiasi posizione nel comando. Questa configurazione consente comandi npm e git commit mentre blocca git push:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Lo spazio prima di * è importante: Bash(ls *) corrisponde a ls -la ma non a lsof, mentre Bash(ls*) corrisponde a entrambi. Il suffisso :* è un modo equivalente per scrivere un carattere jolly finale, quindi Bash(ls:*) corrisponde agli stessi comandi di Bash(ls *).

La finestra di dialogo di autorizzazione scrive la forma separata da spazi quando selezionate "Sì, non chiedere più" per un prefisso di comando. La forma :* è riconosciuta solo alla fine di un modello. In un modello come Bash(git:* push), il due punti viene trattato come un carattere letterale e non corrisponderà ai comandi git.

Regole di autorizzazione specifiche dello strumento

Bash

Le regole di autorizzazione Bash supportano la corrispondenza con caratteri jolly con *. I caratteri jolly possono apparire in qualsiasi posizione nel comando, incluso all'inizio, nel mezzo o alla fine:

Bash(npm run build) corrisponde al comando Bash esatto npm run build
Bash(npm run test *) corrisponde ai comandi Bash che iniziano con npm run test
Bash(npm *) corrisponde a qualsiasi comando che inizia con npm
Bash(* install) corrisponde a qualsiasi comando che termina con install
Bash(git * main) corrisponde a comandi come git checkout main e git log --oneline main

Un singolo * corrisponde a qualsiasi sequenza di caratteri inclusi gli spazi, quindi un singolo carattere jolly può estendersi su più argomenti. Bash(git *) corrisponde a git log --oneline --all e Bash(git * main) corrisponde sia a git push origin main che a git merge main.

Quando * appare alla fine con uno spazio prima (come Bash(ls *)), applica un confine di parola, richiedendo che il prefisso sia seguito da uno spazio o dalla fine della stringa. Ad esempio, Bash(ls *) corrisponde a ls -la ma non a lsof. Al contrario, Bash(ls*) senza spazio corrisponde sia a ls -la che a lsof perché non c'è un vincolo di confine di parola.

Comandi composti

Quando approvate un comando composto con "Sì, non chiedere più", Claude Code salva una regola separata per ogni sottocomando che richiede approvazione, piuttosto che una singola regola per la stringa completa. Ad esempio, approvando git status && npm test salva una regola per npm test, quindi le future invocazioni di npm test vengono riconosciute indipendentemente da cosa precede &&. I sottocomandi come cd in una sottodirectory generano la loro propria regola Read per quel percorso. Fino a 5 regole possono essere salvate per un singolo comando composto.

Wrapper di processo

Prima di corrispondere alle regole Bash, Claude Code rimuove un insieme fisso di wrapper di processo in modo che una regola come Bash(npm test *) corrisponda anche a timeout 30 npm test. I wrapper riconosciuti sono timeout, time, nice, nohup e stdbuf.

Anche xargs nudo viene rimosso, quindi Bash(grep *) corrisponde a xargs grep pattern. La rimozione si applica solo quando xargs non ha flag: un'invocazione come xargs -n1 grep pattern viene abbinata come comando xargs, quindi le regole scritte per il comando interno non la coprono.

Questo elenco di wrapper è integrato e non è configurabile. I runner dell'ambiente di sviluppo come direnv exec, devbox run, mise exec, npx e docker exec non sono nell'elenco. Poiché questi strumenti eseguono i loro argomenti come comando, una regola come Bash(devbox run *) corrisponde a qualsiasi cosa venga dopo run, incluso devbox run rm -rf .. Per approvare il lavoro all'interno di un runner dell'ambiente, scrivete una regola specifica che includa sia il runner che il comando interno, come Bash(devbox run npm test). Aggiungete una regola per ogni comando interno che desiderate consentire.

I wrapper exec come watch, setsid, ionice e flock richiedono sempre un prompt e non possono essere auto-approvati da una regola di prefisso come Bash(watch *). Lo stesso vale per find con -exec o -delete: una regola Bash(find *) non copre queste forme. Per approvare un'invocazione specifica, scrivete una regola di corrispondenza esatta per la stringa di comando completa.

Comandi di sola lettura

Claude Code riconosce un insieme integrato di comandi Bash come di sola lettura e li esegue senza un prompt di autorizzazione in ogni modalità. Questi includono ls, cat, head, tail, grep, find, wc, diff, stat, du, cd e forme di sola lettura di git. L'insieme non è configurabile; per richiedere un prompt per uno di questi comandi, aggiungete una regola ask o deny per esso.

I modelli glob non quotati sono consentiti per i comandi il cui ogni flag è di sola lettura, quindi ls *.ts e wc -l src/*.py vengono eseguiti senza un prompt. I comandi con flag in grado di scrivere o eseguire, come find, sort, sed e git, richiedono comunque un prompt quando è presente un glob non quotato perché il glob potrebbe espandersi a un flag come -delete.

Un cd in un percorso all'interno della vostra directory di lavoro o di una directory aggiuntiva è anche di sola lettura. Un comando composto come cd packages/api && ls viene eseguito senza un prompt quando ogni parte si qualifica da sola. La combinazione di cd con git in un comando composto richiede sempre un prompt, indipendentemente dalla directory di destinazione.

Warning

I modelli di autorizzazione Bash che tentano di vincolare gli argomenti del comando sono fragili. Ad esempio, Bash(curl http://github.com/ *) intende limitare curl agli URL di GitHub, ma non corrisponderà a variazioni come:

Opzioni prima dell'URL: curl -X GET http://github.com/...
Protocollo diverso: curl https://github.com/...
Reindirizzamenti: curl -L http://bit.ly/xyz (reindirizza a github)
Variabili: URL=http://github.com && curl $URL
Spazi extra: curl http://github.com

Per un filtraggio URL più affidabile, considerate:

Limitare gli strumenti di rete Bash: utilizzate regole deny per bloccare curl, wget e comandi simili, quindi utilizzate lo strumento WebFetch con l'autorizzazione WebFetch(domain:github.com) per i domini consentiti
Utilizzare hook PreToolUse: implementate un hook che convalida gli URL nei comandi Bash e blocca i domini non consentiti
Istruire Claude Code sui vostri modelli curl consentiti tramite CLAUDE.md

Nota che l'utilizzo di WebFetch da solo non impedisce l'accesso alla rete. Se Bash è consentito, Claude può comunque utilizzare curl, wget o altri strumenti per raggiungere qualsiasi URL.

PowerShell

Le regole di autorizzazione PowerShell utilizzano la stessa forma delle regole Bash. I caratteri jolly con * corrispondono in qualsiasi posizione, il suffisso :* è equivalente a un * finale, e un PowerShell nudo o PowerShell(*) corrisponde a ogni comando. Questa configurazione consente comandi Get-ChildItem e git commit mentre blocca Remove-Item:

{
  "permissions": {
    "allow": [
      "PowerShell(Get-ChildItem *)",
      "PowerShell(git commit *)"
    ],
    "deny": [
      "PowerShell(Remove-Item *)"
    ]
  }
}

Gli alias comuni vengono canonicalizati prima della corrispondenza. Una regola scritta per il nome del cmdlet corrisponde anche ai suoi alias, quindi PowerShell(Get-ChildItem *) corrisponde a gci, ls e dir nonché. La corrispondenza non è sensibile alle maiuscole.

Claude Code analizza l'AST di PowerShell e controlla ogni comando in un comando composto indipendentemente. Gli operatori pipeline |, i separatori di istruzione ; e su PowerShell 7+ gli operatori di catena && e || dividono un comando composto in sottocomandi. Una regola deve corrispondere a ogni sottocomando affinché il comando composto sia consentito.

Read e Edit

Le regole Edit si applicano a tutti gli strumenti integrati che modificano i file. Claude fa un tentativo migliore per applicare le regole Read a tutti gli strumenti integrati che leggono file come Grep e Glob.

Le regole Read e Edit seguono entrambe la specifica gitignore con quattro tipi di modello distinti:

Modello	Significato	Esempio	Corrisponde
`//path`	Percorso assoluto dalla radice del filesystem	`Read(//Users/alice/secrets/**)`	`/Users/alice/secrets/**`
`~/path`	Percorso dalla directory home	`Read(~/Documents/*.pdf)`	`/Users/alice/Documents/*.pdf`
`/path`	Percorso relativo alla radice del progetto	`Edit(/src/*/.ts)`	`<project root>/src/*/.ts`
`path` o `./path`	Percorso relativo alla directory corrente	`Read(*.env)`	`<cwd>/*.env`

Su Windows, i percorsi vengono normalizzati in forma POSIX prima della corrispondenza. C:\Users\alice diventa /c/Users/alice, quindi utilizzate //c/**/.env per corrispondere ai file .env in qualsiasi punto su quel drive. Per corrispondere su tutti i drive, utilizzate //**/.env.

Esempi:

Edit(/docs/**): modifica in <project>/docs/ (NON /docs/ e NON <project>/.claude/docs/)
Read(~/.zshrc): legge il .zshrc della vostra directory home
Edit(//tmp/scratch.txt): modifica il percorso assoluto /tmp/scratch.txt
Read(src/**): legge da <current-directory>/src/

Quando Claude accede a un symlink, le regole di autorizzazione controllano due percorsi: il symlink stesso e il file a cui si risolve. Le regole allow e deny trattano quella coppia diversamente: le regole allow ricadono nel richiedere un prompt, mentre le regole deny bloccano completamente.

Regole allow: si applicano solo quando sia il percorso del symlink che il suo target corrispondono. Un symlink all'interno di una directory consentita che punta al di fuori di essa richiede comunque un prompt.
Regole deny: si applicano quando il percorso del symlink o il suo target corrisponde. Un symlink che punta a un file negato è esso stesso negato.

Ad esempio, con Read(./project/**) consentito e Read(~/.ssh/**) negato, un symlink in ./project/key che punta a ~/.ssh/id_rsa viene bloccato: il target non supera la regola allow e corrisponde alla regola deny.

WebFetch

WebFetch(domain:example.com) corrisponde alle richieste di fetch a example.com

MCP

mcp__puppeteer corrisponde a qualsiasi strumento fornito dal server puppeteer (nome configurato in Claude Code)
mcp__puppeteer__* sintassi con caratteri jolly che corrisponde anche a tutti gli strumenti dal server puppeteer
mcp__puppeteer__puppeteer_navigate corrisponde allo strumento puppeteer_navigate fornito dal server puppeteer

Agent (subagents)

Utilizzate le regole Agent(AgentName) per controllare quali subagents Claude può utilizzare:

Agent(Explore) corrisponde al subagent Explore
Agent(Plan) corrisponde al subagent Plan
Agent(my-custom-agent) corrisponde a un subagent personalizzato denominato my-custom-agent

Aggiungete queste regole all'array deny nelle vostre impostazioni o utilizzate il flag CLI --disallowedTools per disabilitare agenti specifici. Per disabilitare l'agente Explore:

{
  "permissions": {
    "deny": ["Agent(Explore)"]
  }
}

Estendere le autorizzazioni con hook

Gli hook di Claude Code forniscono un modo per registrare comandi shell personalizzati per eseguire la valutazione delle autorizzazioni in fase di esecuzione. Quando Claude Code effettua una chiamata di strumento, gli hook PreToolUse vengono eseguiti prima del prompt di autorizzazione. L'output dell'hook può negare la chiamata dello strumento, forzare un prompt o saltare il prompt per consentire alla chiamata di procedere.

Le decisioni dell'hook non bypassano le regole di autorizzazione. Le regole deny e ask vengono valutate indipendentemente da ciò che un hook PreToolUse restituisce, quindi una regola deny corrispondente blocca la chiamata e una regola ask corrispondente richiede comunque un prompt anche quando l'hook ha restituito "allow" o "ask". Questo preserva la precedenza deny-first descritta in Gestire le autorizzazioni, incluse le regole deny impostate nelle impostazioni gestite.

Un hook di blocco ha anche la precedenza sulle regole allow. Un hook che esce con codice 2 interrompe la chiamata dello strumento prima che le regole di autorizzazione vengono valutate, quindi il blocco si applica anche quando una regola allow consentirebbe altrimenti la chiamata. Per eseguire tutti i comandi Bash senza prompt tranne alcuni che desiderate bloccare, aggiungete "Bash" al vostro elenco allow e registrate un hook PreToolUse che rifiuta quei comandi specifici. Vedi Bloccare le modifiche ai file protetti per uno script di hook che potete adattare.

Directory di lavoro

Per impostazione predefinita, Claude ha accesso ai file nella directory in cui è stato avviato. Potete estendere questo accesso:

Durante l'avvio: utilizzate l'argomento CLI --add-dir <path>
Durante la sessione: utilizzate il comando /add-dir
Configurazione persistente: aggiungete a additionalDirectories nei file di impostazioni

I file nelle directory aggiuntive seguono le stesse regole di autorizzazione della directory di lavoro originale: diventano leggibili senza prompt e le autorizzazioni di modifica dei file seguono la modalità di autorizzazione corrente.

Le directory aggiuntive concedono l'accesso ai file, non la configurazione

L'aggiunta di una directory estende dove Claude può leggere e modificare i file. Non rende quella directory una radice di configurazione completa: la maggior parte della configurazione .claude/ non viene scoperta dalle directory aggiuntive, anche se alcuni tipi vengono caricati come eccezioni.

I seguenti tipi di configurazione vengono caricati dalle directory --add-dir:

Configurazione	Caricato da `--add-dir`
Skills in `.claude/skills/`	Sì, con ricaricamento live
Impostazioni plugin in `.claude/settings.json`	Solo `enabledPlugins` e `extraKnownMarketplaces`
File CLAUDE.md, `.claude/rules/` e `CLAUDE.local.md`	Solo quando `CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1` è impostato. `CLAUDE.local.md` richiede inoltre l'impostazione `local` source, che è abilitata per impostazione predefinita

Tutto il resto, inclusi subagents, commands, output styles, hooks e altre impostazioni, viene scoperto solo dalla directory di lavoro corrente e dai suoi genitori, dalla vostra directory utente in ~/.claude/ e dalle impostazioni gestite. Per condividere quella configurazione tra progetti, utilizzate uno di questi approcci:

Configurazione a livello utente: posizionate i file in ~/.claude/agents/, ~/.claude/output-styles/ o ~/.claude/settings.json per renderli disponibili in ogni progetto
Plugin: pacchetto e distribuite la configurazione come plugin che i team possono installare
Avviate dalla directory di configurazione: eseguite Claude Code dalla directory contenente la configurazione .claude/ che desiderate

Come le autorizzazioni interagiscono con il sandboxing

Le autorizzazioni e il sandboxing sono livelli di sicurezza complementari:

Autorizzazioni controllano quali strumenti Claude Code può utilizzare e quali file o domini può accedere. Si applicano a tutti gli strumenti (Bash, Read, Edit, WebFetch, MCP e altri).
Sandboxing fornisce l'applicazione a livello del sistema operativo che limita l'accesso al filesystem e alla rete dello strumento Bash. Si applica solo ai comandi Bash e ai loro processi figlio.

Utilizzate entrambi per la difesa in profondità:

Le regole deny di autorizzazione impediscono a Claude di tentare anche di accedere alle risorse limitate
Le restrizioni sandbox impediscono ai comandi Bash di raggiungere risorse al di fuori dei confini definiti, anche se un'iniezione di prompt bypassa il processo decisionale di Claude
Le restrizioni del filesystem nella sandbox utilizzano le regole deny di Read e Edit, non una configurazione sandbox separata
Le restrizioni di rete combinano le regole di autorizzazione WebFetch con gli elenchi allowedDomains e deniedDomains della sandbox

Quando il sandboxing è abilitato con autoAllowBashIfSandboxed: true, che è l'impostazione predefinita, i comandi Bash in sandbox vengono eseguiti senza richiedere un prompt anche se le vostre autorizzazioni includono ask: Bash(*). Il confine della sandbox sostituisce il prompt per comando. Le regole deny esplicite si applicano ancora, e i comandi rm o rmdir che hanno come destinazione /, la vostra directory home o altri percorsi critici del sistema attivano comunque un prompt. Consultate modalità sandbox per modificare questo comportamento.

Impostazioni gestite

Per le organizzazioni che necessitano di un controllo centralizzato sulla configurazione di Claude Code, gli amministratori possono distribuire impostazioni gestite che non possono essere ignorate dalle impostazioni utente o di progetto. Queste impostazioni di criteri seguono lo stesso formato dei file di impostazioni regolari e possono essere fornite tramite criteri MDM/a livello del sistema operativo, file di impostazioni gestite o impostazioni gestite dal server. Vedi file di impostazioni per i meccanismi di consegna e i percorsi dei file.

Impostazioni solo gestite

Le seguenti impostazioni sono efficaci solo nelle impostazioni gestite. Posizionarle nei file di impostazioni utente o di progetto non ha alcun effetto.

Impostazione	Descrizione
`allowedChannelPlugins`	Elenco di autorizzazione dei plugin di canale che possono inviare messaggi. Sostituisce l'elenco di autorizzazione Anthropic predefinito quando impostato. Richiede `channelsEnabled: true`. Vedi Limitare quali plugin di canale possono essere eseguiti
`allowManagedHooksOnly`	Quando `true`, solo gli hook gestiti, gli hook SDK e gli hook dai plugin force-enabled nelle impostazioni gestite `enabledPlugins` vengono caricati. Gli hook utente, progetto e tutti gli altri plugin vengono bloccati
`allowManagedMcpServersOnly`	Quando `true`, solo `allowedMcpServers` dalle impostazioni gestite sono rispettati. `deniedMcpServers` si unisce comunque da tutte le fonti. Vedi Configurazione MCP gestita
`allowManagedPermissionRulesOnly`	Quando `true`, impedisce alle impostazioni utente e di progetto di definire regole di autorizzazione `allow`, `ask` o `deny`. Si applicano solo le regole nelle impostazioni gestite
`blockedMarketplaces`	Elenco di blocco delle fonti del marketplace. Le fonti bloccate vengono controllate prima del download, quindi non toccano mai il filesystem. Vedi restrizioni marketplace gestite
`channelsEnabled`	Consenti channels per gli utenti Team e Enterprise. Non impostato o `false` blocca la consegna dei messaggi di canale indipendentemente da ciò che gli utenti passano a `--channels`
`forceRemoteSettingsRefresh`	Quando `true`, blocca l'avvio della CLI fino a quando le impostazioni gestite remote non vengono recuperate di recente ed esce se il recupero non riesce. Vedi applicazione fail-closed
`pluginTrustMessage`	Messaggio personalizzato aggiunto all'avviso di fiducia del plugin mostrato prima dell'installazione
`sandbox.filesystem.allowManagedReadPathsOnly`	Quando `true`, solo i percorsi `filesystem.allowRead` dalle impostazioni gestite sono rispettati. `denyRead` si unisce comunque da tutte le fonti
`sandbox.network.allowManagedDomainsOnly`	Quando `true`, solo `allowedDomains` e le regole allow `WebFetch(domain:...)` dalle impostazioni gestite sono rispettate. I domini non consentiti vengono bloccati automaticamente senza richiedere all'utente. I domini negati si uniscono comunque da tutte le fonti
`strictKnownMarketplaces`	Controlla quali marketplace di plugin gli utenti possono aggiungere e installare plugin da. Vedi restrizioni marketplace gestite
`wslInheritsWindowsSettings`	Quando `true` nella chiave del registro HKLM di Windows o in `C:\Program Files\ClaudeCode\managed-settings.json`, WSL legge le impostazioni gestite dalla catena di criteri di Windows oltre a `/etc/claude-code`. Vedi File di impostazioni

disableBypassPermissionsMode è tipicamente posizionato nelle impostazioni gestite per applicare la politica organizzativa, ma funziona da qualsiasi ambito. Un utente può impostarlo nelle proprie impostazioni per bloccarsi dalla modalità bypass.

Esaminare i rifiuti della modalità auto

Quando la modalità auto nega una chiamata di strumento, appare una notifica e l'azione negata viene registrata in /permissions nella scheda Recently denied. Premete r su un'azione negata per contrassegnarla per il retry: quando uscite dalla finestra di dialogo, Claude Code invia un messaggio dicendo al modello che può riprovare quella chiamata di strumento e riprende la conversazione.

Per reagire ai rifiuti a livello di programmazione, utilizzate l'hook PermissionDenied.

Configurare il classificatore della modalità auto

La modalità auto utilizza un modello di classificazione per decidere se ogni azione è sicura da eseguire senza richiedere. Per impostazione predefinita, si fida solo della directory di lavoro e, se presente, dei remoti del repository corrente. Azioni come il push verso l'organizzazione di controllo del codice sorgente della vostra azienda o la scrittura in un bucket cloud del team verranno bloccate come potenziale esfiltrazione di dati.

Per regolare ciò che il classificatore consente o blocca, aggiungete istruzioni al vostro file CLAUDE.md. Il classificatore legge CLAUDE.md dalle directory affidabili insieme alla conversazione, quindi un'istruzione come "non forzare mai il push" guida sia Claude che il classificatore contemporaneamente. Iniziate qui per le convenzioni di progetto e le regole comportamentali.

Per le regole che si applicano tra i progetti, come l'infrastruttura affidabile o le regole di negazione a livello organizzativo, utilizzate il blocco di impostazioni autoMode. Il classificatore legge autoMode dalle impostazioni utente, .claude/settings.local.json e impostazioni gestite. Non legge dalle impostazioni di progetto condivise in .claude/settings.json, perché un repository archiviato potrebbe altrimenti iniettare le sue proprie regole allow.

Ambito	File	Utilizzare per
Un sviluppatore	`~/.claude/settings.json`	Infrastruttura affidabile personale
Un progetto, uno sviluppatore	`.claude/settings.local.json`	Bucket o servizi affidabili per progetto, gitignored
Organizzazione	Impostazioni gestite	Infrastruttura affidabile applicata a tutti gli sviluppatori

Le voci da ogni ambito vengono combinate. Uno sviluppatore può estendere environment, allow e soft_deny con voci personali ma non può rimuovere le voci fornite dalle impostazioni gestite. Poiché le regole allow agiscono come eccezioni alle regole di blocco all'interno del classificatore, una voce allow aggiunta da uno sviluppatore può ignorare una voce soft_deny dell'organizzazione: la combinazione è additiva, non un confine di criteri rigido. Se avete bisogno di una regola che gli sviluppatori non possono aggirare, utilizzate permissions.deny nelle impostazioni gestite, che blocca le azioni prima che il classificatore venga consultato.

Definire l'infrastruttura affidabile

Per la maggior parte delle organizzazioni, autoMode.environment è l'unico campo che dovete impostare. Dice al classificatore quali repository, bucket e domini sono affidabili, senza toccare le regole di blocco e allow integrate. Il classificatore utilizza environment per decidere cosa significa "esterno": qualsiasi destinazione non elencata è un potenziale obiettivo di esfiltrazione.

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

Le voci sono prosa, non regex o modelli di strumento. Il classificatore le legge come regole in linguaggio naturale. Scrivitele come descrivereste la vostra infrastruttura a un nuovo ingegnere. Una sezione environment approfondita copre:

Organizzazione: il nome della vostra azienda e per cosa Claude Code viene utilizzato principalmente, come sviluppo software, automazione dell'infrastruttura o ingegneria dei dati
Controllo del codice sorgente: ogni organizzazione GitHub, GitLab o Bitbucket a cui i vostri sviluppatori eseguono il push
Provider cloud e bucket affidabili: nomi di bucket o prefissi che Claude dovrebbe essere in grado di leggere e scrivere
Domini interni affidabili: nomi host per API, dashboard e servizi all'interno della vostra rete, come *.internal.example.com
Servizi interni chiave: CI, registri di artefatti, indici di pacchetti interni, strumenti di incidenti
Contesto aggiuntivo: vincoli di settore regolamentato, infrastruttura multi-tenant o requisiti di conformità che influiscono su ciò che il classificatore dovrebbe trattare come rischioso

Un modello di partenza utile: compilate i campi tra parentesi e rimuovete le righe che non si applicano:

{
  "autoMode": {
    "environment": [
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

Più contesto specifico fornite, meglio il classificatore può distinguere le operazioni interne di routine dai tentativi di esfiltrazione.

Non è necessario compilare tutto in una volta. Un rollout ragionevole: iniziate con i valori predefiniti e aggiungete la vostra organizzazione di controllo del codice sorgente e i servizi interni chiave, che risolvono i falsi positivi più comuni come il push nei vostri repository. Aggiungete i domini affidabili e i bucket cloud successivamente. Compilate il resto man mano che i blocchi si presentano.

Ignorare le regole di blocco e allow

Due campi aggiuntivi vi consentono di sostituire gli elenchi di regole integrate del classificatore: autoMode.soft_deny controlla cosa viene bloccato e autoMode.allow controlla quali eccezioni si applicano. Ognuno è un array di descrizioni in prosa, lette come regole in linguaggio naturale.

All'interno del classificatore, la precedenza è: le regole soft_deny bloccano per prime, quindi le regole allow ignorano come eccezioni, quindi l'intento esplicito dell'utente ignora entrambi. Se il messaggio dell'utente descrive direttamente e specificamente l'azione esatta che Claude sta per intraprendere, il classificatore la consente anche se una regola soft_deny corrisponde. Le richieste generali non contano: chiedere a Claude di "pulire il repository" non autorizza il force-push, ma chiedere a Claude di "force-push questo ramo" sì.

Per allentare: rimuovete le regole da soft_deny quando i valori predefiniti bloccano qualcosa che la vostra pipeline già protegge con revisione PR, CI o ambienti di staging, o aggiungete a allow quando il classificatore contrassegna ripetutamente un modello di routine che le eccezioni predefinite non coprono. Per stringere: aggiungete a soft_deny per i rischi specifici del vostro ambiente che i valori predefiniti mancano, o rimuovete da allow per mantenere un'eccezione predefinita alle regole di blocco. In tutti i casi, eseguite claude auto-mode defaults per ottenere gli elenchi predefiniti completi, quindi copiate e modificate: non iniziate mai da un elenco vuoto.

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow",
      "...copy full default soft_deny list here first, then add your rules..."
    ]
  }
}

Le tre sezioni vengono valutate indipendentemente, quindi impostare solo environment lascia intatti gli elenchi predefiniti allow e soft_deny.

Ispezionare i valori predefiniti e la vostra configurazione effettiva

Poiché impostare allow o soft_deny sostituisce i valori predefiniti, iniziate qualsiasi personalizzazione copiando gli elenchi predefiniti completi. Tre sottocomandi CLI vi aiutano a ispezionare e convalidare:

claude auto-mode defaults  # the built-in environment, allow, and soft_deny rules
claude auto-mode config    # what the classifier actually uses: your settings where set, defaults otherwise
claude auto-mode critique  # get AI feedback on your custom allow and soft_deny rules

Salvate l'output di claude auto-mode defaults in un file, modificate gli elenchi per corrispondere alla vostra politica e incollate il risultato nel vostro file di impostazioni. Dopo il salvataggio, eseguite claude auto-mode config per confermare che le regole effettive sono quelle che vi aspettate. Se avete scritto regole personalizzate, claude auto-mode critique le rivede e contrassegna le voci che sono ambigue, ridondanti o probabilmente causeranno falsi positivi.

Precedenza delle impostazioni

Le regole di autorizzazione seguono la stessa precedenza delle impostazioni di tutte le altre impostazioni di Claude Code:

Impostazioni gestite: non possono essere ignorate da nessun altro livello, inclusi gli argomenti della riga di comando
Argomenti della riga di comando: override temporanei della sessione
Impostazioni di progetto locale (.claude/settings.local.json)
Impostazioni di progetto condivise (.claude/settings.json)
Impostazioni utente (~/.claude/settings.json)

Se uno strumento viene negato a qualsiasi livello, nessun altro livello può consentirlo. Ad esempio, un deny delle impostazioni gestite non può essere ignorato da --allowedTools e --disallowedTools può aggiungere restrizioni oltre a quelle definite dalle impostazioni gestite.

Se un'autorizzazione è consentita nelle impostazioni utente ma negata nelle impostazioni di progetto, l'impostazione di progetto ha la precedenza e l'autorizzazione viene bloccata.

Configurazioni di esempio

Questo repository include configurazioni di impostazioni iniziali per scenari di distribuzione comuni. Utilizzatele come punti di partenza e adattatele alle vostre esigenze.

Vedi anche

Settings: riferimento di configurazione completo inclusa la tabella delle impostazioni di autorizzazione
Configure auto mode: comunicate al classificatore della modalità auto quale infrastruttura la vostra organizzazione ritiene affidabile
Sandboxing: isolamento del filesystem e della rete a livello del sistema operativo per i comandi Bash
Authentication: configurate l'accesso utente a Claude Code
Security: salvaguardie di sicurezza e best practice
Hooks: automatizzate i flussi di lavoro ed estendete la valutazione delle autorizzazioni

permissions.md +473 −0 created

1> ## Documentation Index

2> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt

3> Use this file to discover all available pages before exploring further.

5# Configurare le autorizzazioni

7> Controlla cosa Claude Code può accedere e fare con regole di autorizzazione granulari, modalità e criteri gestiti.

9Claude Code supporta autorizzazioni granulari in modo che Lei possa specificare esattamente cosa l'agente è autorizzato a fare e cosa non può fare. Le impostazioni di autorizzazione possono essere archiviate nel controllo della versione e distribuite a tutti gli sviluppatori della Sua organizzazione, nonché personalizzate dai singoli sviluppatori.

11## Sistema di autorizzazione

13Claude Code utilizza un sistema di autorizzazione a livelli per bilanciare potenza e sicurezza:

16| :---------------- | :-------------------- | :--------------------- | :-------------------------------------------------- |

17| Sola lettura | Letture di file, Grep | No | N/A |

18| Comandi Bash | Esecuzione shell | Sì | Permanentemente per directory di progetto e comando |

19| Modifica di file | Edit/Write di file | Sì | Fino alla fine della sessione |

21## Gestire le autorizzazioni

23Potete visualizzare e gestire le autorizzazioni degli strumenti di Claude Code con `/permissions`. Questa interfaccia utente elenca tutte le regole di autorizzazione e il file settings.json da cui provengono.

25* Le regole **Allow** consentono a Claude Code di utilizzare lo strumento specificato senza approvazione manuale.

26* Le regole **Ask** richiedono una conferma ogni volta che Claude Code tenta di utilizzare lo strumento specificato.

27* Le regole **Deny** impediscono a Claude Code di utilizzare lo strumento specificato.

29Le regole vengono valutate in ordine: **deny -> ask -> allow**. La prima regola corrispondente vince, quindi le regole deny hanno sempre la precedenza.

31## Modalità di autorizzazione

33Claude Code supporta diverse modalità di autorizzazione che controllano come gli strumenti vengono approvati. Vedi [Permission modes](/it/permission-modes) per quando utilizzare ciascuna. Impostate `defaultMode` nei vostri [file di impostazioni](/it/settings#settings-files):

35| Modalità | Descrizione |

36| :------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

37| `default` | Comportamento standard: richiede l'autorizzazione al primo utilizzo di ogni strumento |

38| `acceptEdits` | Accetta automaticamente le modifiche ai file e i comandi comuni del filesystem (`mkdir`, `touch`, `mv`, `cp`, ecc.) per i percorsi nella directory di lavoro o `additionalDirectories` |

39| `plan` | Plan Mode: Claude può analizzare ma non modificare file o eseguire comandi |

40| `auto` | Auto-approva le chiamate di strumento con controlli di sicurezza in background che verificano che le azioni si allineino con la Sua richiesta. Attualmente un'anteprima di ricerca |

41| `dontAsk` | Nega automaticamente gli strumenti a meno che non siano pre-approvati tramite `/permissions` o regole `permissions.allow` |

42| `bypassPermissions` | Salta i prompt di autorizzazione. Le rimozioni che hanno come destinazione la radice del filesystem o la directory home, come `rm -rf /` e `rm -rf ~`, richiedono comunque un prompt come interruttore di protezione contro gli errori del modello |

44<Warning>

45 La modalità `bypassPermissions` salta i prompt di autorizzazione, incluse le scritture in `.git`, `.claude`, `.vscode`, `.idea` e `.husky`. Le rimozioni che hanno come destinazione la radice del filesystem o la directory home, come `rm -rf /` e `rm -rf ~`, richiedono comunque un prompt come interruttore di protezione contro gli errori del modello. Utilizzate questa modalità solo in ambienti isolati come contenitori o macchine virtuali dove Claude Code non può causare danni. Gli amministratori possono impedire questa modalità impostando `permissions.disableBypassPermissionsMode` su `"disable"` nelle [impostazioni gestite](#managed-settings).

46</Warning>

48Per prevenire che la modalità `bypassPermissions` o `auto` venga utilizzata, impostate `permissions.disableBypassPermissionsMode` o `permissions.disableAutoMode` su `"disable"` in qualsiasi [file di impostazioni](/it/settings#settings-files). Questi sono più utili nelle [impostazioni gestite](#managed-settings) dove non possono essere ignorati.

50## Sintassi delle regole di autorizzazione

52Le regole di autorizzazione seguono il formato `Tool` o `Tool(specifier)`.

54### Corrispondere a tutti gli utilizzi di uno strumento

56Per corrispondere a tutti gli utilizzi di uno strumento, utilizzate solo il nome dello strumento senza parentesi:

58| Regola | Effetto |

59| :--------- | :-------------------------------------------- |

60| `Bash` | Corrisponde a tutti i comandi Bash |

61| `WebFetch` | Corrisponde a tutte le richieste di web fetch |

62| `Read` | Corrisponde a tutte le letture di file |

64`Bash(*)` è equivalente a `Bash` e corrisponde a tutti i comandi Bash.

66### Utilizzare gli specificatori per il controllo granulare

68Aggiungete uno specificatore tra parentesi per corrispondere a utilizzi specifici dello strumento:

70| Regola | Effetto |

71| :----------------------------- | :---------------------------------------------------------------- |

72| `Bash(npm run build)` | Corrisponde al comando esatto `npm run build` |

73| `Read(./.env)` | Corrisponde alla lettura del file `.env` nella directory corrente |

74| `WebFetch(domain:example.com)` | Corrisponde alle richieste di fetch a example.com |

76### Modelli con caratteri jolly

78Le regole Bash supportano modelli glob con `*`. I caratteri jolly possono apparire in qualsiasi posizione nel comando. Questa configurazione consente comandi npm e git commit mentre blocca git push:

80```json theme={null}

81{

82 "permissions": {

83 "allow": [

84 "Bash(npm run *)",

85 "Bash(git commit *)",

86 "Bash(git * main)",

87 "Bash(* --version)",

88 "Bash(* --help *)"

89 ],

90 "deny": [

91 "Bash(git push *)"

92 ]

93 }

94}

95```

97Lo spazio prima di `*` è importante: `Bash(ls *)` corrisponde a `ls -la` ma non a `lsof`, mentre `Bash(ls*)` corrisponde a entrambi. Il suffisso `:*` è un modo equivalente per scrivere un carattere jolly finale, quindi `Bash(ls:*)` corrisponde agli stessi comandi di `Bash(ls *)`.

99La finestra di dialogo di autorizzazione scrive la forma separata da spazi quando selezionate "Sì, non chiedere più" per un prefisso di comando. La forma `:*` è riconosciuta solo alla fine di un modello. In un modello come `Bash(git:* push)`, il due punti viene trattato come un carattere letterale e non corrisponderà ai comandi git.

100

101## Regole di autorizzazione specifiche dello strumento

102

103### Bash

104

105Le regole di autorizzazione Bash supportano la corrispondenza con caratteri jolly con `*`. I caratteri jolly possono apparire in qualsiasi posizione nel comando, incluso all'inizio, nel mezzo o alla fine:

106

107* `Bash(npm run build)` corrisponde al comando Bash esatto `npm run build`

108* `Bash(npm run test *)` corrisponde ai comandi Bash che iniziano con `npm run test`

109* `Bash(npm *)` corrisponde a qualsiasi comando che inizia con `npm `

110* `Bash(* install)` corrisponde a qualsiasi comando che termina con ` install`

111* `Bash(git * main)` corrisponde a comandi come `git checkout main` e `git log --oneline main`

112

113Un singolo `*` corrisponde a qualsiasi sequenza di caratteri inclusi gli spazi, quindi un singolo carattere jolly può estendersi su più argomenti. `Bash(git *)` corrisponde a `git log --oneline --all` e `Bash(git * main)` corrisponde sia a `git push origin main` che a `git merge main`.

114

115Quando `*` appare alla fine con uno spazio prima (come `Bash(ls *)`), applica un confine di parola, richiedendo che il prefisso sia seguito da uno spazio o dalla fine della stringa. Ad esempio, `Bash(ls *)` corrisponde a `ls -la` ma non a `lsof`. Al contrario, `Bash(ls*)` senza spazio corrisponde sia a `ls -la` che a `lsof` perché non c'è un vincolo di confine di parola.

116

117#### Comandi composti

118

119<Tip>

120 Claude Code è consapevole degli operatori shell, quindi una regola come `Bash(safe-cmd *)` non gli darà il permesso di eseguire il comando `safe-cmd && other-cmd`. I separatori di comando riconosciuti sono `&&`, `||`, `;`, `|`, `|&`, `&` e newline. Una regola deve corrispondere a ogni sottocomando indipendentemente.

121</Tip>

122

123Quando approvate un comando composto con "Sì, non chiedere più", Claude Code salva una regola separata per ogni sottocomando che richiede approvazione, piuttosto che una singola regola per la stringa completa. Ad esempio, approvando `git status && npm test` salva una regola per `npm test`, quindi le future invocazioni di `npm test` vengono riconosciute indipendentemente da cosa precede `&&`. I sottocomandi come `cd` in una sottodirectory generano la loro propria regola Read per quel percorso. Fino a 5 regole possono essere salvate per un singolo comando composto.

124

125#### Wrapper di processo

126

127Prima di corrispondere alle regole Bash, Claude Code rimuove un insieme fisso di wrapper di processo in modo che una regola come `Bash(npm test *)` corrisponda anche a `timeout 30 npm test`. I wrapper riconosciuti sono `timeout`, `time`, `nice`, `nohup` e `stdbuf`.

128

129Anche `xargs` nudo viene rimosso, quindi `Bash(grep *)` corrisponde a `xargs grep pattern`. La rimozione si applica solo quando `xargs` non ha flag: un'invocazione come `xargs -n1 grep pattern` viene abbinata come comando `xargs`, quindi le regole scritte per il comando interno non la coprono.

130

131Questo elenco di wrapper è integrato e non è configurabile. I runner dell'ambiente di sviluppo come `direnv exec`, `devbox run`, `mise exec`, `npx` e `docker exec` non sono nell'elenco. Poiché questi strumenti eseguono i loro argomenti come comando, una regola come `Bash(devbox run *)` corrisponde a qualsiasi cosa venga dopo `run`, incluso `devbox run rm -rf .`. Per approvare il lavoro all'interno di un runner dell'ambiente, scrivete una regola specifica che includa sia il runner che il comando interno, come `Bash(devbox run npm test)`. Aggiungete una regola per ogni comando interno che desiderate consentire.

132

133I wrapper exec come `watch`, `setsid`, `ionice` e `flock` richiedono sempre un prompt e non possono essere auto-approvati da una regola di prefisso come `Bash(watch *)`. Lo stesso vale per `find` con `-exec` o `-delete`: una regola `Bash(find *)` non copre queste forme. Per approvare un'invocazione specifica, scrivete una regola di corrispondenza esatta per la stringa di comando completa.

134

135#### Comandi di sola lettura

136

137Claude Code riconosce un insieme integrato di comandi Bash come di sola lettura e li esegue senza un prompt di autorizzazione in ogni modalità. Questi includono `ls`, `cat`, `head`, `tail`, `grep`, `find`, `wc`, `diff`, `stat`, `du`, `cd` e forme di sola lettura di `git`. L'insieme non è configurabile; per richiedere un prompt per uno di questi comandi, aggiungete una regola `ask` o `deny` per esso.

138

139I modelli glob non quotati sono consentiti per i comandi il cui ogni flag è di sola lettura, quindi `ls *.ts` e `wc -l src/*.py` vengono eseguiti senza un prompt. I comandi con flag in grado di scrivere o eseguire, come `find`, `sort`, `sed` e `git`, richiedono comunque un prompt quando è presente un glob non quotato perché il glob potrebbe espandersi a un flag come `-delete`.

140

141Un `cd` in un percorso all'interno della vostra directory di lavoro o di una [directory aggiuntiva](#working-directories) è anche di sola lettura. Un comando composto come `cd packages/api && ls` viene eseguito senza un prompt quando ogni parte si qualifica da sola. La combinazione di `cd` con `git` in un comando composto richiede sempre un prompt, indipendentemente dalla directory di destinazione.

142

143<Warning>

144 I modelli di autorizzazione Bash che tentano di vincolare gli argomenti del comando sono fragili. Ad esempio, `Bash(curl http://github.com/ *)` intende limitare curl agli URL di GitHub, ma non corrisponderà a variazioni come:

145

146 * Opzioni prima dell'URL: `curl -X GET http://github.com/...`

147 * Protocollo diverso: `curl https://github.com/...`

148 * Reindirizzamenti: `curl -L http://bit.ly/xyz` (reindirizza a github)

149 * Variabili: `URL=http://github.com && curl $URL`

150 * Spazi extra: `curl http://github.com`

151

152 Per un filtraggio URL più affidabile, considerate:

153

154 * **Limitare gli strumenti di rete Bash**: utilizzate regole deny per bloccare `curl`, `wget` e comandi simili, quindi utilizzate lo strumento WebFetch con l'autorizzazione `WebFetch(domain:github.com)` per i domini consentiti

155 * **Utilizzare hook PreToolUse**: implementate un hook che convalida gli URL nei comandi Bash e blocca i domini non consentiti

156 * Istruire Claude Code sui vostri modelli curl consentiti tramite CLAUDE.md

157

158 Nota che l'utilizzo di WebFetch da solo non impedisce l'accesso alla rete. Se Bash è consentito, Claude può comunque utilizzare `curl`, `wget` o altri strumenti per raggiungere qualsiasi URL.

159</Warning>

160

161### PowerShell

162

163Le regole di autorizzazione PowerShell utilizzano la stessa forma delle regole Bash. I caratteri jolly con `*` corrispondono in qualsiasi posizione, il suffisso `:*` è equivalente a un ` *` finale, e un PowerShell nudo o `PowerShell(*)` corrisponde a ogni comando. Questa configurazione consente comandi `Get-ChildItem` e `git commit` mentre blocca `Remove-Item`:

164

165```json theme={null}

166{

167 "permissions": {

168 "allow": [

169 "PowerShell(Get-ChildItem *)",

170 "PowerShell(git commit *)"

171 ],

172 "deny": [

173 "PowerShell(Remove-Item *)"

174 ]

175 }

176}

177```

178

179Gli alias comuni vengono canonicalizati prima della corrispondenza. Una regola scritta per il nome del cmdlet corrisponde anche ai suoi alias, quindi `PowerShell(Get-ChildItem *)` corrisponde a `gci`, `ls` e `dir` nonché. La corrispondenza non è sensibile alle maiuscole.

180

181Claude Code analizza l'AST di PowerShell e controlla ogni comando in un comando composto indipendentemente. Gli operatori pipeline `|`, i separatori di istruzione `;` e su PowerShell 7+ gli operatori di catena `&&` e `||` dividono un comando composto in sottocomandi. Una regola deve corrispondere a ogni sottocomando affinché il comando composto sia consentito.

182

183### Read e Edit

184

185Le regole `Edit` si applicano a tutti gli strumenti integrati che modificano i file. Claude fa un tentativo migliore per applicare le regole `Read` a tutti gli strumenti integrati che leggono file come Grep e Glob.

186

187<Warning>

188 Le regole deny di Read e Edit si applicano agli strumenti di file integrati di Claude, non ai sottoprocessi Bash. Una regola deny `Read(./.env)` blocca lo strumento Read ma non impedisce `cat .env` in Bash. Per l'applicazione a livello del sistema operativo che blocca tutti i processi dall'accesso a un percorso, [abilitate la sandbox](/it/sandboxing).

189</Warning>

190

191Le regole Read e Edit seguono entrambe la specifica [gitignore](https://git-scm.com/docs/gitignore) con quattro tipi di modello distinti:

192

194| ----------------- | ------------------------------------------------- | -------------------------------- | ------------------------------ |

195| `//path` | Percorso **assoluto** dalla radice del filesystem | `Read(//Users/alice/secrets/**)` | `/Users/alice/secrets/**` |

196| `~/path` | Percorso dalla directory **home** | `Read(~/Documents/*.pdf)` | `/Users/alice/Documents/*.pdf` |

197| `/path` | Percorso **relativo alla radice del progetto** | `Edit(/src/**/*.ts)` | `<project root>/src/**/*.ts` |

198| `path` o `./path` | Percorso **relativo alla directory corrente** | `Read(*.env)` | `<cwd>/*.env` |

199

200<Warning>

201 Un modello come `/Users/alice/file` NON è un percorso assoluto. È relativo alla radice del progetto. Utilizzate `//Users/alice/file` per i percorsi assoluti.

202</Warning>

203

204Su Windows, i percorsi vengono normalizzati in forma POSIX prima della corrispondenza. `C:\Users\alice` diventa `/c/Users/alice`, quindi utilizzate `//c/**/.env` per corrispondere ai file `.env` in qualsiasi punto su quel drive. Per corrispondere su tutti i drive, utilizzate `//**/.env`.

205

206Esempi:

207

208* `Edit(/docs/**)`: modifica in `<project>/docs/` (NON `/docs/` e NON `<project>/.claude/docs/`)

209* `Read(~/.zshrc)`: legge il `.zshrc` della vostra directory home

210* `Edit(//tmp/scratch.txt)`: modifica il percorso assoluto `/tmp/scratch.txt`

211* `Read(src/**)`: legge da `<current-directory>/src/`

212

213<Note>

214 Nei modelli gitignore, `*` corrisponde ai file in una singola directory mentre `**` corrisponde ricorsivamente tra le directory. Per consentire l'accesso a tutti i file, utilizzate solo il nome dello strumento senza parentesi: `Read`, `Edit` o `Write`.

215</Note>

216

217Quando Claude accede a un symlink, le regole di autorizzazione controllano due percorsi: il symlink stesso e il file a cui si risolve. Le regole allow e deny trattano quella coppia diversamente: le regole allow ricadono nel richiedere un prompt, mentre le regole deny bloccano completamente.

218

219* **Regole allow**: si applicano solo quando sia il percorso del symlink che il suo target corrispondono. Un symlink all'interno di una directory consentita che punta al di fuori di essa richiede comunque un prompt.

220* **Regole deny**: si applicano quando il percorso del symlink o il suo target corrisponde. Un symlink che punta a un file negato è esso stesso negato.

221

222Ad esempio, con `Read(./project/**)` consentito e `Read(~/.ssh/**)` negato, un symlink in `./project/key` che punta a `~/.ssh/id_rsa` viene bloccato: il target non supera la regola allow e corrisponde alla regola deny.

223

224### WebFetch

225

226* `WebFetch(domain:example.com)` corrisponde alle richieste di fetch a example.com

227

228### MCP

229

230* `mcp__puppeteer` corrisponde a qualsiasi strumento fornito dal server `puppeteer` (nome configurato in Claude Code)

231* `mcp__puppeteer__*` sintassi con caratteri jolly che corrisponde anche a tutti gli strumenti dal server `puppeteer`

232* `mcp__puppeteer__puppeteer_navigate` corrisponde allo strumento `puppeteer_navigate` fornito dal server `puppeteer`

233

234### Agent (subagents)

235

236Utilizzate le regole `Agent(AgentName)` per controllare quali [subagents](/it/sub-agents) Claude può utilizzare:

237

238* `Agent(Explore)` corrisponde al subagent Explore

239* `Agent(Plan)` corrisponde al subagent Plan

240* `Agent(my-custom-agent)` corrisponde a un subagent personalizzato denominato `my-custom-agent`

241

242Aggiungete queste regole all'array `deny` nelle vostre impostazioni o utilizzate il flag CLI `--disallowedTools` per disabilitare agenti specifici. Per disabilitare l'agente Explore:

243

244```json theme={null}

245{

246 "permissions": {

247 "deny": ["Agent(Explore)"]

248 }

249}

250```

251

252## Estendere le autorizzazioni con hook

253

254Gli [hook di Claude Code](/it/hooks-guide) forniscono un modo per registrare comandi shell personalizzati per eseguire la valutazione delle autorizzazioni in fase di esecuzione. Quando Claude Code effettua una chiamata di strumento, gli hook PreToolUse vengono eseguiti prima del prompt di autorizzazione. L'output dell'hook può negare la chiamata dello strumento, forzare un prompt o saltare il prompt per consentire alla chiamata di procedere.

255

256Le decisioni dell'hook non bypassano le regole di autorizzazione. Le regole deny e ask vengono valutate indipendentemente da ciò che un hook PreToolUse restituisce, quindi una regola deny corrispondente blocca la chiamata e una regola ask corrispondente richiede comunque un prompt anche quando l'hook ha restituito `"allow"` o `"ask"`. Questo preserva la precedenza deny-first descritta in [Gestire le autorizzazioni](#manage-permissions), incluse le regole deny impostate nelle impostazioni gestite.

257

258Un hook di blocco ha anche la precedenza sulle regole allow. Un hook che esce con codice 2 interrompe la chiamata dello strumento prima che le regole di autorizzazione vengono valutate, quindi il blocco si applica anche quando una regola allow consentirebbe altrimenti la chiamata. Per eseguire tutti i comandi Bash senza prompt tranne alcuni che desiderate bloccare, aggiungete `"Bash"` al vostro elenco allow e registrate un hook PreToolUse che rifiuta quei comandi specifici. Vedi [Bloccare le modifiche ai file protetti](/it/hooks-guide#block-edits-to-protected-files) per uno script di hook che potete adattare.

259

260## Directory di lavoro

261

262Per impostazione predefinita, Claude ha accesso ai file nella directory in cui è stato avviato. Potete estendere questo accesso:

263

264* **Durante l'avvio**: utilizzate l'argomento CLI `--add-dir <path>`

265* **Durante la sessione**: utilizzate il comando `/add-dir`

266* **Configurazione persistente**: aggiungete a `additionalDirectories` nei [file di impostazioni](/it/settings#settings-files)

267

268I file nelle directory aggiuntive seguono le stesse regole di autorizzazione della directory di lavoro originale: diventano leggibili senza prompt e le autorizzazioni di modifica dei file seguono la modalità di autorizzazione corrente.

269

270### Le directory aggiuntive concedono l'accesso ai file, non la configurazione

271

272L'aggiunta di una directory estende dove Claude può leggere e modificare i file. Non rende quella directory una radice di configurazione completa: la maggior parte della configurazione `.claude/` non viene scoperta dalle directory aggiuntive, anche se alcuni tipi vengono caricati come eccezioni.

273

274I seguenti tipi di configurazione vengono caricati dalle directory `--add-dir`:

275

276| Configurazione | Caricato da `--add-dir` |

277| :----------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

278| [Skills](/it/skills) in `.claude/skills/` | Sì, con ricaricamento live |

279| Impostazioni plugin in `.claude/settings.json` | Solo `enabledPlugins` e `extraKnownMarketplaces` |

280| File [CLAUDE.md](/it/memory), `.claude/rules/` e `CLAUDE.local.md` | Solo quando `CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1` è impostato. `CLAUDE.local.md` richiede inoltre l'impostazione `local` source, che è abilitata per impostazione predefinita |

281

282Tutto il resto, inclusi subagents, commands, output styles, hooks e altre impostazioni, viene scoperto solo dalla directory di lavoro corrente e dai suoi genitori, dalla vostra directory utente in `~/.claude/` e dalle impostazioni gestite. Per condividere quella configurazione tra progetti, utilizzate uno di questi approcci:

283

284* **Configurazione a livello utente**: posizionate i file in `~/.claude/agents/`, `~/.claude/output-styles/` o `~/.claude/settings.json` per renderli disponibili in ogni progetto

285* **Plugin**: pacchetto e distribuite la configurazione come [plugin](/it/plugins) che i team possono installare

286* **Avviate dalla directory di configurazione**: eseguite Claude Code dalla directory contenente la configurazione `.claude/` che desiderate

287

288## Come le autorizzazioni interagiscono con il sandboxing

289

290Le autorizzazioni e il [sandboxing](/it/sandboxing) sono livelli di sicurezza complementari:

291

292* **Autorizzazioni** controllano quali strumenti Claude Code può utilizzare e quali file o domini può accedere. Si applicano a tutti gli strumenti (Bash, Read, Edit, WebFetch, MCP e altri).

293* **Sandboxing** fornisce l'applicazione a livello del sistema operativo che limita l'accesso al filesystem e alla rete dello strumento Bash. Si applica solo ai comandi Bash e ai loro processi figlio.

294

295Utilizzate entrambi per la difesa in profondità:

296

297* Le regole deny di autorizzazione impediscono a Claude di tentare anche di accedere alle risorse limitate

298* Le restrizioni sandbox impediscono ai comandi Bash di raggiungere risorse al di fuori dei confini definiti, anche se un'iniezione di prompt bypassa il processo decisionale di Claude

299* Le restrizioni del filesystem nella sandbox utilizzano le regole deny di Read e Edit, non una configurazione sandbox separata

300* Le restrizioni di rete combinano le regole di autorizzazione WebFetch con gli elenchi `allowedDomains` e `deniedDomains` della sandbox

301

302Quando il sandboxing è abilitato con `autoAllowBashIfSandboxed: true`, che è l'impostazione predefinita, i comandi Bash in sandbox vengono eseguiti senza richiedere un prompt anche se le vostre autorizzazioni includono `ask: Bash(*)`. Il confine della sandbox sostituisce il prompt per comando. Le regole deny esplicite si applicano ancora, e i comandi `rm` o `rmdir` che hanno come destinazione `/`, la vostra directory home o altri percorsi critici del sistema attivano comunque un prompt. Consultate [modalità sandbox](/it/sandboxing#sandbox-modes) per modificare questo comportamento.

303

304## Impostazioni gestite

305

306Per le organizzazioni che necessitano di un controllo centralizzato sulla configurazione di Claude Code, gli amministratori possono distribuire impostazioni gestite che non possono essere ignorate dalle impostazioni utente o di progetto. Queste impostazioni di criteri seguono lo stesso formato dei file di impostazioni regolari e possono essere fornite tramite criteri MDM/a livello del sistema operativo, file di impostazioni gestite o [impostazioni gestite dal server](/it/server-managed-settings). Vedi [file di impostazioni](/it/settings#settings-files) per i meccanismi di consegna e i percorsi dei file.

307

308### Impostazioni solo gestite

309

310Le seguenti impostazioni sono efficaci solo nelle impostazioni gestite. Posizionarle nei file di impostazioni utente o di progetto non ha alcun effetto.

311

312| Impostazione | Descrizione |

313| :--------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

314| `allowedChannelPlugins` | Elenco di autorizzazione dei plugin di canale che possono inviare messaggi. Sostituisce l'elenco di autorizzazione Anthropic predefinito quando impostato. Richiede `channelsEnabled: true`. Vedi [Limitare quali plugin di canale possono essere eseguiti](/it/channels#restrict-which-channel-plugins-can-run) |

315| `allowManagedHooksOnly` | Quando `true`, solo gli hook gestiti, gli hook SDK e gli hook dai plugin force-enabled nelle impostazioni gestite `enabledPlugins` vengono caricati. Gli hook utente, progetto e tutti gli altri plugin vengono bloccati |

316| `allowManagedMcpServersOnly` | Quando `true`, solo `allowedMcpServers` dalle impostazioni gestite sono rispettati. `deniedMcpServers` si unisce comunque da tutte le fonti. Vedi [Configurazione MCP gestita](/it/mcp#managed-mcp-configuration) |

317| `allowManagedPermissionRulesOnly` | Quando `true`, impedisce alle impostazioni utente e di progetto di definire regole di autorizzazione `allow`, `ask` o `deny`. Si applicano solo le regole nelle impostazioni gestite |

318| `blockedMarketplaces` | Elenco di blocco delle fonti del marketplace. Le fonti bloccate vengono controllate prima del download, quindi non toccano mai il filesystem. Vedi [restrizioni marketplace gestite](/it/plugin-marketplaces#managed-marketplace-restrictions) |

319| `channelsEnabled` | Consenti [channels](/it/channels) per gli utenti Team e Enterprise. Non impostato o `false` blocca la consegna dei messaggi di canale indipendentemente da ciò che gli utenti passano a `--channels` |

320| `forceRemoteSettingsRefresh` | Quando `true`, blocca l'avvio della CLI fino a quando le impostazioni gestite remote non vengono recuperate di recente ed esce se il recupero non riesce. Vedi [applicazione fail-closed](/it/server-managed-settings#enforce-fail-closed-startup) |

321| `pluginTrustMessage` | Messaggio personalizzato aggiunto all'avviso di fiducia del plugin mostrato prima dell'installazione |

322| `sandbox.filesystem.allowManagedReadPathsOnly` | Quando `true`, solo i percorsi `filesystem.allowRead` dalle impostazioni gestite sono rispettati. `denyRead` si unisce comunque da tutte le fonti |

323| `sandbox.network.allowManagedDomainsOnly` | Quando `true`, solo `allowedDomains` e le regole allow `WebFetch(domain:...)` dalle impostazioni gestite sono rispettate. I domini non consentiti vengono bloccati automaticamente senza richiedere all'utente. I domini negati si uniscono comunque da tutte le fonti |

324| `strictKnownMarketplaces` | Controlla quali marketplace di plugin gli utenti possono aggiungere e installare plugin da. Vedi [restrizioni marketplace gestite](/it/plugin-marketplaces#managed-marketplace-restrictions) |

325| `wslInheritsWindowsSettings` | Quando `true` nella chiave del registro HKLM di Windows o in `C:\Program Files\ClaudeCode\managed-settings.json`, WSL legge le impostazioni gestite dalla catena di criteri di Windows oltre a `/etc/claude-code`. Vedi [File di impostazioni](/it/settings#settings-files) |

326

327`disableBypassPermissionsMode` è tipicamente posizionato nelle impostazioni gestite per applicare la politica organizzativa, ma funziona da qualsiasi ambito. Un utente può impostarlo nelle proprie impostazioni per bloccarsi dalla modalità bypass.

328

329<Note>

330 L'accesso a [Remote Control](/it/remote-control) e [sessioni web](/it/claude-code-on-the-web) non è controllato da una chiave di impostazioni gestite. Nei piani Team e Enterprise, un amministratore abilita o disabilita queste funzioni nelle [impostazioni di amministrazione di Claude Code](https://claude.ai/admin-settings/claude-code).

331</Note>

332

333## Esaminare i rifiuti della modalità auto

334

335Quando la [modalità auto](/it/permission-modes#eliminate-prompts-with-auto-mode) nega una chiamata di strumento, appare una notifica e l'azione negata viene registrata in `/permissions` nella scheda Recently denied. Premete `r` su un'azione negata per contrassegnarla per il retry: quando uscite dalla finestra di dialogo, Claude Code invia un messaggio dicendo al modello che può riprovare quella chiamata di strumento e riprende la conversazione.

336

337Per reagire ai rifiuti a livello di programmazione, utilizzate l'[hook `PermissionDenied`](/it/hooks#permissiondenied).

338

339## Configurare il classificatore della modalità auto

340

341La [modalità auto](/it/permission-modes#eliminate-prompts-with-auto-mode) utilizza un modello di classificazione per decidere se ogni azione è sicura da eseguire senza richiedere. Per impostazione predefinita, si fida solo della directory di lavoro e, se presente, dei remoti del repository corrente. Azioni come il push verso l'organizzazione di controllo del codice sorgente della vostra azienda o la scrittura in un bucket cloud del team verranno bloccate come potenziale esfiltrazione di dati.

342

343Per regolare ciò che il classificatore consente o blocca, aggiungete istruzioni al vostro file [CLAUDE.md](/it/memory). Il classificatore legge CLAUDE.md dalle directory affidabili insieme alla conversazione, quindi un'istruzione come "non forzare mai il push" guida sia Claude che il classificatore contemporaneamente. Iniziate qui per le convenzioni di progetto e le regole comportamentali.

344

345Per le regole che si applicano tra i progetti, come l'infrastruttura affidabile o le regole di negazione a livello organizzativo, utilizzate il blocco di impostazioni `autoMode`. Il classificatore legge `autoMode` dalle impostazioni utente, `.claude/settings.local.json` e impostazioni gestite. Non legge dalle impostazioni di progetto condivise in `.claude/settings.json`, perché un repository archiviato potrebbe altrimenti iniettare le sue proprie regole allow.

346

347| Ambito | File | Utilizzare per |

348| :---------------------------- | :---------------------------- | :----------------------------------------------------------- |

349| Un sviluppatore | `~/.claude/settings.json` | Infrastruttura affidabile personale |

350| Un progetto, uno sviluppatore | `.claude/settings.local.json` | Bucket o servizi affidabili per progetto, gitignored |

351| Organizzazione | Impostazioni gestite | Infrastruttura affidabile applicata a tutti gli sviluppatori |

352

353Le voci da ogni ambito vengono combinate. Uno sviluppatore può estendere `environment`, `allow` e `soft_deny` con voci personali ma non può rimuovere le voci fornite dalle impostazioni gestite. Poiché le regole allow agiscono come eccezioni alle regole di blocco all'interno del classificatore, una voce `allow` aggiunta da uno sviluppatore può ignorare una voce `soft_deny` dell'organizzazione: la combinazione è additiva, non un confine di criteri rigido. Se avete bisogno di una regola che gli sviluppatori non possono aggirare, utilizzate `permissions.deny` nelle impostazioni gestite, che blocca le azioni prima che il classificatore venga consultato.

354

355### Definire l'infrastruttura affidabile

356

357Per la maggior parte delle organizzazioni, `autoMode.environment` è l'unico campo che dovete impostare. Dice al classificatore quali repository, bucket e domini sono affidabili, senza toccare le regole di blocco e allow integrate. Il classificatore utilizza `environment` per decidere cosa significa "esterno": qualsiasi destinazione non elencata è un potenziale obiettivo di esfiltrazione.

358

359```json theme={null}

360{

361 "autoMode": {

362 "environment": [

363 "Source control: github.example.com/acme-corp and all repos under it",

364 "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",

365 "Trusted internal domains: *.corp.example.com, api.internal.example.com",

366 "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"

367 ]

368 }

369}

370```

371

372Le voci sono prosa, non regex o modelli di strumento. Il classificatore le legge come regole in linguaggio naturale. Scrivitele come descrivereste la vostra infrastruttura a un nuovo ingegnere. Una sezione environment approfondita copre:

373

374* **Organizzazione**: il nome della vostra azienda e per cosa Claude Code viene utilizzato principalmente, come sviluppo software, automazione dell'infrastruttura o ingegneria dei dati

375* **Controllo del codice sorgente**: ogni organizzazione GitHub, GitLab o Bitbucket a cui i vostri sviluppatori eseguono il push

376* **Provider cloud e bucket affidabili**: nomi di bucket o prefissi che Claude dovrebbe essere in grado di leggere e scrivere

377* **Domini interni affidabili**: nomi host per API, dashboard e servizi all'interno della vostra rete, come `*.internal.example.com`

378* **Servizi interni chiave**: CI, registri di artefatti, indici di pacchetti interni, strumenti di incidenti

379* **Contesto aggiuntivo**: vincoli di settore regolamentato, infrastruttura multi-tenant o requisiti di conformità che influiscono su ciò che il classificatore dovrebbe trattare come rischioso

380

381Un modello di partenza utile: compilate i campi tra parentesi e rimuovete le righe che non si applicano:

382

383```json theme={null}

384{

385 "autoMode": {

386 "environment": [

387 "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",

388 "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",

389 "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",

390 "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",

391 "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",

392 "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",

393 "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"

394 ]

395 }

396}

397```

398

399Più contesto specifico fornite, meglio il classificatore può distinguere le operazioni interne di routine dai tentativi di esfiltrazione.

400

401Non è necessario compilare tutto in una volta. Un rollout ragionevole: iniziate con i valori predefiniti e aggiungete la vostra organizzazione di controllo del codice sorgente e i servizi interni chiave, che risolvono i falsi positivi più comuni come il push nei vostri repository. Aggiungete i domini affidabili e i bucket cloud successivamente. Compilate il resto man mano che i blocchi si presentano.

402

403### Ignorare le regole di blocco e allow

404

405Due campi aggiuntivi vi consentono di sostituire gli elenchi di regole integrate del classificatore: `autoMode.soft_deny` controlla cosa viene bloccato e `autoMode.allow` controlla quali eccezioni si applicano. Ognuno è un array di descrizioni in prosa, lette come regole in linguaggio naturale.

406

407All'interno del classificatore, la precedenza è: le regole `soft_deny` bloccano per prime, quindi le regole `allow` ignorano come eccezioni, quindi l'intento esplicito dell'utente ignora entrambi. Se il messaggio dell'utente descrive direttamente e specificamente l'azione esatta che Claude sta per intraprendere, il classificatore la consente anche se una regola `soft_deny` corrisponde. Le richieste generali non contano: chiedere a Claude di "pulire il repository" non autorizza il force-push, ma chiedere a Claude di "force-push questo ramo" sì.

408

409Per allentare: rimuovete le regole da `soft_deny` quando i valori predefiniti bloccano qualcosa che la vostra pipeline già protegge con revisione PR, CI o ambienti di staging, o aggiungete a `allow` quando il classificatore contrassegna ripetutamente un modello di routine che le eccezioni predefinite non coprono. Per stringere: aggiungete a `soft_deny` per i rischi specifici del vostro ambiente che i valori predefiniti mancano, o rimuovete da `allow` per mantenere un'eccezione predefinita alle regole di blocco. In tutti i casi, eseguite `claude auto-mode defaults` per ottenere gli elenchi predefiniti completi, quindi copiate e modificate: non iniziate mai da un elenco vuoto.

410

411```json theme={null}

412{

413 "autoMode": {

414 "environment": [

415 "Source control: github.example.com/acme-corp and all repos under it"

416 ],

417 "allow": [

418 "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",

419 "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"

420 ],

421 "soft_deny": [

422 "Never run database migrations outside the migrations CLI, even against dev databases",

423 "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow",

424 "...copy full default soft_deny list here first, then add your rules..."

425 ]

426 }

427}

428```

429

430<Danger>

431 Impostare `allow` o `soft_deny` sostituisce l'intero elenco predefinito per quella sezione. Se impostate `soft_deny` con una singola voce, ogni regola di blocco integrata viene scartata: force push, esfiltrazione di dati, `curl | bash`, deploy di produzione e tutte le altre regole di blocco predefinite diventano consentite. Per personalizzare in modo sicuro, eseguite `claude auto-mode defaults` per stampare le regole integrate, copiatele nel vostro file di impostazioni, quindi rivedete ogni regola rispetto alla vostra pipeline e tolleranza al rischio. Rimuovete solo le regole per i rischi che la vostra infrastruttura già mitiga.

432</Danger>

433

434Le tre sezioni vengono valutate indipendentemente, quindi impostare solo `environment` lascia intatti gli elenchi predefiniti `allow` e `soft_deny`.

435

436### Ispezionare i valori predefiniti e la vostra configurazione effettiva

437

438Poiché impostare `allow` o `soft_deny` sostituisce i valori predefiniti, iniziate qualsiasi personalizzazione copiando gli elenchi predefiniti completi. Tre sottocomandi CLI vi aiutano a ispezionare e convalidare:

439

440```bash theme={null}

441claude auto-mode defaults # the built-in environment, allow, and soft_deny rules

442claude auto-mode config # what the classifier actually uses: your settings where set, defaults otherwise

443claude auto-mode critique # get AI feedback on your custom allow and soft_deny rules

444```

445

446Salvate l'output di `claude auto-mode defaults` in un file, modificate gli elenchi per corrispondere alla vostra politica e incollate il risultato nel vostro file di impostazioni. Dopo il salvataggio, eseguite `claude auto-mode config` per confermare che le regole effettive sono quelle che vi aspettate. Se avete scritto regole personalizzate, `claude auto-mode critique` le rivede e contrassegna le voci che sono ambigue, ridondanti o probabilmente causeranno falsi positivi.

447

448## Precedenza delle impostazioni

449

450Le regole di autorizzazione seguono la stessa [precedenza delle impostazioni](/it/settings#settings-precedence) di tutte le altre impostazioni di Claude Code:

451

4521. **Impostazioni gestite**: non possono essere ignorate da nessun altro livello, inclusi gli argomenti della riga di comando

4532. **Argomenti della riga di comando**: override temporanei della sessione

4543. **Impostazioni di progetto locale** (`.claude/settings.local.json`)

4554. **Impostazioni di progetto condivise** (`.claude/settings.json`)

4565. **Impostazioni utente** (`~/.claude/settings.json`)

457

458Se uno strumento viene negato a qualsiasi livello, nessun altro livello può consentirlo. Ad esempio, un deny delle impostazioni gestite non può essere ignorato da `--allowedTools` e `--disallowedTools` può aggiungere restrizioni oltre a quelle definite dalle impostazioni gestite.

459

460Se un'autorizzazione è consentita nelle impostazioni utente ma negata nelle impostazioni di progetto, l'impostazione di progetto ha la precedenza e l'autorizzazione viene bloccata.

461

462## Configurazioni di esempio

463

464Questo [repository](https://github.com/anthropics/claude-code/tree/main/examples/settings) include configurazioni di impostazioni iniziali per scenari di distribuzione comuni. Utilizzatele come punti di partenza e adattatele alle vostre esigenze.

465

466## Vedi anche

467

468* [Settings](/it/settings): riferimento di configurazione completo inclusa la tabella delle impostazioni di autorizzazione

469* [Configure auto mode](/it/auto-mode-config): comunicate al classificatore della modalità auto quale infrastruttura la vostra organizzazione ritiene affidabile

470* [Sandboxing](/it/sandboxing): isolamento del filesystem e della rete a livello del sistema operativo per i comandi Bash

471* [Authentication](/it/authentication): configurate l'accesso utente a Claude Code

472* [Security](/it/security): salvaguardie di sicurezza e best practice

473* [Hooks](/it/hooks-guide): automatizzate i flussi di lavoro ed estendete la valutazione delle autorizzazioni

permissions.md 2026-05-02 18:14 UTC to 2026-05-04 22:58 UTC

Configurare le autorizzazioni

Sistema di autorizzazione

Gestire le autorizzazioni

Modalità di autorizzazione

Sintassi delle regole di autorizzazione

Corrispondere a tutti gli utilizzi di uno strumento

Utilizzare gli specificatori per il controllo granulare

Modelli con caratteri jolly

Regole di autorizzazione specifiche dello strumento

Bash

Comandi composti

Wrapper di processo

Comandi di sola lettura

PowerShell

Read e Edit

WebFetch

MCP

Agent (subagents)

Estendere le autorizzazioni con hook

Directory di lavoro

Le directory aggiuntive concedono l'accesso ai file, non la configurazione

Come le autorizzazioni interagiscono con il sandboxing

Impostazioni gestite

Impostazioni solo gestite

Esaminare i rifiuti della modalità auto

Configurare il classificatore della modalità auto

Definire l'infrastruttura affidabile

Ignorare le regole di blocco e allow

Ispezionare i valori predefiniti e la vostra configurazione effettiva

Precedenza delle impostazioni

Configurazioni di esempio

Vedi anche