Claude Code veilig draaien op een server

Wat het veilig draaien van Claude Code op een server betekent

Om Claude Code veilig op een server te draaien, moet u de toestemmingsprompts aan laten staan, het uitvoeren als een toegewezen onbevoegde gebruiker, en onbeheerde runs een echte grens geven in plaats van vertrouwen: de ingebouwde sandbox, een container, of een tijdelijke VPS zonder belangrijke gegevens. De --dangerously-skip-permissions flag verwijdert de goedkeuringsstap tussen het model en uw shell. Deze ruil kan redelijk zijn voor onbeheerd werk, maar alleen binnen een grens die beperkt wat één foutief commando kan bereiken. Deze gids legt uit wat de flag precies verandert en hoe u die grens opbouwt in stappen met toenemende isolatie.

Wat Claude Code kan doen op uw systeem

Claude Code is een coding agent die in uw terminal draait. Het leest bestanden, schrijft bestanden en voert shell commands uit als de gebruiker die het gestart heeft. Dat is de volledige waarde van de tool: het kan een repository clonen, code bewerken, tests uitvoeren, de fout lezen en de code in een loop repareren, zonder dat u elk commando typt. Als u het nog niet op een server heeft ingesteld, behandelt het draaien van Claude Code op een VPS met tmux de installatie en de sessiebehandeling. Deze pagina behandelt de macht die u het geeft zodra het daar is.

Het risico is hetzelfde scenario dat u een tweede keer leest. Een proces dat shell commands uitvoert als uw gebruiker, kan alles doen wat uw gebruiker kan doen. Het kan ~/.ssh/id_ed25519, ~/.aws/credentials en elk .env bestand lezen dat uw gebruiker kan openen. Het kan curl uitvoeren en data verzenden naar elke host die de server kan bereiken. Het kan git push --force uitvoeren. De agent heeft geen eigen motief. Het gevaar is dat een taak misgaat, of dat de tekst die het las tijdens het werk instructies bevatte geschreven door iemand anders: een webpagina die het ophaalde, of een commentaar in een issue dat het moest repareren. Dat tweede geval wordt prompt injection genoemd, en dat is waarom "het model is meestal verstandig" geen beveiligingsplan is. U plant voor de foutieve run, niet voor de gemiddelde run.

Het permissiesysteem in eenvoudige woorden

Standaard vraagt Claude Code om toestemming voordat het handelt. Het lezen van bestanden binnen het project gebeurt stilzwijgend, maar het bewerken van een bestand of het uitvoeren van een shell command laat u eerst de exacte bewerking of het commando zien en wacht op een bevestiging. U kunt één actie goedkeuren, of dat type actie goedkeuren voor de rest van de sessie. Deze goedkeuringen zijn sessie-gebonden: sluit de CLI af en de volgende sessie start weer voorzichtig. Voor regels die u wilt behouden, bevat het instellingenbestand persistente allow, ask, en deny lijsten. Bijvoorbeeld: allow git status, ask op git push, deny reads van .env. Deny regels winnen altijd.

Dit ontwerp gaat ervan uit dat een mens de terminal in de gaten houdt, wat op een laptop waar is. Op een server is het punt vaak dat niemand kijkt. U start een lange taak in tmux en gaat slapen, en een agent die om 2 uur 's nachts stopt om een vraag te stellen, maakt geen progressie tot de ochtend. De pauze kost zowel geld als tijd, omdat een inactieve Claude Code sessie zijn warme prompt cache verliest en de volgende beurt betaalt om deze opnieuw op te bouwen. Dat is de eerlijke reden waarom mensen op servers voor de skip flag kiezen, en het probleem dat het oplost is reëel. De rest van deze gids gaat over het oplossen ervan zonder alle beveiligingsmaatregelen op te geven.

Wat --dangerously-skip-permissions verandert

