Tutti i permessi, senza distruggere la tua macchina

Claude Code chiede prima di fare qualsiasi cosa con conseguenze. Alla scrivania va bene: dai un'occhiata, approvi e prosegui. Lontano dalla scrivania blocca il lavoro. L'agente si ferma al terzo passo di un'attività da venti minuti e aspetta un tocco che arriva quaranta minuti dopo, quando il senso di affidargli il lavoro era proprio che tu non stessi guardando.

Così si ricorre a --dangerously-skip-permissions. Quel flag è pericoloso sulla macchina sbagliata e ragionevole su quella giusta, e la differenza non sta in quanto sei prudente. Sta in cosa può raggiungere l'agente quando fa qualcosa che non intendevi. Questa pagina spiega cosa fa davvero il flag, perché non funziona come root, la configurazione che lo rende difendibile, e gli equivalenti in Codex, OpenCode, Grok Build e Antigravity.

Cosa consente davvero il bypass

Claude Code ha sei modalità di permesso. La pagina sulle modalità di permesso di Anthropic le descrive così. La tabella segue l'ordine della documentazione: default è il nome di configurazione della modalità Manual, non la modalità con cui parte una sessione.

Il bypass esegue subito ogni chiamata a uno strumento, comprese le scritture in percorsi protetti come .git e la configurazione di Claude stesso. Alcune cose valgono comunque:

• Le regole di divieto nelle tue impostazioni bloccano in ogni modalità, bypass compreso. Le regole di autorizzazione lì non hanno effetto.
• Le regole ask esplicite chiedono comunque.
• rm e rmdir rivolti a percorsi critici chiedono comunque: la radice del filesystem, le directory di primo livello, la tua home, e la directory di lavoro e le sue genitrici.

Il bypass non ti dà alcuna difesa contro la prompt injection o contro un comando sbagliato eseguito con sicurezza. La documentazione di Anthropic lo dice chiaramente: usalo solo in ambienti isolati in cui Claude Code non può danneggiare l'host.

Due flag che si somigliano

• --dangerously-skip-permissions avvia la sessione in bypass. Equivale a --permission-mode bypassPermissions.
• --allow-dangerously-skip-permissions aggiunge soltanto il bypass al ciclo di Shift+Tab. La sessione parte in una modalità normale, e passi al bypass quando lo decidi tu.

Il secondo conta perché non puoi entrare in bypass da una sessione che non è stata avviata con il bypass abilitato. Se pensi di volerlo in seguito, devi deciderlo all'avvio. La forma --allow- è il modo prudente di farlo: la sessione si comporta normalmente finché non cambi modalità di proposito.

Il primo avvio interattivo con il bypass abilitato mostra una finestra di avviso. Accettarla scrive skipDangerousModePermissionPrompt: true in ~/.claude/settings.json; rifiutarla fa uscire Claude Code. Le esecuzioni non interattive con -p saltano la finestra. Gli amministratori possono bloccare la modalità per tutti con permissions.disableBypassPermissionsMode: "disable" nelle impostazioni gestite.

Perché fallisce come root

Su Linux e macOS, Claude Code si rifiuta di partire in modalità bypass come root o con sudo:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Il controllo viene saltato dentro una sandbox che Claude Code riconosce, ed è per questo che il dev container di Anthropic lo esegue con un utente non root. Su un normale VPS dove accedi come root, crea prima un utente normale. La nostra guida alla configurazione del VPS riporta i tre comandi.

Abbiamo imparato tre cose pratiche eseguendo Claude Code sotto il daemon di Maude su molti server diversi:

• Come root, falliva anche la forma --allow-. Nei nostri test con Claude Code 2.1.x il processo terminava all'avvio, invece di limitarsi a escludere il bypass dal ciclo. Qualsiasi wrapper che aggiunge il flag deve prima controllare l'ID utente, altrimenti muore ogni sessione su un server root.
• Le versioni vecchie rifiutano il flag del tutto. Una CLI che non conosce il flag esce allo stesso modo. Controlla che compaia in claude --help prima di passarlo.
• Testa su una macchina pulita. Il tuo ~/.claude/settings.json probabilmente ha già skipDangerousModePermissionPrompt dal giorno in cui hai accettato l'avviso. Su un server nuovo quella finestra compare prima del prompt, e una sessione senza supervisione resta lì ad aspettare. Testa in un container pulito, non sul tuo portatile.

Lo schema del server usa e getta

Prima di allentare i permessi ovunque, fatti una domanda: se questo processo eseguisse adesso un comando distruttivo qualsiasi, cosa perderei?

Su un portatile tipico la risposta onesta è scomoda: le tue chiavi SSH, le credenziali cloud in ~/.aws e ~/.config, profili del browser con sessioni attive, un .env con URL di produzione, e ogni altro repository che hai in locale. Su un VPS usa e getta con un solo progetto, la risposta è quel progetto, che comunque è già stato pushato, più un'ora per ricostruire. È un rischio accettabile. Ecco tre posti dove mettere l'agente:

