Claude Code sicher auf einem Server betreiben

Was es bedeutet, Claude Code sicher auf einem Server zu betreiben

Damit Claude Code sicher auf einem Server ausgeführt wird, müssen die Berechtigungsabfragen aktiviert bleiben. Führen Sie Claude Code als dedizierten Benutzer ohne privilegierte Rechte aus. Geben Sie unbeaufsichtigten Ausführungen außerdem eine echte Begrenzung statt bloß Vertrauen: Verwenden Sie die integrierte Sandbox, einen Container oder einen temporären VPS, auf dem sich keine wichtigen Daten befinden. Das Flag --dangerously-skip-permissions entfernt die Bestätigung zwischen dem Modell und Ihrer Shell. Dieser Kompromiss kann für unbeaufsichtigte Aufgaben vertretbar sein, aber nur innerhalb einer Begrenzung, die einschränkt, welche Ressourcen ein fehlerhafter Befehl erreichen kann. Dieser Leitfaden erklärt, was das Flag tatsächlich ändert und wie Sie diese Begrenzung mit zunehmender Isolation stufenweise aufbauen.

Was Claude Code auf Ihrem System tun kann

Claude Code ist ein Coding-Agent, der in Ihrem Terminal ausgeführt wird. Er liest Dateien, schreibt Dateien und führt Shell-Befehle mit den Rechten des Benutzers aus, der ihn gestartet hat. Darin liegt der gesamte Nutzen des Tools: Es kann ein Repository klonen, Code bearbeiten, Tests ausführen, den Fehler lesen und den Code in einer Schleife korrigieren, ohne dass Sie jeden Befehl eingeben müssen. Wenn Sie Claude Code noch nicht auf einem Server eingerichtet haben, behandelt Claude Code auf einem VPS mit tmux ausführen die Installation und die Verwaltung der Sitzung. Diese Seite beschreibt die Rechte, die Sie ihm damit übertragen.

Das Risiko ergibt sich aus demselben Satz, wenn man ihn ein zweites Mal liest. Ein Prozess, der Shell-Befehle mit Ihren Benutzerrechten ausführt, kann alles tun, was Sie tun können. Er kann ~/.ssh/id_ed25519, ~/.aws/credentials und jede .env-Datei lesen, auf die Ihr Benutzer zugreifen kann. Er kann curl ausführen und Daten an jeden Host senden, den der Server erreichen kann. Er kann git push --force ausführen. Der Agent hat keine eigenen Motive. Die Gefahr besteht darin, dass eine Aufgabe fehlschlägt oder dass der Text, den er während der Arbeit liest, Anweisungen enthält, die von einer anderen Person stammen: etwa eine abgerufene Webseite oder ein Kommentar in einem Issue, das er bearbeiten soll. Dieser zweite Fall wird als Prompt Injection bezeichnet. Deshalb ist die Annahme, dass „das Modell normalerweise vernünftig handelt“, kein Sicherheitskonzept. Anweisungen können auch aus der näheren Umgebung kommen, weil zwei Claude-Code-Sitzungen auf demselben System einander Text senden können und eine Nachricht aus einer anderen Sitzung für den empfangenden Agenten lediglich weiterer gelesener Text ist. Planen Sie für den problematischen Lauf, nicht für den durchschnittlichen.

Das Berechtigungssystem in einfachen Worten

Standardmäßig fragt Claude Code nach, bevor es Aktionen ausführt. Dateien innerhalb des Projekts werden still gelesen. Beim Bearbeiten einer Datei oder beim Ausführen eines Shell-Befehls zeigt Claude Code jedoch zuerst die genaue Änderung oder den genauen Befehl an und wartet auf Ihre Bestätigung. Sie können eine einzelne Aktion genehmigen oder diese Art von Aktion für den Rest der Sitzung genehmigen. Diese Genehmigungen gelten nur für die Sitzung: Wenn Sie die CLI beenden, startet die nächste Sitzung wieder mit vorsichtigen Standardeinstellungen. Für Regeln, die dauerhaft gelten sollen, enthält die Einstellungsdatei persistente Listen für allow, ask und deny. Beispiel: allow für git status, ask für git push und Lesezugriffe auf .env mit deny ablehnen. deny-Regeln haben immer Vorrang. Diese Ausgangslage ändert sich ebenfalls, da der automatische Modus am 14. August 2026 zum Standard wird. Daher sollten Sie wissen, was die einzelnen Berechtigungsmodi tatsächlich erlauben, bevor Sie entscheiden, welchen Modus ein Server verwenden soll, den Sie nicht überwachen können.

