Claude Code su server: come eseguirlo in sicurezza

Cosa significa eseguire Claude Code in sicurezza su un server

Per eseguire Claude Code in sicurezza su un server, mantieni attive le richieste di autorizzazione, eseguilo con un utente dedicato senza privilegi e assegna alle esecuzioni non supervisionate un vero limite operativo, invece di basarti sulla fiducia: il sandbox integrato, un container oppure un VPS temporaneo che non contenga dati importanti. Il flag --dangerously-skip-permissions rimuove il passaggio di approvazione tra il modello e la shell. Questo compromesso può essere ragionevole per le attività non supervisionate, ma solo all'interno di un limite che riduca ciò che un singolo comando errato può raggiungere. Questa guida spiega cosa modifica effettivamente il flag e come costruire questo limite con livelli progressivi di isolamento.

Cosa può fare Claude Code sul tuo server

Claude Code è un agente per lo sviluppo che viene eseguito nel terminale. Legge file, scrive file ed esegue comandi shell con l'utente che lo ha avviato. Questo è il valore principale dello strumento: può clonare un repository, modificare il codice, eseguire i test, leggere l'errore e correggere il codice in un ciclo continuo, senza che tu debba digitare ogni comando. Se non lo hai ancora configurato su un server, eseguire Claude Code su un VPS con tmux descrive l'installazione e la gestione della sessione. Questa pagina descrive i privilegi che gli concedi dopo la configurazione.

Il rischio è contenuto nella stessa frase, riletta una seconda volta. Un processo che esegue comandi shell con il tuo utente può fare tutto ciò che può fare il tuo utente. Può leggere ~/.ssh/id_ed25519, ~/.aws/credentials e ogni file .env che il tuo utente può aprire. Può eseguire curl e inviare dati a qualsiasi host raggiungibile dal server. Può eseguire git push --force. L'agente non ha obiettivi propri. Il pericolo nasce quando un'attività va male oppure quando il testo letto durante l'esecuzione contiene istruzioni scritte da terzi: una pagina web recuperata oppure un commento in una issue che gli è stato chiesto di correggere. Il secondo caso si chiama prompt injection. Per questo, pensare che «il modello è solitamente affidabile» non costituisce un piano di sicurezza. Le istruzioni possono arrivare anche da fonti più vicine, perché due sessioni di Claude Code sullo stesso server possono inviarsi testo a vicenda e un messaggio proveniente da una sessione parallela è semplicemente altro testo che l'agente ricevente legge. Devi pianificare il comportamento in caso di esecuzione errata, non quello medio.

Il sistema delle autorizzazioni in termini semplici

Per impostazione predefinita, Claude Code chiede conferma prima di eseguire un'azione. La lettura dei file all'interno del progetto avviene senza messaggi, ma prima di modificare un file o eseguire un comando shell mostra l'operazione o il comando esatto e attende una risposta affermativa. È possibile approvare una singola azione oppure approvare quel tipo di azione per il resto della sessione. Le approvazioni sono valide solo per la sessione corrente: quando si esce dalla CLI, la sessione successiva riparte nuovamente in modalità prudente. Per le regole da conservare, il file delle impostazioni contiene elenchi persistenti di operazioni consentite, da confermare e negate. Ad esempio: consentire git status, chiedere conferma per git push, negare le letture di .env. Le regole di negazione hanno sempre la precedenza. Anche questa configurazione di base sta cambiando, perché la modalità automatica diventerà predefinita il 14 agosto 2026; prima di decidere quale modalità utilizzare su un server che non è possibile monitorare, conviene quindi sapere che cosa consente realmente ciascuna modalità di autorizzazione.

Questo modello presuppone che una persona controlli il terminale, come normalmente avviene su un laptop. Su un server, invece, spesso non c'è nessuno a controllarlo. Si avvia un'attività lunga all'interno di tmux e si va a dormire; se l'agent si ferma per porre una domanda alle 2 di notte, non fa più progressi fino al mattino. La pausa comporta un costo oltre alla perdita di tempo, perché una sessione di Claude Code inattiva perde la cache del prompt mantenuta in memoria e il turno successivo deve ricostruirla, con un nuovo costo. Questo è il motivo concreto per cui sui server si ricorre al flag di esclusione dei controlli, e il problema che risolve è reale. Il resto di questa guida spiega come risolverlo senza rinunciare a tutte le protezioni.

Che cosa modifica --dangerously-skip-permissions

