Claude Code --dangerously-skip-permissions: spariscono i prompt, non le regole deny né gli hook

Cosa fa davvero claude --dangerously-skip-permissions?

Avvia Claude Code in modalità bypassPermissions. La reference della CLI di Anthropic definisce il flag «equivalente a --permission-mode bypassPermissions», e la pagina sulle modalità di permesso spiega che cosa comporta: la modalità «disattiva i prompt di permesso e i controlli di sicurezza, così le chiamate ai tool vengono eseguite subito, comprese le scritture nei percorsi protetti». Modifiche ai file, comandi di shell, richieste web e tool MCP girano con il tuo utente, senza chiedere niente a nessuno.

I «percorsi protetti» sono il dettaglio che quasi tutte le guide saltano. Parliamo di .git, .vscode, .claude, .mcp.json e dei profili di shell come .zshrc: in tutte le altre modalità una scrittura lì dentro passa da un prompt, da un classificatore, oppure viene negata. In bypass, la tabella della documentazione dice «Consentita». Sono file che più tardi un altro programma eseguirà, ed è questo il meccanismo dietro la maggior parte delle evasioni dalla sandbox rese pubbliche nel 2026.

Ecco che cosa sparisce e che cosa resta in piedi:

In un'esecuzione con -p non c'è nessuno a rispondere, quindi le chiamate che chiederebbero ancora conferma vengono negate.

L'avvertenza di Anthropic, poi, sta in una riga: «bypassPermissions non offre alcuna protezione contro la prompt injection o le azioni indesiderate».

Quali sono le permission mode di Claude Code, e il bypass è attivo di default?

Claude Code ha sei modalità di permesso, e no: bypassPermissions non è mai quella predefinita di fabbrica. Con i piani Pro, Max e Team una nuova sessione nel terminale parte in auto (dalla v2.1.228). Con un piano Enterprise, una chiave API della Console, Bedrock, Foundry, claude -p e l'Agent SDK parte invece in default, che nell'interfaccia si chiama Manual.

A decidere la modalità di partenza è, nell'ordine, il flag, poi permissions.defaultMode in un file di settings, infine il default di fabbrica. Se cloni spesso repository altrui, qui c'è un dettaglio da conoscere. La reference dei settings precisa che auto e bypassPermissions «non hanno effetto dai settings di progetto o locali», e subito dopo aggiunge: «Prima della v2.1.257, bypassPermissions aveva effetto da qualsiasi file». In altre parole, sulle versioni più vecchie un .claude/settings.json committato nel repository poteva scegliere il bypass al posto tuo, dietro una finestra di avviso mostrata una volta sola.

Si può passare a bypass permissions mid session, con Claude Code già in esecuzione?

Solo se la sessione è stata lanciata con il bypass disponibile. La documentazione non lascia margini: «Non puoi entrare in bypassPermissions da una sessione che hai avviato senza averla abilitata». Se vuoi tenerti aperta la porta, lancia Claude Code con --allow-dangerously-skip-permissions, che aggiunge la modalità al ciclo di Shift+Tab, subito dopo plan. Nemmeno un hook può concederla.

Quel flag ha però un effetto collaterale. Con il bypass disponibile in un terminale interattivo, i blocchi del plan mode non vengono più applicati: «Claude riceve ancora l'istruzione di pianificare senza modificare nulla, ma una modifica a un file o un comando di shell che tenta durante la pianificazione viene eseguito senza prompt». Il plan mode diventa così un'istruzione data al modello e smette di essere un blocco imposto dal client. Fanno eccezione le esecuzioni con -p, l'Agent SDK e il pannello di chat di VS Code.

--dangerously-skip-permissions funziona nell'estensione VS Code?