Dieses Design setzt voraus, dass ein Mensch das Terminal überwacht. Auf einem Laptop ist das normalerweise der Fall. Auf einem Server besteht der Zweck jedoch häufig gerade darin, dass niemand zusieht. Sie starten eine lange Aufgabe in tmux und gehen schlafen. Wenn ein Agent dann um 2 Uhr nachts eine Frage stellt, macht er bis zum Morgen keine Fortschritte. Diese Unterbrechung kostet nicht nur Zeit, sondern auch Geld, weil eine inaktive Claude Code-Sitzung ihren warmen Prompt-Cache verliert und der nächste Durchlauf für dessen erneuten Aufbau bezahlt. Das ist der sachliche Grund, warum viele auf Servern zum Skip-Flag greifen. Das Problem, das es löst, ist real. Im weiteren Verlauf dieses Leitfadens geht es darum, dieses Problem zu lösen, ohne sämtliche Schutzmechanismen aufzugeben.

Was --dangerously-skip-permissions ändert

claude --dangerously-skip-permissions deaktiviert den Genehmigungsschritt. Änderungen werden ohne Rückfrage durchgeführt. Shell-Befehle werden ohne Rückfrage ausgeführt. Auch die Prüfungen geschützter Pfade, die normalerweise sensible Speicherorte schützen, werden übersprungen. Ihre expliziten Ablehnungsregeln gelten weiterhin, und einige besonders kritische Aktionen erfordern weiterhin eine Bestätigung. Die einfache Zusammenfassung lautet jedoch: Was das Modell auszuführen entscheidet, wird ausgeführt.

Bei einem Server sind zwei Fakten zu diesem Flag wichtig. Erstens ist es blockiert, wenn Claude Code unter Linux oder macOS als root oder über sudo ausgeführt wird, weil root ohne Rückfragen jede Datei und jeden Dienst auf dem System ändern kann. Der Agent benötigt ohnehin ein eigenes unprivilegiertes Konto, und das Flag erzwingt diese Voraussetzung. Zweitens ändert das Flag das Verhalten des Modells in keiner Weise. Es entfernt den Menschen aus der Kontrollschleife und ändert sonst nichts. Jeder Fehler, den eine Rückfrage verhindert hätte, wird nun ausgeführt.

Die Konsequenz ist daher eindeutig. Wenn Sie Berechtigungen überspringen, ändert sich die Sicherheitsfrage von „wird der Agent etwas Schädliches tun?“ zu „wie groß kann der Schaden durch eine einzige fehlerhafte Aktion werden?“. Sie versuchen nicht mehr, jede Entscheidung zu kontrollieren, sondern begrenzen den möglichen Schaden. Die Antwort ist Containment, und dafür gibt es mehrere Stufen.

Die integrierte Claude-Code-Sandbox

Bevor Sie die einzelnen Stufen durchgehen, sollten Sie wissen, dass Claude Code inzwischen eine Sandbox auf Betriebssystemebene für die ausgeführten Befehle bereitstellt. Dadurch entfallen die meisten Gründe, aus denen bisher das Skip-Flag verwendet wurde. Unter Linux verwendet sie bubblewrap zur Isolierung des Dateisystems und socat, um den Netzwerkverkehr über einen Proxy zu leiten. Innerhalb der Sandbox kann ein Befehl nur in das Projektverzeichnis und ein temporäres Sitzungsverzeichnis schreiben. Auf das Netzwerk kann er nur über einen Proxy zugreifen, der jede Domain gegen eine Allowlist prüft. Wenn ein Befehl erstmals auf eine neue Domain zugreifen möchte, fragt Claude Code Sie.

Aktivieren Sie die Sandbox innerhalb einer Sitzung mit dem Befehl /sandbox. Installieren Sie unter Ubuntu und Debian zunächst die beiden benötigten Pakete:

sudo apt install bubblewrap socat

Unter Ubuntu 24.04 und höher verhindert die standardmäßige AppArmor-Richtlinie, dass bubblewrap die benötigten User-Namespaces erstellt. Das Sandbox-Panel weist Sie darauf hin, wenn etwas fehlt. Die Dokumentation zur Claude-Code-Sandbox enthält das kurze AppArmor-Profil, das dieses Problem behebt.

Die Sandbox verfügt über einen Auto-Allow-Modus. Sandboxed ausgeführte Befehle laufen ohne Rückfrage, weil nun die erzwungene Begrenzung die Aufgabe übernimmt, die zuvor die Rückfrage erfüllt hat. Befehle, die nicht innerhalb der Sandbox ausgeführt werden können, fallen auf den normalen Berechtigungsablauf zurück. Dadurch werden ungewöhnliche Aktionen weiterhin abgefragt. Für die meisten Server-Workflows ist dies der richtige Ersatz für das Skip-Flag, weil Sie mit einer vom Betriebssystem erzwungenen Begrenzung deutlich weniger Rückfragen erhalten als ohne eine solche Begrenzung.