claude --dangerously-skip-permissions schakelt de goedkeuringsstap uit. Bewerkingen vinden plaats zonder prompt. Shell commands worden uitgevoerd zonder prompt. De protected-path checks die normaal gesproken gevoelige locaties bewaken, worden ook overgeslagen. Uw expliciete deny regels blijven van toepassing, en enkele extreme acties stoppen nog steeds om te vragen, maar de samenvatting is simpel: wat het model ook besluit uit te voeren, wordt uitgevoerd.

Twee feiten over de flag zijn belangrijk op een server. Ten eerste wordt deze geblokkeerd wanneer Claude Code draait als root of onder sudo op Linux en macOS, omdat root zonder prompts elk bestand of elke service op de machine kan wijzigen. De agent heeft sowieso zijn eigen onbevoegde account nodig, en de flag dwingt dit af. Ten tweede verandert de flag het gedrag van het model op geen enkele manier. Het verwijdert de mens uit de loop en verandert verder niets, dus elke fout die een prompt zou hebben opgevangen, wordt nu uitgevoerd.

Dit is de eerlijke calculus. Als u permissies overslaat, verandert de beveiligingsvraag van "zal de agent iets slechts doen" naar "hoeveel schade kan één slechte actie aanrichten". U stopt met het proberen te controleren van elke beslissing en begint de blast radius te controleren. Containment is het antwoord, en dat komt in stappen.

De ingebouwde Claude Code sandbox

Voordat we naar de stappen kijken: weet dat Claude Code nu een OS-level sandbox levert voor de commands die het uitvoert, en het verwijdert de meeste redenen waarom mensen naar de skip flag grepen. Op Linux gebruikt het bubblewrap voor filesystem isolatie, plus socat om netwerkverkeer via een proxy te routeren. Binnen de sandbox kan een command alleen schrijven naar de project directory en een sessie temp directory, en kan het alleen bij het netwerk via een proxy die elke domain controleert tegen een allow list. De eerste keer dat een command een nieuwe domain wil, vraagt Claude Code het u.

Zet het aan met het /sandbox commando binnen een sessie. Installeer op Ubuntu en Debian eerst de twee benodigde packages:

sudo apt install bubblewrap socat

Op Ubuntu 24.04 en later stopt het standaard AppArmor policy ervoor dat bubblewrap de benodigde user namespaces aanmaakt. Het sandbox paneel vertelt u wanneer er iets ontbreekt, en de Claude Code sandboxing documentatie bevat het korte AppArmor profile dat dit oplost.

De sandbox heeft een auto-allow mode: sandboxed commands draaien zonder enige prompt, omdat de afgedwongen grens nu het werk doet dat de prompt vroeger deed. Commands die niet binnen de sandbox kunnen draaien, vallen terug op de normale permissie flow, dus de echt ongebruikelijke acties vragen nog steeds om toestemming. Voor de meeste server workflows is dit de juiste vervanging voor de skip flag, omdat u veel minder vragen krijgt met een OS-enforced grens in plaats van helemaal niets.

Wees eerlijk over de limieten. Standaard kan een sandboxed command nog steeds het grootste deel van het filesystem lezen, inclusief credential files, tenzij u die paths weigert; de sandbox.credentials setting bestaat precies daarvoor. De netwerk proxy controleert domain names en inspecteert het verkeer zelf niet, dus een brede allow zoals github.com laat nog steeds ruimte om data te exporteren. Docker werkt niet binnen de sandbox. De sandbox verhoogt de basisveiligheid aanzienlijk. Het is geen volledige isolatiegrens, wat de reden is dat de onderstaande stappen nog steeds belangrijk zijn.

De containment ladder

Drie stappen, in stijgende volgorde van isolatie. Kies de laagste stap die past bij wat er verder nog op de machine staat.

Stap 1: een toegewezen onbevoegde gebruiker. De agent krijgt zijn eigen account, zijn eigen home directory, zijn eigen project directory, en geen sudo:

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

