Come usare Claude Code in sicurezza su server

Cosa significa eseguire Claude Code in sicurezza su un server

Per eseguire Claude Code in sicurezza su un server, mantieni attivi i prompt di autorizzazione, eseguilo come un utente dedicato non privilegiato e fornisci alle esecuzioni unattended un confine reale invece della semplice fiducia: il sandbox integrato, un container o un VPS usa e getta che non contenga dati importanti. Il flag --dangerously-skip-permissions rimuove il passaggio di approvazione tra il modello e la tua shell. Questo compromesso può essere accettabile per il lavoro unattended, ma solo all'interno di un confine che limiti l'impatto di un comando errato. Questa guida spiega cosa cambia effettivamente il flag e come costruire questo confine attraverso livelli di isolamento crescenti.

Cosa può fare Claude Code sulla tua macchina

Claude Code è un agente di coding che viene eseguito nel terminale. Legge file, scrive file ed esegue comandi shell come 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, senza che tu debba digitare ogni comando. Se non lo hai ancora configurato su un server, eseguire Claude Code su un VPS con tmux copre l'installazione e la gestione della sessione. Questa pagina descrive il potere che gli conferisci una volta installato.

Il rischio è lo stesso concetto letto una seconda volta. Un processo che esegue comandi shell come il tuo utente può fare tutto ciò che il tuo utente può fare. 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 motivazioni proprie. Il pericolo è che un task fallisca, o che il testo letto durante il lavoro contenga istruzioni scritte da qualcun altro: una pagina web recuperata o un commento in un issue da risolvere. Questo secondo caso è chiamato prompt injection, ed è il motivo per cui "il modello è solitamente sensato" non è un piano di sicurezza. Devi pianificare per l'esecuzione errata, non per quella media.

Il sistema di permessi spiegato semplicemente

Di default, Claude Code chiede il permesso prima di agire. La lettura dei file all'interno del progetto avviene silenziosamente, ma la modifica di un file o l'esecuzione di un comando shell mostra prima l'esatta modifica o il comando e attende una conferma. Puoi approvare una singola azione o approvare quel tipo di azione per il resto della sessione. Queste approvazioni sono limitate alla sessione: chiudi la CLI e la sessione successiva ripartirà con cautela. Per le regole che vuoi mantenere, il file di impostazioni contiene liste persistenti di allow, ask e deny. Ad esempio: allow git status, ask su git push, deny letture di .env. Le regole di deny hanno sempre la precedenza.

Questo design presuppone che un essere umano stia monitorando il terminale, il che è vero su un laptop. Su un server, il punto è spesso che nessuno sta monitorando. Inizi un task lungo dentro tmux e vai a dormire; un agente che si ferma per fare una domanda alle 2:00 del mattino non farà progressi fino al mattino. La pausa costa tempo e denaro, perché una sessione di Claude Code inattiva perde la sua cache del prompt e il turno successivo deve pagare per ricostruirla. Questo è il motivo reale per cui si ricorre al flag di skip sui server, e il problema che risolve è reale. Il resto di questa guida riguarda come risolverlo senza rinunciare a ogni protezione.

Cosa cambia con --dangerously-skip-permissions

claude --dangerously-skip-permissions disattiva il passaggio di approvazione. Le modifiche avvengono senza prompt. I comandi shell vengono eseguiti senza prompt. Anche i controlli sui protected-path che normalmente proteggono le posizioni sensibili vengono saltati. Le tue regole di deny esplicite si applicano ancora e alcune azioni estreme si fermano comunque per chiedere, ma il riassunto è semplice: qualsiasi cosa il modello decida di eseguire, viene eseguita.

Due fatti sul flag sono importanti su un server. Primo, il flag è bloccato quando Claude Code viene eseguito come root o tramite sudo su Linux e macOS, perché root senza prompt può modificare qualsiasi file o servizio sulla macchina. L'agente necessita comunque di un proprio account non privilegiato, e il flag impone questo limite. Secondo, il flag non cambia in alcun modo il comportamento del modello. Rimuove l'essere umano dal ciclo e non cambia nient'altro, quindi ogni errore che un prompt avrebbe intercettato viene ora eseguito.

Ecco il calcolo onesto. Se salti i permessi, la domanda di sicurezza passa da "l'agente farà qualcosa di sbagliato" a "quanto danno può fare una singola azione errata". Smetti di cercare di controllare ogni decisione e inizia a controllare il raggio d'azione (blast radius). Il contenimento è la soluzione, e si sviluppa per livelli.

Il sandbox integrato di Claude Code