Seien Sie sich der Einschränkungen bewusst. Ein Befehl in der Sandbox kann standardmäßig weiterhin die meisten Dateien im Dateisystem lesen, einschließlich Dateien mit Zugangsdaten, sofern Sie diese Pfade nicht sperren. Genau dafür gibt es die Einstellung sandbox.credentials. Der Netzwerk-Proxy prüft Domainnamen, inspiziert den Datenverkehr selbst jedoch nicht. Eine weit gefasste Allow-Regel wie github.com lässt daher weiterhin Raum, Daten nach außen zu übertragen. Docker funktioniert innerhalb der Sandbox nicht. Die Sandbox erhöht das Sicherheitsniveau deutlich. Sie ist jedoch keine vollständige Isolationsgrenze. Deshalb bleiben die folgenden Stufen weiterhin relevant.

Die Containment-Leiter

Drei Stufen mit zunehmender Isolation. Wählen Sie die niedrigste Stufe, die dazu passt, welche anderen Dienste auf dem Server laufen.

Stufe 1: ein dedizierter Benutzer ohne Privilegien. Der Agent erhält ein eigenes Konto, ein eigenes Home-Verzeichnis, ein eigenes Projektverzeichnis und keinen sudo-Zugriff:

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

Die Kontogrenze hält den Agenten von Ihren Dateien fern: von Ihren SSH-Schlüsseln und von allen anderen Projekten auf dem Rechner. Außerdem wird das Überspringen-Flag dadurch überhaupt nutzbar, weil das Flag die Ausführung als root verweigert. Das ist dasselbe Prinzip wie jeden Dienst als Benutzer ohne Privilegien auszuführen, angewendet auf einen Agenten. Was Stufe 1 nicht begrenzt: das Netzwerk und alle weltweit lesbaren Daten auf dem Rechner.

Stufe 2: ein Container. Anthropic veröffentlicht einen Referenz-Devcontainer, der Claude Code als Benutzer ohne root-Rechte ausführt und mit Firewall-Regeln begrenzt, welche Hosts der Agent erreichen kann. Ein selbst erstellter Container erfüllt denselben Zweck. Das Dateisystem beschränkt sich auf die von Ihnen eingebundenen Volumes. Der ausgehende Datenverkehr beschränkt sich auf das, was die Regeln des Containers zulassen. Das ist die passende mittlere Stufe, wenn auf dem Server weitere wichtige Dienste laufen. Ihre Grenze besteht darin, dass Container den Kernel des Hosts gemeinsam verwenden. Eine unachtsame Einbindung hebt die Begrenzung auf; mit /var/run/docker.sock kann der Container den gesamten Host erreichen.

Stufe 3: ein dedizierter VPS. Die stärkste Stufe ist zugleich die grobste: Geben Sie dem Agenten einen vollständigen Rechner, auf dem sich nichts befindet, was Ihnen wichtig ist. Ein kleiner VPS kostet wenige Dollar pro Monat. Richten Sie ihn mit dem Runbook für die ersten zehn Minuten auf einem neuen VPS ein, erstellen Sie einen Snapshot des sauberen Zustands und lassen Sie den Agenten arbeiten. Dort läuft nichts anderes. Kein persönlicher SSH-Schlüssel, sondern nur ein Deploy-Schlüssel mit Berechtigung für das eine Repository. Keine Cloud-Zugangsdaten und keine Produktionsdaten. Wenn ein Lauf fehlschlägt oder Sie einfach einen sauberen Ausgangszustand benötigen, stellen Sie den Snapshot wieder her oder löschen Sie den Server und erstellen ihn innerhalb weniger Minuten neu. Der mögliche Schadensumfang beschränkt sich auf die Miete. In dieser Konfiguration wirkt --dangerously-skip-permissions nicht mehr beängstigend, weil das schlimmste realistische Ergebnis ein neu erstellter Server und ein widerrufenes Token ist.

Die Stufen lassen sich kombinieren. Ein isolierter Agent, der als Benutzer ohne Privilegien auf einem nur vorübergehend verwendeten VPS läuft, verursacht kaum zusätzliche Kosten und macht die Fehlerfolgen unspektakulär. Unspektakulär ist das Ziel.

Anmeldedaten schützen