De account grens houdt de agent buiten uw bestanden: uw SSH keys en elk ander project op de machine. Het maakt de skip flag ook überhaupt bruikbaar, aangezien de flag weigert te draaien als root. Dit is hetzelfde principe als elke service draaien als een onbevoegde gebruiker, toegepast op een agent. Wat stap 1 niet begrenst: het netwerk, en alles op de machine dat wereldwijd leesbaar is.

Stap 2: een container. Anthropic publiceert een referentie devcontainer die Claude Code draait als een non-root gebruiker, met firewall rules die beperken welke hosts de agent kan bereiken; een container die u zelf bouwt doet hetzelfde werk. Het filesystem krimpt tot de volumes die u mount, en egress krimpt tot wat de rules van de container toelaten. Dit is de juiste middelste stap wanneer de server andere services host die u belangrijk vindt. De limiet is dat containers de host kernel delen, en één onvoorzichtige mount de grens ongedaan maakt; geef de container /var/run/docker.sock en hij kan de hele host bereiken.

Stap 3: een toegewezen VPS. De sterkste stap is de meest directe: geef de agent een volledige machine die niets bevat wat u belangrijk vindt. Een kleine VPS kost een paar dollar per maand. Richt deze in met de eerste tien minuten op een nieuwe VPS runbook, maak een snapshot van de schone staat, en laat de agent werken. Er leeft niets anders op. Geen persoonlijke SSH key, alleen een deploy key beperkt tot de ene repository. Geen cloud credentials, geen productie data. Als een run misgaat, of als u simpelweg een schone lei wilt, herstel dan de snapshot of vernietig en herbouw de machine in minuten. De blast radius is de huurprijs. Dit is de setup waar --dangerously-skip-permissions niet langer beangstigend is, omdat het slechtste realistische resultaat een herbouwde server en één ingetrokken token is.

De stappen stapelen zich op. Een sandboxed agent, draaiend als een onbevoegde gebruiker, op een tijdelijke VPS, kost bijna niets extra en maakt de failure stories saai. Saai is het doel.

Bescherm de credentials

De regel die alles betaalt: de gebruiker van de agent mag geen secrets kunnen lezen die bij iets anders horen.

Geef de API key aan de agent en aan niets anders. Plaats deze in een bestand dat eigendom is van de gebruiker van de agent met mode 600, en laad deze wanneer een shell start:

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