Prima dei livelli, sappi che Claude Code include ora un sandbox a livello di sistema operativo per i comandi che esegue, eliminando la maggior parte dei motivi per cui si usava il flag di skip. Su Linux utilizza bubblewrap per l'isolamento del filesystem, più socat per instradare il traffico di rete tramite un proxy. All'interno del sandbox, un comando può scrivere solo nella directory del progetto e in una directory temporanea della sessione, e può raggiungere la rete solo tramite un proxy che verifica ogni dominio contro una allow list. La prima volta che un comando richiede un nuovo dominio, Claude Code te lo chiede.

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 predefinita di AppArmor impedisce a bubblewrap di creare i namespace utente necessari. Il pannello del sandbox ti avvisa quando manca qualcosa, e la documentazione del sandboxing di Claude Code contiene il profilo AppArmor breve per risolvere il problema.

Il sandbox ha una modalità auto-allow: i comandi sandboxed vengono eseguiti senza prompt, perché il confine imposto ora svolge il lavoro che prima faceva il prompt. I comandi che non possono essere eseguiti nel sandbox tornano al normale flusso di permessi, quindi le azioni realmente insolite chiedono comunque l'autorizzazione. Per la maggior parte dei workflow su server, questa è la sostituzione corretta per il flag di skip, perché ricevi molte meno domande grazie a un confine imposto dal sistema operativo invece di nessuna.

Sii onesto riguardo ai suoi limiti. Di default, un comando sandboxed può ancora leggere la maggior parte del filesystem, inclusi i file delle credenziali, a meno che tu non neghi quei percorsi; l'impostazione sandbox.credentials esiste esattamente per questo. Il proxy di rete controlla i nomi dei domini e non ispeziona il traffico stesso, quindi un allow ampio come github.com lascia comunque spazio per esportare dati. Docker non funziona al suo interno. Il sandbox alza notevolmente l'asticella della sicurezza. Non è un confine di isolamento completo, motivo per cui i livelli sottostanti rimangono importanti.

La scala del contenimento

Tre livelli, in ordine crescente di isolamento. Scegli il più basso che si adatti a ciò che è già presente sulla macchina.

Livello 1: un utente dedicato non privilegiato. L'agente ottiene il proprio account, la propria home directory, la propria directory di progetto e nessun accesso sudo:

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

Il confine dell'account mantiene l'agente lontano dai tuoi file: le tue chiavi SSH e ogni altro progetto sulla macchina. Rende inoltre utilizzabile il flag di skip, poiché il flag rifiuta di eseguire come root. Questo è lo stesso principio di eseguire ogni servizio come utente non privilegiato, applicato a un agente. Ciò che il livello 1 non limita: la rete e qualsiasi cosa sulla macchina sia leggibile da tutti (world-readable).

Livello 2: un container. Anthropic pubblica un devcontainer di riferimento che esegue Claude Code come utente non root, con regole firewall che limitano i host raggiungibili dall'agente; un container costruito da te svolge lo stesso compito. Il filesystem si riduce ai volumi montati e l'uscita (egress) si riduce a ciò che le regole del container permettono. Questo è il livello intermedio corretto quando il server ospita altri servizi importanti. Il suo limite è che i container condividono il kernel dell'host e un mount errato annulla il confine; consegna al container /var/run/docker.sock e potrà raggiungere l'intero host.

Livello 3: un VPS dedicato. Il livello più forte è il più drastico: dai all'agente un'intera macchina che non contenga nulla di importante per te. Un piccolo VPS costa pochi dollari al mese. Configuralo con il runbook dei primi dieci minuti su un nuovo VPS, scatta uno snapshot dello stato pulito e lascia lavorare l'agente. Niente altro vive lì. Nessuna chiave SSH personale, solo una deploy key limitata a un singolo repository. Nessuna credenziale cloud, nessun dato di produzione. Se un'esecuzione fallisce, o se vuoi semplicemente ricominciare da capo, ripristina lo snapshot o distruggi e ricostruisci la macchina in pochi minuti. Il raggio d'azione è il costo dell'affitto. Questo è il setup in cui --dangerously-skip-permissions smette di essere spaventoso, perché il peggior risultato realistico è un server ricostruito e un token revocato.

I livelli si sommano. Un agente sandboxed, eseguito come utente non privilegiato, su un VPS usa e getta, non costa quasi nulla in più e rende le storie di fallimento noiose. La noia è l'obiettivo.

Proteggi le credenziali

La regola che compensa tutto il resto: l'utente dell'agente non deve poter leggere segreti appartenenti a qualcos'altro.

Assegna la chiave API all'agente e a nient'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'altra direzione. Su Debian e Ubuntu, le home directory sono spesso create leggibili da ogni utente sulla macchina, quindi stringi la tua: chmod 750 /home/youruser. Verifica con ls -ld /home/* e correggi tutto ciò che l'account dell'agente può elencare.

Limita ogni token. Un token GitHub granulare limitato a un singolo repository, o una deploy key per repository, significa che una credenziale compromessa perde un solo progetto e non l'intero account. Se usi il sandbox, aggiungi le sue impostazioni per le credenziali in modo che ~/.ssh e ~/.aws siano negati anche per le letture. E tieni le credenziali di produzione completamente fuori dalla macchina, perché un agente non può esporre un segreto che non è mai stato lì.

Git è la rete di sicurezza