Sì, ma dietro un interruttore spento di default. L'estensione mostra Bypass permissions nel suo indicatore di modalità solo dopo che hai attivato l'opzione Allow dangerously skip permissions (allowDangerouslySkipPermissions, valore predefinito false), che la documentazione accompagna con una raccomandazione: «Usala solo in sandbox senza accesso a internet». Senza quell'opzione, un default impostato su bypassPermissions fa partire la conversazione in Manual, e in nessun caso un repository può scegliere la modalità di partenza.

Nell'estensione, la sandbox va messa alla prova. La issue #32814, aperta il 10 marzo 2026, segnalava che l'estensione lanciava il binario senza --sandbox, per cui sandbox.enabled: true non applicava alcun profilo Seatbelt. È stata chiusa in automatico come duplicato quattro giorni dopo, e noi non abbiamo ritestato le build attuali. Il test è alla portata di chiunque: chiedi all'agente di scrivere fuori dal workspace e guarda che cosa succede.

Perché --dangerously-skip-permissions non parte come root o con sudo?

Perché su Linux e macOS Claude Code rifiuta quella combinazione. L'errore che compare è --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons, e il motivo lo dà la pagina sul sandboxing: «l'accesso root unito all'assenza di prompt di permesso può modificare qualsiasi file o servizio del sistema». Il controllo viene saltato «automaticamente dentro una sandbox riconosciuta».

Ci si inciampa soprattutto con Docker, dove i processi girano come root di default. La correzione documentata: «verifica che remoteUser sia impostato su un account non root».

La sandbox ti protegge ancora quando salti i permessi?

In parte. La modalità di permesso decide se una chiamata a un tool viene eseguita; la sandbox integrata limita ciò che un comando Bash può raggiungere una volta partito. Sono due meccanismi indipendenti, quindi anche in bypass i comandi di shell in sandbox restano confinati. La sandbox, però, copre soltanto la shell. Lo dice la pagina di confronto di Anthropic: «I tool integrati per i file, i server MCP e gli hook continuano a girare direttamente sul tuo host».

Facciamo un caso concreto, sandbox accesa e permessi saltati. Un comando di shell che aggiunge una riga a ~/.zshrc viene fermato dal sistema operativo. Il tool Edit che scrive nello stesso file, no: «Read, Edit e Write usano direttamente il sistema dei permessi invece di passare dalla sandbox», e quel sistema lo hai appena spento.

C'è poi una via di fuga prevista dal progetto stesso. Un comando che fallisce nella sandbox può essere ritentato con dangerouslyDisableSandbox, e il nuovo tentativo «passa dal normale flusso dei permessi», che in bypass non ha più alcun prompt da mostrare. Per chiuderla, imposta sandbox.allowUnsandboxedCommands su false.

Da qui la regola della documentazione: le sessioni in bypass vanno eseguite «dentro un container, una VM o il sandbox runtime», dove anche i tool per i file, i server MCP e gli hook stanno dentro il confine. Codex traccia la linea altrove, con un unico flag che toglie insieme approvazioni e sandbox: lo raccontiamo nella nostra guida ai flag di Codex.

La strada più corta è la Dev Container Feature di Anthropic, da dichiarare in .devcontainer/devcontainer.json, senza montare nessun segreto dell'host:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

npm install -g @devcontainers/cli
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . \
  claude -p "run the test suite and fix what fails" --dangerously-skip-permissions

Fai il login una volta dentro il container, oppure passa una ANTHROPIC_API_KEY con ambito limitato. Quello che ottieni è un utente non root e un confine di processo, non una policy sul traffico in uscita: per quella, il container di riferimento nel repository anthropics/claude-code aggiunge uno script di firewall default-deny.

La pagina sui dev container avverte infatti che una sessione in bypass può comunque esfiltrare «tutto ciò che è accessibile dentro il container, comprese le credenziali di Claude Code conservate in ~/.claude». E se nel container ci sono dati personali, la fuga diventa anche una questione di GDPR. Monta il repository, mai la tua home directory.

Come evitare che Claude Code chieda il permesso ogni volta, senza usare il flag?

