Claude Code bypass permissions: rischi e alternative

Claude Code bypass permissions: quali controlli disattiva?

--dangerously-skip-permissions e --permission-mode bypassPermissions attivano la stessa modalità. Claude può modificare file, eseguire comandi della shell e chiamare altri strumenti senza fermarsi per le consuete approvazioni. La modalità consente anche di scrivere nei percorsi protetti. Al primo avvio interattivo compare un avviso sulla responsabilità dell'utente; se non lo accetti, Claude Code si chiude. Documentazione Anthropic sul bypass dei permessi

Immagina i permessi come uno sportello che autorizza il lavoro e l'isolamento come le pareti del laboratorio. Togliere lo sportello non costruisce le pareti. Il vantaggio pratico è una sessione senza interruzioni; il prezzo da pagare è perdere l'occasione di intercettare un'azione sbagliata prima che venga eseguita.

Il flusso di lavoro cambia: invece di approvare le singole operazioni, definisci prima l'ambiente e controlli i risultati dopo. Questo non rende corretto il codice e non neutralizza le istruzioni ostili.

Quali controlli restano attivi?

La parola «skip» non significa che sparisca ogni controllo. Le distinzioni seguenti spiegano perché un'esecuzione che dovrebbe procedere senza supervisione può fermarsi o rifiutare un'azione:

Per l'ultima riga, l'impostazione esatta è permissions.blockReadsOutsideWorkingDirectories: true. I comandi Bash riconosciuti come comandi di lettura possono ancora richiedere una conferma fuori dalle directory consentite; i blocchi imposti dalla sandbox si comportano diversamente. In un'esecuzione bypass non interattiva con -p, le chiamate che richiederebbero ancora una conferma vengono invece negate. Azioni che nessuna modalità approva automaticamente, impostazione per le letture fuori directory

Anche gli hook PreToolUse che bloccano le chiamate continuano a intervenire nell'approvazione degli strumenti. Esiste un'eccezione specifica per EndConversation: le regole deny e ask non lo limitano finché rimane disponibile un altro strumento. Le mod installate possono prevalere su alcune decisioni di autorizzazione non gestite centralmente, quindi i controlli obbligatori di un team vanno inseriti nei criteri gestiti. Gli amministratori possono vietare il bypass con "permissions": {"disableBypassPermissionsMode": "disable"}. Anche una sessione avviata con --restricted rifiuta questa modalità. Precedenza di hook e regole, impostazione per disabilitare il bypass

In modalità bypass si può scrivere nei percorsi protetti

Non dare per scontato che per modificare .git o .claude serva ancora una conferma. La modalità bypass consente le scritture nei percorsi protetti. È un meccanismo diverso dai controlli sulla cancellazione delle directory critiche descritti sopra.

L'elenco dei percorsi protetti di Anthropic comprende:

All'interno di .claude esistono eccezioni circoscritte, tra cui i worktree di Claude, i file del piano corrente, lo spazio temporaneo delle sessioni in background e alcuni file Markdown della memoria. Nelle normali sessioni Manual e acceptEdits, le scritture protette richiedono una conferma; la modalità auto le sottopone al proprio classificatore. Una regola allow in un file delle impostazioni non può autorizzarle in anticipo. Percorsi protetti ed eccezioni

Quattro alternative più sicure per ridurre le interruzioni

Scegli il controllo adatto all'interruzione che vuoi eliminare. Alla maggior parte degli sviluppatori serve prima di tutto una politica di approvazione più precisa, prima ancora del bypass.

Usa la modalità auto per il normale lavoro di sviluppo

Avvia una sessione con claude --permission-mode auto. Un classificatore, cioè un modello separato che esamina le azioni proposte, prende le decisioni di approvazione di routine. Per renderla la modalità predefinita del terminale, integra "permissions": {"defaultMode": "auto"} in ~/.claude/settings.json.

Inserire quel valore in .claude/settings.json o .claude/settings.local.json non la attiva. La modalità auto dipende anche dai modelli supportati e dalle impostazioni dell'organizzazione; le regole ask esplicite continuano a richiedere conferma. Riduce le interruzioni, senza garantire la sicurezza. Impostazione della modalità predefinita, requisiti della modalità auto

La nostra guida alla modalità auto di Claude Code spiega quando questo modello di revisione si adatta al tuo flusso di lavoro.

Autorizza le operazioni abituali e vieta azioni specifiche

Usa permissions.allow per i comandi che hai verificato e permissions.deny per le operazioni da bloccare. Claude Code valuta prima deny, poi ask e infine allow. Un'autorizzazione ampia non può annullare un divieto che corrisponde alla stessa operazione. Regole di autorizzazione