Ogni modifica effettuata dall'agente deve essere revisionabile e annullabile, e git ti offre entrambe le cose gratuitamente se l'agente lavora su un branch:

git switch -c agent/refactor-auth

Revisiona l'esecuzione successivamente con git diff main...agent/refactor-auth, unisci ciò che è corretto e cancella il branch se l'esecuzione non ha portato a nulla. Proteggi il branch main sul fornitore (forge), in modo che il token dell'agente non possa fare push su di esso e non possa fare force-push ovunque. La cronologia dei commit funge anche da log di audit di ciò che è accaduto mentre dormivi, il che vale più di qualsiasi log del terminale.

La rete fa parte del raggio d'azione

Un agente può eseguire curl. Questa frase riassume tutto il problema dell'egress: tutto ciò che l'agente può leggere, può anche inviarlo da qualche parte, e un agente vittima di prompt injection potrebbe farlo. Un semplice utente non privilegiato non limita affatto questo, poiché qualsiasi utente può raggiungere tutto ciò che il server può raggiungere. Il sandbox lo limita per dominio tramite il suo proxy. Un container può limitarlo con le proprie regole firewall. Un VPS dedicato limita ciò che può essere esposto fin dall'inizio, che è la risposta più robusta tra le tre.

Non cercare di risolvere l'egress solo con ufw. ufw permette tutto il traffico in uscita di default, e scrivere regole in uscita che permettano ancora apt, npm, git e l'API di Claude è un lavoro complicato che si rompe silenziosamente. Scegli invece il confine a livello di sandbox, container o macchina, dove una allow list di domini o una macchina dedicata svolgono lo stesso compito in modo pulito.

Se stai costruendo il tuo agente tramite API invece di eseguire Claude Code, lo stesso ragionamento si applica invariato. Costruire un agente AI con Claude su un VPS copre questo percorso, e il suo agente merita lo stesso utente dedicato, gli stessi token limitati e la stessa macchina usa e getta.

Rafforza la macchina per prima

Qualunque livello tu scelga, la macchina stessa ha comunque bisogno delle basi prima che l'agente venga installato: solo chiavi SSH, nessun login root, un firewall con deny di default, aggiornamenti di sicurezza automatici. Genera la tua checklist qui e seguila una volta sola:

FAQ

L'uso di --dangerously-skip-permissions è sicuro su un server?

Non da solo. Il flag rimuove ogni prompt di approvazione, quindi il primo comando errato viene eseguito nel momento stesso in cui il modello lo genera. Diventa un compromesso difendibile quando il raggio d'azione è contenuto: un utente dedicato non privilegiato come minimo, e per lavoro unattended un container o un VPS usa e getta che contenga un solo progetto e un solo token limitato. Non usarlo mai su una macchina che contiene credenziali di produzione o dati che non puoi perdere.

Claude Code ha un sandbox?

Sì. Claude Code include un sandbox integrato per i comandi shell, attivabile con il comando /sandbox. Utilizza bubblewrap su Linux e Seatbelt su macOS, limita le scritture alla directory del progetto e instrada l'accesso alla rete tramite un proxy che permette solo domini approvati. La sua modalità auto-allow esegue i comandi sandboxed senza prompt, riducendo le interruzioni come fa il flag di skip, pur mantenendo un confine imposto dal sistema operativo. Non è un confine di isolamento completo, quindi abbinalo a un utente dedicato o a una macchina dedicata per le esecuzioni unattended.

Perché il flag di skip rifiuta di eseguire come root?

Perché root, senza prompt di autorizzazione, può modificare qualsiasi file e qualsiasi servizio sul sistema; Claude Code blocca --dangerously-skip-permissions quando viene eseguito come root o tramite sudo su Linux e macOS. La soluzione non è combattere il controllo. Crea un utente non privilegiato per l'agente ed eseguilo lì; quel confine dell'account è il primo e più economico livello di contenimento.

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

Può leggere tutto ciò che l'utente sotto cui viene eseguito può leggere, e persino la policy predefinita del sandbox permette la lettura di percorsi di credenziali finché non li neghi. Quindi esegui l'agente come un utente dedicato, mantieni la tua home directory con modalità 750 o più restrittiva, nega i percorsi delle credenziali nelle impostazioni del sandbox e tieni i segreti di produzione completamente fuori dalla macchina. Un segreto che la macchina non ha mai ospitato non può essere letto o esposto.

Qual è il modo più sicuro per eseguire Claude Code in modalità unattended?

Un VPS dedicato economico usato solo per il lavoro dell'agente: rafforzato in dieci minuti, con snapshot pulito, eseguendo Claude Code sotto un utente non privilegiato con il sandbox attivo, un file con modalità 600 che contiene la chiave API, una deploy key per repository e tutto il lavoro su branch da revisionare prima del merge. Se un'esecuzione fallisce, revochi un solo token e ripristini lo snapshot, e nient'altro di ciò che possiedi ne risentirà.