Con la modalità auto, oppure scrivendo delle regole. La modalità auto sostituisce il prompt con un modello classificatore, e sui piani Pro, Max e Team è già il default. Negli altri casi le leve sono queste: le regole permissions.allow pre-approvano i comandi che lanci tutto il giorno, acceptEdits elimina i prompt sulle modifiche ai file, e la modalità auto-allow della sandbox esegue senza chiedere i comandi di shell che girano in sandbox.

L'argomento a favore di meno prompt, del resto, lo fornisce Anthropic stessa. Il suo post di engineering sulla modalità auto, del 25 marzo 2026, si apre così: «Gli utenti di Claude Code approvano il 93% dei prompt di permesso». Un punto di controllo che dice sì 93 volte su 100 è soprattutto un'abitudine. Conta che cosa lo sostituisce, e per il flag la pagina sul sandboxing risponde con una parola: «Niente».

Ecco un ~/.claude/settings.json che elimina la maggior parte dei prompt e tiene quelli sulle operazioni pericolose:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "disableBypassPermissionsMode": "disable",
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "ask": ["Bash(git push *)", "Bash(terraform *)"],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)"
    ]
  }
}

Le regole vengono valutate in quest'ordine: prima deny, poi ask, poi allow. Se il tuo obiettivo è «consenti tutto», lo schema documentato è un "Bash" senza argomenti in allow, più un hook PreToolUse che respinge i pochi comandi che non vuoi vedere mai.

Quanto a disableBypassPermissionsMode, è la chiave che cercano gli amministratori: messa nei managed settings, le impostazioni gestite, chiude la porta a tutto il team, e a quel punto Claude Code «rifiuta il flag --dangerously-skip-permissions».

Le regole Bash(...) hanno un limite che conviene conoscere: confrontano il testo del comando. La pagina sui permessi di Anthropic scrive che una regola deny «copre l'invocazione che Claude produce di solito e non è un confine di sicurezza attorno al programma». In pratica Bash(rm *) ferma rm -rf build/, ma non /bin/rm -rf build/ né bash -c 'rm -rf build/'.

Quali guardrail di Claude Code funzionano ancora con i permessi saltati?

Tre: le regole deny, il controllo di rm sui percorsi critici e gli hook PreToolUse. La guida agli hook afferma che questi hook «scattano prima di qualsiasi controllo legato alla modalità di permesso, in ogni modalità», e che un hook che restituisce un deny «blocca il tool anche in modalità bypassPermissions o con --dangerously-skip-permissions». Dei tre, l'hook è l'unico che esegue una logica scritta da te.

Eccone uno ridotto all'osso, registrato in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "$HOME/.claude/hooks/guard.sh" }]
      }
    ]
  }
}

#!/bin/bash
# ~/.claude/hooks/guard.sh: exit 2 blocca la chiamata, stderr torna a Claude
CMD=$(jq -r '.tool_input.command')
if echo "$CMD" | grep -Eiq 'terraform[[:space:]]+destroy|drop[[:space:]]+(schema|database|table)|push[[:space:]].*--force'; then
  echo "Blocked: destructive command, ask the human to run it." >&2
  exit 2
fi
exit 0

Tienilo nei settings utente o in quelli gestiti. In bypass la directory .claude del progetto è scrivibile senza prompt, quindi un hook che vive nel repository l'agente se lo può modificare da solo.

Veniamo ai limiti, perché anche questa guardia confronta del testo. La nota di ricerca GuardFall della Cloud Security Alliance, pubblicata l'11 luglio 2026, ha aggirato le guardie dei comandi di dieci agenti di coding open source su undici, usando cinque classi di shell injection. Claude Code non faceva parte del campione, ma il ragionamento vale per qualunque matcher: «Una guardia che ispeziona la stringa prima della trasformazione e una shell che esegue la stringa dopo la trasformazione stanno, di fatto, valutando due comandi diversi».