Per un repository attendibile, l'esempio seguente combina autorizzazioni mirate e un hook di blocco. Integralo in .claude/settings.json, mantenendo le chiavi già presenti. Le sessioni del terminale partono volutamente in modalità Manual, così sono le autorizzazioni elencate a regolare il lavoro. Prima di approvarli, controlla che cosa eseguono davvero gli script di test e lint del progetto.

{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)", "Read(./.env.*)"]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "if": "Bash(rm *)",
        "command": "echo 'Use the approved cleanup task instead.' >&2; exit 2"
      }]
    }]
  }
}

Per impostazioni personali che prevalgano su quelle del progetto, usa .claude/settings.local.json; se crei il file manualmente, aggiungilo a .gitignore. Apri /permissions per vedere le regole attive e i file da cui provengono. Ambito delle impostazioni

Questi pattern non isolano né il filesystem né la rete. Forme alternative dello stesso comando possono sfuggire a un pattern Bash, e gli script possono leggere file indirettamente nonostante le regole deny applicate agli strumenti di accesso ai file. Tieni i segreti fuori dall'ambiente e usa i vincoli della sandbox quando un accesso deve essere impossibile. Limiti delle regole Bash, limiti delle regole sui file

Parti dalla modalità plan prima di una modifica estesa

Avvia claude --permission-mode plan, oppure imposta "permissions": {"defaultMode": "plan"} nelle impostazioni del progetto. Claude esplora il codice e propone il lavoro prima che vengano approvate modifiche ai sorgenti. L'impostazione di primo livello "useAutoModeDuringPlan": false disattiva l'approvazione dei comandi di pianificazione da parte del classificatore: i comandi che non rientrano nell'insieme predefinito di sola lettura richiedono quindi la tua approvazione. Configurazione della modalità plan

Avvia una nuova sessione plan senza flag che rendano disponibile il bypass. In una sessione interattiva del terminale in cui il bypass è disponibile, la modalità plan non applica i consueti blocchi su modifiche e comandi. Vale anche quando la disponibilità è stata abilitata con --allow-dangerously-skip-permissions, che permette di selezionare il bypass in seguito senza attivarlo subito. Modalità plan e disponibilità del bypass

Usa gli hook per bloccare comandi specifici

Il gestore hooks.PreToolUse dell'esempio usa matcher: "Bash", type: "command" e if: "Bash(rm *)". Quando la condizione corrisponde, il comando della shell stampa una spiegazione e termina con codice 2, bloccando la chiamata allo strumento. Non serve uno script separato. Il comando della shell è un nostro piccolo esempio basato sui campi degli hook e sul codice di uscita bloccante documentati da Anthropic. Configurazione degli hook, codici di uscita che bloccano l'esecuzione

Questo blocca le chiamate rm corrispondenti, non tutti i modi possibili di cancellare un file. Un team potrebbe sostituirlo con un validatore verificato per i propri comandi di deployment o pulizia. Mantieni i controlli abbastanza circoscritti da poterli capire e testare. La nostra pagina sugli hook di Claude Code ne illustra la configurazione e il debug.

In quali ambienti Anthropic consente il bypass?

La tabella delle configurazioni comuni di Anthropic richiede un container, una VM o un runtime sandbox, con un utente non root su Linux e macOS. La sezione sul bypass descrive ambienti isolati che non possono danneggiare l'host e cita in particolare quelli senza accesso a Internet. La guida al devcontainer presenta invece una configurazione connessa, con accesso in uscita limitato ai servizi necessari a Claude. Considera l'accesso alla rete senza restrizioni come un'esposizione distinta. Isolamento richiesto, restrizioni di rete del devcontainer

Su Linux e macOS, l'avvio del bypass come root o tramite sudo viene normalmente rifiutato. La documentazione segnala un'eccezione automatica all'interno di una sandbox riconosciuta; la procedura documentata per il devcontainer usa un account non root. Non risolvere un errore legato a root indebolendo questo limite.

Configurare Claude Code con Docker: il devcontainer di riferimento

Usa un checkout usa e getta di un repository attendibile. Dopo aver installato Docker, VS Code e l'estensione Dev Containers, parti dal progetto di riferimento di Anthropic:

git clone https://github.com/anthropics/claude-code.git claude-code-isolated
code claude-code-isolated