Un container sulla tua macchina

È l'opzione più economica e più vicina. Avvia un container Linux con Docker o OrbStack, installa Claude Code dentro con un utente non root e monta solo il progetto su cui vuoi che lavori. Non montare la tua home, non passare le credenziali dell'host e non usare --privileged né montare il socket di Docker, perché entrambi restituiscono l'accesso all'host.

Un VPS dedicato

È l'opzione su cui si orienta la maggior parte delle persone: una piccola macchina che esegue uno o due progetti e nient'altro. È sempre accesa, quindi il lavoro continua mentre le tue macchine sono spente. Se mai venisse compromessa, la distruggi e ne costruisci un'altra. Fai in modo che ricostruirla sia banale, con un breve script di setup invece di una macchina rifinita a mano per un anno. La guida all'acquisto di un VPS tratta il dimensionamento.

Una sandbox cloud effimera

Le sessioni cloud di Anthropic eseguono ogni attività in una VM isolata, con le credenziali git tenute fuori dalla sandbox e l'accesso alla rete limitato di default. È un isolamento solido senza nulla da mantenere. Ma lì il bypass non è disponibile. Le sessioni cloud offrono Accept edits, Plan e Auto, e ignorano bypassPermissions impostato nelle impostazioni di un repository.

Segreti da tenere fuori dalla macchina

• Credenziali di produzione. Puntalo verso lo staging o una copia locale. Il guaio da cui ti stai proteggendo non è la malizia; è un errore commesso con sicurezza contro una stringa di connessione che si trovava lì per caso.
• La tua chiave SSH personale. Dai al server una sua deploy key o un token con permessi granulari, limitato ai repository che gli servono. Non usare nemmeno l'SSH agent forwarding verso di esso: presteresti le tue chiavi alla macchina per tutto il tempo in cui sei collegato.
• Token cloud troppo ampi. Niente chiavi AWS da amministratore né token GitHub validi per tutta l'organizzazione. Se un'attività ne richiede uno, limitane la portata e lascialo scadere.
• Tutto ciò che esiste solo lì. Fai push spesso, così perdere il server non ti costa nulla che non puoi ricreare.

Una credenziale deve stare sulla macchina: l'accesso dell'agente stesso. Claude Code lo conserva in ~/.claude/.credentials.json, quindi chiunque abbia una shell con quell'utente può usare il tuo piano. Un motivo in più per dare all'agente un utente tutto suo.

Equivalenti in Codex e negli altri agenti

Ogni agente di coding ha la sua versione di questo interruttore, e non significano tutte la stessa cosa:

Fonti: riferimento di Codex CLI e approvazioni e sicurezza, permessi di OpenCode, permessi di Grok Build, permessi di Antigravity e il codelab di Google su Antigravity CLI, verificati a ottobre 2026. Codex e Antigravity usano entrambi una sandbox di default, quindi disattivare le richieste e disattivare la sandbox sono decisioni separate. È disattivare la sandbox che richiede la macchina usa e getta.

Posso attivare il bypass dal telefono?

Non dall'app Claude. La documentazione mobile di Anthropic dice che non puoi selezionare Bypass permissions dall'app, né per le sessioni cloud né per Remote Control, e Remote Control dall'app non offre nemmeno Auto. Per un client generico è un'impostazione sensata.

Maude è pensato per l'altro caso, un server tuo che potresti ricostruire, quindi offre la modalità ad accesso completo di ogni agente come «yolo», accanto alle altre modalità dell'agente. Per Claude ha effetto solo quando il daemon gira con un utente non root e il Claude Code installato supporta il flag. Altrimenti la sessione resta in una modalità normale. Maude avvia la sessione in una modalità normale e passa al bypass dopo l'avvio, mai alla creazione del processo. Su un server con solo root, un pulsante nell'app crea un utente non root per te. Puoi impostare una modalità predefinita per ogni agente, o cambiarla per singola sessione.

Gestiscilo dal telefono

Se hai preparato il server usa e getta, Claude Code sul telefono mostra come lo esegue Maude. Approvare i permessi degli agenti dal telefono copre l'approccio opposto: tenere attive le richieste e rispondere da una notifica.

Domande frequenti

Cosa è cambiato

• 1 ottobre 2026 — Riscritto: restrizione per root, --allow-dangerously-skip-permissions vs --dangerously-skip-permissions, la modalità auto come via di mezzo predefinita, cosa blocca ancora il bypass, gli equivalenti in Codex/OpenCode/Grok Build/Antigravity, e cosa consentono l'app mobile di Anthropic e Maude.
• 25 luglio 2026 — Prima pubblicazione.