La nostra guardia dei comandi sbaglia anche nell'altro senso, e lo abbiamo misurato. Nel nostro studio controllato del 24 agosto 2026 ha controllato 1.769 comandi di shell e ne ha rifiutati 17: un caso reale, cioè un agente che andava a prendersi una credenziale salvata, tre applicazioni corrette della policy e 13 falsi positivi, ciascuno costato un turno all'agente. Per la maggior parte erano il token nc riconosciuto dentro un heredoc Python.

Una guardia testuale è un filo d'inciampo per il caso comune. Il confine che regge quando la guardia manca il colpo è il container.

Claude Code ha davvero cancellato un database di produzione?

Sì, e nel caso meglio documentato il flag non c'entrava. Il 26 febbraio 2026 Claude Code ha eseguito terraform destroy sull'infrastruttura di produzione di DataTalks.Club, portandosi via il database, 2,5 anni di elaborati consegnati nei corsi e tutti gli snapshot automatici. Il fondatore, Alexey Grigorev, ha pubblicato il post-mortem il 6 marzo; il supporto di AWS ha ripristinato i dati circa 24 ore dopo.

L'agente la sua mossa l'aveva annunciata: «Non posso farlo. Eseguirò un terraform destroy». Grigorev scrive che la cosa «sembrava logica», e quindi «non ho fermato l'agente». Nel suo post i permessi saltati non compaiono mai: al punto di controllo c'era una persona, e il comando è passato perché la motivazione suonava giusta. Il suo bilancio, ripreso anche da Tom's Hardware: «Ho trattato plan, apply e destroy come qualcosa che si poteva delegare. Questo ha eliminato l'ultimo livello di sicurezza».

93%

dei prompt di permesso approvati dagli utenti di Claude Code (Anthropic, 25 marzo 2026)

65

issue con rm -rf nel titolo sul tracker di Claude Code, 13 ancora aperte (API GitHub, 20 settembre 2026)

17%

dei casi reali di azioni troppo zelanti sfuggiti al classificatore della modalità auto, secondo i conti della stessa Anthropic

Una ricerca nei titoli del tracker di Claude Code per rm -rf restituisce 65 issue al 20 settembre 2026, e una si intitola «Claude Code ha eseguito rm -rf cancellando l'intera home directory». Sono segnalazioni di utenti, che non abbiamo verificato. Nel registro degli incidenti interni di Anthropic, riportato nello stesso post sulla modalità auto, compare anche questo: «tentare migrazioni su un database di produzione».

Che cosa avrebbe aiutato, dal rimedio più solido al più debole:

1. nessuna credenziale di produzione nella sessione e la protezione dalla cancellazione sul database, che è poi la correzione adottata da Grigorev;
2. una regola ask su Bash(terraform *);
3. l'hook visto sopra;
4. la modalità auto, la cui lista di blocchi predefinita nomina terraform destroy.

Claude Code è sicuro per il lavoro in azienda, se nessuno salta i permessi?

Più sicuro sì, completo no. Intanto c'è codice che gira prima che il sistema dei permessi possa dire la sua. La CVE-2025-59536 permetteva a un progetto di eseguire codice prima che venisse accettata la finestra di fiducia all'avvio (corretta nella 1.0.111), e la ricerca GitSpawn di Manifold, del 1º settembre 2026, ha fatto eseguire il comando core.fsmonitor di un repository «prima che il prompt di fiducia del workspace venisse accettato». E poi i permessi decidono soltanto se un'azione può essere eseguita: il codice che l'agente scrive non lo leggono mai.

Questo secondo limite è la ragione per cui l'articolo esiste. Tutti i controlli visti finora decidono che cosa Claude Code può eseguire, e nessuno guarda che cosa scrive. Una sessione in Manual, con ogni prompt letto da un ingegnere attento, può comunque committare un endpoint senza controllo di autorizzazione: un diff che compila non è un evento di permesso. Saltare i permessi toglie l'ultimo punto di controllo umano sulle azioni; tenerli non ne aggiunge nessuno sul codice. Quella parte la pagina sulla sicurezza di Anthropic la lascia a te: «Sei responsabile di verificare che il codice e i comandi proposti siano sicuri prima di approvarli».