claude --dangerously-skip-permissions disattiva il passaggio di approvazione. Le modifiche vengono applicate senza richiesta di conferma. I comandi della shell vengono eseguiti senza richiesta di conferma. Vengono ignorati anche i controlli sui percorsi protetti che normalmente tutelano le directory sensibili. Le regole di diniego esplicite continuano ad applicarsi e alcune operazioni particolarmente rischiose richiedono comunque una conferma, ma il riepilogo operativo è semplice: qualunque operazione il modello decida di eseguire viene eseguita.

Su un server, il flag comporta due aspetti importanti. Primo, è bloccato quando Claude Code viene eseguito come root o tramite sudo su Linux e macOS, perché root senza richieste di conferma può modificare qualsiasi file o servizio del sistema. In ogni caso, l'agente deve usare un account non privilegiato dedicato, e il flag impone questa condizione. Secondo, il flag non modifica in alcun modo il comportamento del modello. Rimuove l'intervento umano dal flusso e non cambia altro, quindi viene eseguito anche ogni errore che una richiesta di conferma avrebbe intercettato.

La valutazione corretta è quindi questa. Se si ignorano le autorizzazioni, la domanda di sicurezza passa da "l'agente eseguirà un'operazione dannosa?" a "quanti danni può causare una singola operazione errata?". Non si cerca più di controllare ogni decisione, ma di limitare l'entità dell'impatto. La risposta è il contenimento, che può essere applicato su più livelli.

Il sandbox integrato di Claude Code

Prima dei livelli, è importante sapere che Claude Code include ora un sandbox a livello di sistema operativo per i comandi che esegue. Questo elimina gran parte dei motivi per cui si ricorreva al flag skip. Su Linux usa bubblewrap per l'isolamento del filesystem e socat per instradare il traffico di rete attraverso un proxy. Nel sandbox, un comando può scrivere soltanto nella directory del progetto e in una directory temporanea della sessione. Può raggiungere la rete soltanto tramite un proxy che verifica ogni dominio rispetto a un elenco di autorizzazioni. La prima volta che un comando deve raggiungere un nuovo dominio, Claude Code chiede conferma.

Attivalo con il comando /sandbox all'interno di una sessione. Su Ubuntu e Debian, installa prima i due pacchetti necessari:

sudo apt install bubblewrap socat

Su Ubuntu 24.04 e versioni successive, la policy AppArmor predefinita impedisce a bubblewrap di creare gli user namespace necessari. Il pannello del sandbox indica quando manca qualcosa. La documentazione sul sandboxing di Claude Code contiene il breve profilo AppArmor che risolve il problema.

Il sandbox dispone di una modalità di autorizzazione automatica: i comandi eseguiti nel sandbox partono senza prompt, perché ora è il confine applicato dal sistema operativo a svolgere il compito che prima spettava al prompt. I comandi che non possono essere eseguiti nel sandbox seguono il normale flusso delle autorizzazioni. Le azioni realmente insolite richiedono quindi ancora una conferma. Per la maggior parte dei flussi di lavoro sui server, questa è la sostituzione corretta del flag skip: si ricevono molte meno richieste, mantenendo un confine imposto dal sistema operativo invece di eliminarlo.

È importante conoscerne i limiti. Per impostazione predefinita, un comando nel sandbox può ancora leggere gran parte del filesystem, inclusi i file contenenti credenziali, a meno che non si neghino esplicitamente quei percorsi; l'impostazione sandbox.credentials esiste proprio per questo. Il proxy di rete verifica i nomi di dominio, ma non analizza il traffico. Un'autorizzazione ampia come github.com lascia quindi ancora la possibilità di esfiltrare dati. Docker non funziona al suo interno. Il sandbox aumenta notevolmente il livello minimo di sicurezza. Non costituisce un confine di isolamento completo. Per questo i livelli descritti di seguito restano importanti.

La scala di isolamento

Tre livelli, in ordine crescente di isolamento. Scegli il livello più basso compatibile con gli altri elementi presenti sul server.

Livello 1: un utente non privilegiato dedicato. Assegna all'agent un account dedicato, una home directory dedicata, una directory di progetto dedicata e nessun accesso sudo:

sudo adduser --disabled-password --gecos "" agent

Il confine dell'account impedisce all'agent di accedere ai tuoi file: alle tue chiavi SSH e a tutti gli altri progetti presenti sulla macchina. Inoltre rende utilizzabile il flag di esclusione, perché questo flag non consente l'esecuzione come root. È lo stesso principio di eseguire ogni servizio come utente non privilegiato, applicato a un agent. Il livello 1 non limita la rete né gli elementi del server leggibili da tutti.