Sluit daarna de andere kant af. Op Debian en Ubuntu zijn home directories vaak leesbaar voor elke gebruiker op de machine, dus verstevig uw eigen: chmod 750 /home/youruser. Controleer met ls -ld /home/* en herstel alles wat het account van de agent kan opsommen.

Beperk elk token. Een fijnmazer GitHub token beperkt tot één repository, of een per-repository deploy key, betekent dat een gelekt credential slechts één project verliest en niet uw hele account. Als u de sandbox gebruikt, voeg dan de credential settings toe zodat ~/.ssh en ~/.aws zelfs voor reads worden geweigerd. En houd productie credentials volledig buiten de machine, want een agent kan geen secret lekken dat er nooit was.

Git is het vangnet

Elke wijziging die de agent maakt moet controleerbaar en ongedaan te maken zijn, en git biedt u beide gratis als de agent op een branch werkt:

git switch -c agent/refactor-auth

Controleer de run achteraf met git diff main...agent/refactor-auth, merge wat goed is, en verwijder de branch als de run nergens toe leidde. Bescherm de main branch aan de forge-zijde, zodat de token van de agent er niet naar kan pushen en nergens een force-push kan doen. De commit history dient tevens als een audit log van wat er gebeurde terwijl u sliep, wat meer waard is dan welke hoeveelheid terminal scrollback dan ook.

Het netwerk is onderdeel van de blast radius

Een agent kan curl uitvoeren. Die zin is het hele egress probleem: wat de agent ook kan lezen, hij kan het ook ergens naartoe sturen, en een prompt-injected agent zou dat kunnen doen. Een gewone onbevoegde gebruiker begrenst dit helemaal niet, omdat elke gebruiker alles kan bereiken wat de server kan bereiken. De sandbox begrenst dit per domain via zijn proxy. Een container kan dit begrenzen met zijn eigen firewall rules. Een toegewezen VPS begrenst wat er überhaupt is om te lekken, wat het meest robuuste antwoord van de drie is.

Probeer egress niet alleen met ufw op te lossen. ufw staat standaard alle uitgaande verkeer toe, en het schrijven van outbound rules die nog steeds apt, npm, git, en de Claude API toestaan, is handig werk dat stilletjes kapot gaat. Kies in plaats daarvan voor de grens op sandbox-, container- of machineregel, waar een domain allow list of een kale machine hetzelfde werk netjes doet.

Als u uw eigen agent bouwt tegen de API in plaats van Claude Code te draaien, geldt dezelfde logica ongewijzigd. Een AI agent bouwen met Claude op een VPS behandelt dat pad, en die agent verdient dezelfde toegewezen gebruiker, dezelfde beperkte tokens, en dezelfde tijdelijke machine.

Versterk de machine eerst

Welke stap u ook kiest, de machine zelf heeft nog de basis nodig voordat de agent intrekt: alleen SSH keys, geen root login, een default-deny firewall, automatische security updates. Genereer uw checklist hier en werk deze eenmalig af:

FAQ

Is --dangerously-skip-permissions veilig te gebruiken op een server?

Niet op zichzelf. De flag verwijdert elke goedkeuringsprompt, dus de eerste foutieve command wordt uitgevoerd op het moment dat het model deze genereert. Het wordt een verdedigbare ruil wanneer de blast radius is begrensd: minimaal een toegewezen onbevoegde gebruiker, en voor echt onbeheerd werk een container of een tijdelijke VPS die één project en één beperkt token bevat. Gebruik het nooit op een machine die productie credentials of data bevat die u niet kunt verliezen.

Heeft Claude Code een sandbox?

Ja. Claude Code levert een ingebouwde sandbox voor shell commands, geopend met het /sandbox commando. Het gebruikt bubblewrap op Linux en Seatbelt op macOS, beperkt schrijfacties tot de project directory, en routeert netwerktoegang via een proxy die alleen goedgekeurde domains toestaat. De auto-allow mode voert sandboxed commands uit zonder prompts, waardoor het onderbrekingen vermindert zoals de skip flag dat doet, terwijl het een OS-enforced grens behoudt. Het is geen volledige isolatiegrens, dus combineer het met een toegewezen gebruiker of een toegewezen machine voor onbeheerde runs.

Waarom weigert de skip flag om als root te draaien?

Omdat root zonder permissie prompts elk bestand en elke service op het systeem kan wijzigen, blokkeert Claude Code --dangerously-skip-permissions wanneer het als root of onder sudo draait op Linux en macOS. De oplossing is niet om tegen de check te vechten. Maak een onbevoegde gebruiker aan voor de agent en draai hem daar; die account grens is de eerste en goedkoopste laag van containment.

Kan Claude Code mijn SSH keys en .env bestanden lezen?

Het kan lezen wat de gebruiker die het uitvoert kan lezen, en zelfs het standaard beleid van de sandbox staat het lezen van credential paths toe totdat u deze weigert. Draai de agent dus als zijn eigen gebruiker, houd uw eigen home directory op mode 750 of strikter, weiger credential paths in de sandbox settings, en houd productie secrets volledig buiten de machine. Een secret dat de machine nooit heeft bevat, kan niet worden gelezen of gelekt.

Wat is de veiligste manier om Claude Code onbeheerd te draaien?

Een goedkope toegewezen VPS die u alleen voor agent werk gebruikt: in tien minuten versterkt, een schone snapshot, draaiend als een onbevoegde gebruiker met de sandbox aan, een mode-600 bestand met de API key, een per-repository deploy key, en al het werk op branches die u controleert voordat u merget. Als een run misgaat, herroept u één token en herstelt u de snapshot, en is niets anders wat u bezit aangetast.