È lì che si colloca un controllo in agent-time. VibeDefend gira come hook dentro lo stesso loop: mette nel contesto del modello le regole che riguardano un file nel momento in cui lo modifica, restituisce all'agente i finding di SAST, SCA, segreti, IaC e CI/CD, e sorveglia i comandi, con i limiti descritti sopra.

Nello studio del 24 agosto, l'agente con il livello ha implementato alla lettera 57 dettagli di regola valutati su 64 (89%), contro 8 su 65 (12%) senza alcuno strumento. Lo stesso studio registra un task in cui la regola è stata servita tredici volte e l'agente ha comunque smantellato le proprie protezioni: l'injection informa, non impone. I dettagli sono in Claude Code segue il tuo CLAUDE.md?, in sicurezza degli agenti di codice AI e nella nostra guida alla sicurezza di Claude Code.

Se usi il flag di proposito, in un container, con un utente non root, con le regole deny, un hook e qualcosa che legga il diff, la configurazione è difendibile. Sul portatile passa alla modalità auto, e parliamone per la parte che nessuna modalità di permesso copre.

Domande frequenti

Qual è il comando per dangerously skip permissions in Claude Code?

claude --dangerously-skip-permissions, oppure l'equivalente claude --permission-mode bypassPermissions, con -p "<prompt>" se vuoi un'esecuzione non interattiva. Anthropic lo riserva ad «ambienti isolati come container, VM o dev container senza accesso a internet».

--dangerously-skip-permissions è attivo di default in Claude Code?

No. Il default di fabbrica è la modalità auto sui piani Pro, Max e Team, e Manual in tutti gli altri casi. Per il bypass servono il flag, un defaultMode a livello utente, oppure un'opzione da attivare esplicitamente nell'estensione VS Code e nell'app desktop. Dalla v2.1.257 i settings di un repository non possono più selezionarlo.

Posso abilitare bypass permissions senza riavviare Claude Code?

Solo se hai lanciato la sessione con --allow-dangerously-skip-permissions, con il flag stesso o con un defaultMode utente impostato su bypassPermissions. Altrimenti la modalità nel ciclo di Shift+Tab non compare proprio, e l'unica strada è rilanciare la sessione.

Come si imposta defaultMode nel settings.json di Claude Code?

Scrivi "permissions": { "defaultMode": "acceptEdits" } in ~/.claude/settings.json. I valori ammessi sono default (alias manual), acceptEdits, plan, auto, dontAsk e bypassPermissions. auto e bypassPermissions vengono ignorati se arrivano dai settings di progetto o locali, e l'estensione VS Code legge prima claudeCode.initialPermissionMode.

Come autorizzo tutti i comandi in Claude Code senza saltare i permessi?

Aggiungi un "Bash" senza argomenti a permissions.allow e registra un hook PreToolUse che respinga i comandi che non vuoi mai. Le regole deny e ask continuano ad avere la precedenza. L'alternativa che costa meno fatica è la modalità auto, anche se Anthropic precisa che «non garantisce la sicurezza».

Claude Code è sicuro sul mio computer personale?

In Manual o in modalità auto, con regole deny sui file .env, su ~/.ssh e sulle cartelle delle credenziali cloud, sì per il lavoro di tutti i giorni. Con i permessi saltati direttamente sull'host, no: l'agente agisce come il tuo utente, con chiavi SSH e credenziali cloud a portata di mano. Usa un container.

Claude Code è adatto all'uso aziendale?

I controlli ci sono: un managed-settings.json (in /etc/claude-code/ su Linux) con disableBypassPermissionsMode, allowManagedPermissionRulesOnly e allowManagedHooksOnly, più le chiavi della sandbox imposte a livello centrale. Governano che cosa l'agente può eseguire. Nessuno rivede il codice che produce: quel lavoro resta tuo.