1. In VS Code, esegui Dev Containers: Reopen in Container. Il progetto di riferimento combina la CLI, volumi persistenti e un firewall per il traffico in uscita. Verifica che remoteUser indichi un account non root.
2. Nel terminale del container, esegui id -u e verifica che il risultato non sia 0. Esegui claude per accedere, poi chiudi quella sessione.
3. Nello stesso terminale del container, esegui claude -p "Inspect this repository and summarize its structure. Do not change files." --dangerously-skip-permissions.
4. Per il tuo progetto, copia la directory .devcontainer/ di riferimento in un checkout usa e getta e adatta il Dockerfile alla toolchain del progetto. Controlla il diff dell'area di lavoro dopo ogni attività.

La procedura segue il flusso di lavoro del container di riferimento di Anthropic. Il riferimento è un esempio funzionante, non un'immagine base mantenuta. Conserva le restrizioni sul traffico in uscita oppure applica controlli di rete equivalenti.

L'area di lavoro montata resta scrivibile dall'interno del container e le modifiche arrivano anche sull'host. Evita di montare ~/.ssh, file con credenziali cloud o directory estranee al progetto. Un progetto malevolo può comunque sottrarre tutto ciò che è accessibile all'interno, comprese le credenziali di Claude. Usa repository attendibili e monitora il lavoro. Limiti del devcontainer

Le sessioni cloud ignorano il bypass come modalità predefinita

Le sessioni cloud ignorano senza avvisi le impostazioni defaultMode: "bypassPermissions" e defaultMode: "dontAsk" presenti nei file di configurazione. Partono nella modalità mostrata nel menu a discesa dell'ambiente cloud. Un'impostazione JSON salvata nel repository non può imporre il bypass a una sessione cloud. Comportamento delle modalità nel cloud

Il file locale ~/.claude/settings.json non viene trasferito nelle sessioni cloud ospitate da Anthropic. Anche le impostazioni del repository hanno dei limiti: le sessioni che coinvolgono più repository non caricano le regole di autorizzazione e gli hook di ciascuno. Controlla i criteri effettivi dell'ambiente cloud, senza dare per scontato che siano quelli del tuo terminale. Impostazioni nelle sessioni cloud

Scegli la modalità in base al lavoro

Di solito, il miglioramento più utile consiste nell'eliminare le approvazioni ripetitive da un flusso di lavoro già in uso. Queste sono le scelte pratiche, nell'ordine in cui le valuterei:

Per il caso della CI, claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" è il punto di partenza documentato da Anthropic. Nega le operazioni che altrimenti richiederebbero una conferma. Configurazioni comuni

Qualunque modalità tu scelga, affiancale le nostre buone pratiche per Claude Code. I permessi regolano l'esecuzione; la verifica stabilisce se il risultato merita di essere conservato.

Due strumenti utili che un team potrebbe sviluppare

L'opportunità più solida è un verificatore della configurazione dei permessi. DataForSEO stima 720 ricerche al mese negli Stati Uniti per «claude code permissions». Il dato segnala una difficoltà nel trovare le informazioni, non un'intenzione d'acquisto dimostrata. Un team che gestisce la piattaforma di sviluppo potrebbe creare un piccolo verificatore che spieghi l'ambito delle impostazioni, segnali i valori di defaultMode ignorati e mostri in anteprima l'effetto delle regole troppo ampie sui comandi, prima di introdurre lo strumento ai colleghi. Il primo risultato utile sarebbe un report con le modifiche suggerite. La difficoltà è mantenerlo aggiornato mentre cambia il comportamento della configurazione di Claude Code.

Un launcher per esecuzioni in ambienti usa e getta potrebbe servire ai team con attività ripetute senza supervisione. La stessa analisi della domanda stima 260 ricerche al mese negli Stati Uniti per «claude code docker». Un MVP potrebbe verificare un modello di container già esaminato, i mount consentiti, l'esecuzione senza root e i criteri sul traffico in uscita, per poi raccogliere diff e log da consegnare al manutentore. Il valore starebbe nella coerenza della configurazione. Il limite è che un launcher non può rendere sicuro il codice di un repository non attendibile né garantire l'isolamento per il solo fatto che ci sia Docker.

Entrambe sono opportunità per strumenti interni da validare con utenti reali. Nessuna delle due richiede di rendere il bypass la modalità predefinita sui computer degli sviluppatori.

Da mettere in pratica lunedì: scegli un flusso di lavoro ripetitivo, esamina i comandi che esegue davvero e configura la politica di approvazione minima che gli consenta di arrivare in fondo. Passa a un container usa e getta solo quando l'attività richiede un'esecuzione senza supervisione che vada oltre quella politica.

Se al tuo team serve qualcuno che costruisca e mantenga questo flusso di lavoro, possiamo aiutarti con i nostri sistemi AI in produzione.