Livello 2: un container. Anthropic pubblica un devcontainer di riferimento che esegue Claude Code come utente non root, con regole firewall che limitano gli host raggiungibili dall'agent. Un container creato autonomamente svolge la stessa funzione. Il filesystem si riduce ai volumi montati e il traffico in uscita si limita a ciò che consentono le regole del container. Questo è il livello intermedio corretto quando il server ospita altri servizi importanti. Il limite è che i container condividono il kernel dell'host e un mount configurato senza attenzione annulla il confine; assegna al container /var/run/docker.sock e potrà raggiungere l'intero host.

Livello 3: un VPS dedicato. Il livello più forte è anche il più semplice: assegna all'agent una macchina intera che non contiene nulla di importante. Un VPS di piccole dimensioni costa pochi dollari al mese. Configuralo seguendo la procedura dei primi dieci minuti su un nuovo VPS, crea uno snapshot dello stato pulito e lascia che l'agent lavori. Non ci sarà nient'altro. Nessuna chiave SSH personale, ma solo una deploy key limitata a un unico repository. Nessuna credenziale cloud e nessun dato di produzione. Quando un'esecuzione va male, o quando vuoi semplicemente ripartire da uno stato pulito, ripristina lo snapshot oppure elimina e ricrea il server in pochi minuti. Il raggio d'azione dell'incidente si limita al costo del VPS. In questa configurazione --dangerously-skip-permissions non è più preoccupante, perché l'esito realistico peggiore è ricreare il server e revocare un token.

I livelli possono essere combinati. Un agent isolato, eseguito come utente non privilegiato su un VPS usa e getta, costa quasi nulla in più e rende banali gli scenari di errore. Questo è l'obiettivo.

Proteggere le credenziali

La regola da cui dipende tutto il resto è questa: l'utente dell'agente non deve poter leggere i secret appartenenti ad altri componenti.