Die wichtigste Regel für alle weiteren Maßnahmen lautet: Der Benutzer des Agenten darf keine Secrets lesen können, die zu anderen Komponenten gehören.

Geben Sie den API-Schlüssel ausschließlich dem Agenten. Legen Sie ihn in einer Datei ab, die dem Benutzer des Agenten gehört und den Modus 600 hat. Laden Sie ihn beim Start einer 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

Sperren Sie anschließend den Zugriff in die andere Richtung. Unter Debian und Ubuntu werden Home-Verzeichnisse häufig so angelegt, dass jeder Benutzer des Systems sie lesen kann. Schränken Sie daher die Berechtigungen Ihres eigenen Home-Verzeichnisses ein: chmod 750 /home/youruser. Prüfen Sie das Ergebnis mit ls -ld /home/* und korrigieren Sie alles, was das Konto des Agenten auflisten kann.

Beschränken Sie jedes Token auf den kleinstmöglichen Geltungsbereich. Ein fein abgestuftes GitHub-Token, das auf ein einzelnes Repository begrenzt ist, oder ein Deploy Key pro Repository sorgt dafür, dass ein offengelegtes Zugangstoken nur ein Projekt und nicht Ihr gesamtes Konto gefährdet. Wenn Sie die Sandbox verwenden, ergänzen Sie deren Einstellungen für Zugangsdaten, sodass ~/.ssh und ~/.aws auch bei Lesezugriffen verweigert werden. Halten Sie Produktionszugangsdaten vollständig von diesem System fern. Ein Agent kann kein Secret offenlegen, das nie auf dem System vorhanden war. Wenn diese Secrets in einem selbst gehosteten Passwortmanager gespeichert sind, betreiben Sie ihn auf einem anderen System als den Agenten und prüfen Sie ihn separat. Die Schwachstellen von Vaultwarden liegen beim Admin-Token und bei der Backup-Datei, nicht im verschlüsselten Vault selbst.

Git ist das Sicherheitsnetz

Jede Änderung des Agenten sollte überprüfbar und rückgängig zu machen sein. Git bietet beides kostenlos, wenn der Agent auf einem Branch arbeitet:

git switch -c agent/refactor-auth

Prüfen Sie den Lauf anschließend mit git diff main...agent/refactor-auth. Übernehmen Sie die guten Änderungen und löschen Sie den Branch, wenn der Lauf zu keinem Ergebnis geführt hat. Ein Lauf, der drei Dateien geändert hat, ist beim Frühstück wesentlich leichter zu lesen als einer, der das halbe Modul neu geschrieben hat. Genau dafür eignet sich eine Fähigkeit, die den Agenten auf die kleinste funktionierende Änderung festlegt. Schützen Sie den main-Branch auf der Forge-Seite. Dadurch kann das Token des Agenten weder dorthin pushen noch irgendwo einen Force-Push ausführen. Die Commit-Historie dient zusätzlich als Audit-Log der Vorgänge, während Sie geschlafen haben. Das ist wertvoller als jede noch so lange Terminalausgabe.

Das Netzwerk gehört zum Schadensradius

Ein Agent kann curl ausführen. Dieser Satz beschreibt das gesamte Egress-Problem: Alles, was der Agent lesen kann, kann er auch an einen anderen Ort senden, und ein per Prompt injizierter Agent könnte das tun. Ein normaler Benutzer ohne privilegierte Rechte begrenzt dies überhaupt nicht, weil jeder Benutzer alles erreichen kann, was der Server erreichen kann. Die Sandbox begrenzt den Zugriff über ihre Proxy-Konfiguration auf bestimmte Domains. Ein Container kann den Zugriff mit eigenen Firewall-Regeln begrenzen. Ein dedizierter VPS begrenzt bereits, welche Daten überhaupt nach außen gelangen können. Das ist die robusteste der drei Lösungen.

Versuchen Sie nicht, Egress allein mit ufw zu lösen. ufw erlaubt ausgehenden Datenverkehr standardmäßig vollständig. Ausgehende Regeln zu schreiben, die apt, npm, git und die Claude API weiterhin zulassen, ist fehleranfällig und aufwendig. Solche Regeln können unbemerkt nicht mehr funktionieren. Legen Sie die Grenze stattdessen auf Ebene der Sandbox, des Containers oder des Rechners fest. Dort erledigt eine Domain-Allowlist oder eine isolierte Maschine dieselbe Aufgabe zuverlässig.

Wenn Sie Ihren eigenen Agenten über die API erstellen, statt Claude Code auszuführen, gilt dieselbe Überlegung unverändert. Einen KI-Agenten mit Claude auf einem VPS erstellen behandelt diesen Ansatz. Auch dieser Agent sollte unter einem eigenen Benutzer mit denselben eingeschränkten Tokens und auf derselben kurzlebigen Maschine ausgeführt werden.

Die Maschine zuerst absichern

Unabhängig davon, welche Stufe Sie wählen, benötigt die Maschine selbst die grundlegenden Absicherungen, bevor der Agent eingerichtet wird: ausschließlich SSH-Schlüssel, keine root-Anmeldung, eine Firewall mit standardmäßig blockierendem Verhalten und automatische Sicherheitsupdates. Erstellen Sie hier Ihre Checkliste und arbeiten Sie sie einmal vollständig ab:

FAQ

Ist die Verwendung von --dangerously-skip-permissions auf einem Server sicher?

Nicht von selbst. Das Flag entfernt jede Bestätigungsabfrage. Der erste schädliche Befehl wird daher ausgeführt, sobald das Modell ihn erzeugt. Vertretbar wird dieser Kompromiss, wenn die Auswirkungen begrenzt sind: mindestens durch einen eigenen Benutzer ohne privilegierte Rechte und bei wirklich unbeaufsichtigten Aufgaben durch einen Container oder einen temporären VPS, der nur ein Projekt und ein Token mit begrenztem Geltungsbereich enthält. Verwenden Sie das Flag niemals auf einem System, das Produktionszugangsdaten oder Daten enthält, auf deren Verlust Sie nicht verzichten können.

Verfügt Claude Code über eine Sandbox?

Ja. Claude Code enthält eine integrierte Sandbox für Shell-Befehle, die mit dem Befehl /sandbox geöffnet wird. Unter Linux verwendet sie bubblewrap und unter macOS Seatbelt. Schreibzugriffe werden auf das Projektverzeichnis begrenzt. Der Netzwerkzugriff wird über einen Proxy geleitet, der nur freigegebene Domains zulässt. Im automatischen Freigabemodus werden Befehle in der Sandbox ohne Rückfragen ausgeführt. Dadurch werden Unterbrechungen ähnlich wie beim Skip-Flag reduziert, während eine vom Betriebssystem erzwungene Grenze erhalten bleibt. Die Sandbox ist keine vollständige Isolationsgrenze. Kombinieren Sie sie daher bei unbeaufsichtigten Ausführungen mit einem eigenen Benutzer oder einem eigenen System.

Warum verweigert das Skip-Flag die Ausführung als root?

Weil root ohne Bestätigungsabfragen jede Datei und jeden Dienst im System ändern kann, blockiert Claude Code --dangerously-skip-permissions, wenn es unter Linux oder macOS als root oder mit sudo ausgeführt wird. Bekämpfen Sie diese Prüfung nicht. Erstellen Sie einen Benutzer ohne privilegierte Rechte für den Agenten und führen Sie ihn unter diesem Benutzer aus. Diese Benutzergrenze ist die erste und kostengünstigste Schutzschicht.

Kann Claude Code meine SSH-Schlüssel und .env-Dateien lesen?

Claude Code kann alles lesen, worauf der Benutzer, unter dem es ausgeführt wird, zugreifen kann. Selbst die Standardrichtlinie der Sandbox erlaubt Lesezugriffe auf Pfade mit Zugangsdaten, bis Sie diese untersagen. Führen Sie den Agenten daher unter einem eigenen Benutzer aus, setzen Sie die Berechtigungen für Ihr eigenes Home-Verzeichnis auf 750 oder restriktiver, verweigern Sie den Zugriff auf Pfade mit Zugangsdaten in den Sandbox-Einstellungen und speichern Sie Produktionsgeheimnisse überhaupt nicht auf dem System. Ein Geheimnis, das das System nie enthalten hat, kann nicht gelesen oder offengelegt werden.

Wie lässt sich Claude Code am sichersten unbeaufsichtigt ausführen?

Am besten verwenden Sie einen günstigen dedizierten VPS, der ausschließlich für Agentenaufgaben dient: innerhalb von zehn Minuten abgesichert, mit einem sauberen Snapshot versehen und mit Claude Code unter einem Benutzer ohne privilegierte Rechte und aktivierter Sandbox betrieben. Die API-Schlüsseldatei sollte die Berechtigungen 600 haben. Verwenden Sie außerdem einen Deploy-Schlüssel pro Repository und führen Sie alle Arbeiten in Branches aus, die Sie vor dem Zusammenführen prüfen. Wenn eine Ausführung fehlschlägt, widerrufen Sie ein Token und stellen den Snapshot wieder her. Andere Systeme und Daten, die Ihnen gehören, bleiben dadurch unbeeinträchtigt.