Fornisci la chiave API all'agente e a nessun altro. Inseriscila in un file di proprietà dell'utente dell'agente con modalità 600 e caricala all'avvio della shell:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Poi chiudi l'accesso nell'altra direzione. Su Debian e Ubuntu, spesso le home directory vengono create con permessi che ne consentono la lettura a tutti gli utenti del sistema. Rendi quindi più restrittiva la tua: chmod 750 /home/youruser. Verifica con ls -ld /home/* e correggi tutto ciò che l'account dell'agente può elencare.

Limita l'ambito di ogni token. Un token GitHub con autorizzazioni granulari limitate a un singolo repository, oppure una deploy key specifica per repository, fa sì che una credenziale compromessa esponga un solo progetto e non l'intero account. Se usi la sandbox, aggiungi le relative impostazioni delle credenziali, in modo che ~/.ssh e ~/.aws siano negati anche per le operazioni di lettura. Inoltre, non conservare le credenziali di produzione sul server: un agente non può divulgare un secret che non è mai stato presente. Se questi secret sono archiviati in un password manager self-hosted, mantienilo su un server diverso da quello dell'agente e sottoponilo a una revisione separata, perché i punti deboli di Vaultwarden sono il token amministrativo e il file di backup, non il vault cifrato in sé.

Git è la rete di sicurezza

Ogni modifica apportata dall'agente deve poter essere esaminata e annullata. Git offre entrambe le possibilità senza costi aggiuntivi se l'agente lavora su un branch:

git switch -c agent/refactor-auth

Esamina l'esecuzione con git diff main...agent/refactor-auth, integra le modifiche corrette ed elimina il branch se l'esecuzione non ha prodotto risultati utili. Un'esecuzione che modifica tre file è molto più semplice da leggere durante la revisione rispetto a una che riscrive metà del modulo. Questo è il motivo pratico per usare una skill che obbliga l'agente ad applicare la modifica minima efficace. Proteggi il branch principale sul forge, in modo che il token dell'agente non possa eseguirvi il push e non possa eseguire force-push in alcun repository. La cronologia dei commit funge anche da registro di audit delle attività svolte mentre dormivi e vale più di qualsiasi quantità di output conservato nel terminale.

La rete rientra nel perimetro dell’incidente

Un agente può eseguire curl. Questa frase descrive l’intero problema del traffico in uscita: qualunque dato l’agente possa leggere, può anche inviarlo altrove, soprattutto se il prompt è stato manipolato. Un normale utente senza privilegi non limita affatto questo comportamento, perché ogni utente può raggiungere qualsiasi destinazione raggiungibile dal server. Il sandbox lo limita per dominio tramite il relativo proxy. Un container può limitarlo con le proprie regole firewall. Un VPS dedicato limita innanzitutto la quantità di dati che può essere esfiltrata. Tra le tre opzioni, è la soluzione più robusta.

Non cercare di risolvere il traffico in uscita usando solo ufw. Per impostazione predefinita, ufw consente tutto il traffico in uscita. Scrivere regole in uscita che continuino a consentire apt, npm, git e Claude API è un lavoro complesso e soggetto a errori, che può causare blocchi senza produrre indicazioni evidenti. Scegli invece il livello di isolamento del sandbox, del container o della macchina. In questo modo, una allow list di domini o una macchina dedicata svolge lo stesso compito in modo chiaro e affidabile.

Se stai sviluppando un tuo agente tramite API invece di eseguire Claude Code, lo stesso ragionamento resta valido. Sviluppare un agente AI con Claude su un VPS descrive questo approccio. Anche il relativo agente deve usare lo stesso utente dedicato, gli stessi token con ambito limitato e la stessa macchina usa e getta.

Prima metti in sicurezza il server

Indipendentemente dal livello scelto, il server deve avere le configurazioni di base prima di installare l'agent: solo chiavi SSH, accesso root disabilitato, firewall con criterio predefinito di negazione e aggiornamenti di sicurezza automatici. Genera qui la checklist e completala una sola volta:

FAQ

È sicuro usare --dangerously-skip-permissions su un server?

Non da solo. Il flag rimuove ogni richiesta di approvazione, quindi il primo comando errato viene eseguito non appena il modello lo genera. Diventa un compromesso accettabile quando si limita il raggio d'azione: almeno un utente dedicato senza privilegi e, per attività realmente non supervisionate, un container o un VPS usa e getta che contenga un solo progetto e un solo token con ambito limitato. Non usarlo mai su una macchina che contiene credenziali di produzione o dati che non puoi perdere.

Claude Code dispone di una sandbox?

Sì. Claude Code include una sandbox integrata per i comandi shell, che si apre con il comando /sandbox. Su Linux usa bubblewrap e su macOS usa Seatbelt; limita le scritture alla directory del progetto e instrada l'accesso di rete tramite un proxy che consente soltanto i domini approvati. La modalità auto-allow esegue i comandi nella sandbox senza richieste, riducendo le interruzioni come fa il flag di skip, ma mantenendo un confine imposto dal sistema operativo. Non costituisce un isolamento completo, quindi per le esecuzioni non supervisionate va usata insieme a un utente dedicato o a una macchina dedicata.

Perché il flag di skip rifiuta l'esecuzione come root?

Perché root, senza richieste di autorizzazione, può modificare qualsiasi file e qualsiasi servizio del sistema. Per questo Claude Code blocca --dangerously-skip-permissions quando viene eseguito come root o tramite sudo su Linux e macOS. La soluzione non consiste nell'aggirare il controllo. Crea un utente senza privilegi per l'agente ed eseguilo con quell'account: il confine tra gli account è il primo livello di contenimento e anche il meno costoso.

Claude Code può leggere le mie chiavi SSH e i file .env?

Può leggere tutto ciò che l'utente con cui viene eseguito può leggere. Anche i criteri predefiniti della sandbox consentono la lettura dei percorsi contenenti credenziali finché non la neghi. Esegui quindi l'agente con un utente dedicato, mantieni la tua directory home con permessi 750 o più restrittivi, nega i percorsi delle credenziali nelle impostazioni della sandbox e non conservare in alcun caso i secret di produzione sulla macchina. Un secret che la macchina non ha mai contenuto non può essere letto né divulgato.

Qual è il modo più sicuro per eseguire Claude Code senza supervisione?

Un VPS dedicato economico, usato esclusivamente per il lavoro dell'agente: puoi applicare l'hardening in dieci minuti, creare uno snapshot pulito, eseguire Claude Code con un utente senza privilegi e con la sandbox attiva, conservare la API key in un file con permessi 600, usare una deploy key per ogni repository e svolgere tutto il lavoro su branch da revisionare prima del merge. Se un'esecuzione va male, revochi un solo token e ripristini lo snapshot, senza compromettere nessun altro sistema o dato di tua proprietà.