SSD Nodes Learn
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-07-24

Claude Code sicher auf Servern ausführen

Erfahren Sie, wie Sie den --skip-permissions Flag nutzen und Claude Code sicher in Sandboxes oder VPS isolieren, um unvorhergesehene Shell-Befehle zu begrenzen.

Was sich sicheres Ausführen von Claude Code auf einem Server bedeutet

Um Claude Code sicher auf einem Server auszuführen, lassen Sie die Berechtigungsabfragen aktiviert, führen Sie es als dedizierten, unprivilegierten Benutzer aus und geben Sie unattended Runs eine echte Grenze statt blindem Vertrauen: die integrierte Sandbox, einen Container oder einen disposable VPS, der keine kritischen Daten enthält. Das --dangerously-skip-permissions Flag entfernt den Bestätigungsschritt zwischen dem Modell und Ihrer Shell. Dieser Kompromiss ist für unattended Arbeit sinnvoll, aber nur innerhalb einer Grenze, die den Zugriff durch einen fehlerhaften Befehl einschränkt. Diese Anleitung erklärt, was das Flag tatsächlich ändert und wie Sie diese Grenze in Stufen zunehmender Isolation aufbauen.

Was Claude Code auf Ihrem System tun kann

Claude Code ist ein Coding-Agent, der in Ihrem Terminal läuft. Er liest Dateien, schreibt Dateien und führt Shell-Befehle als der Benutzer aus, der ihn gestartet hat. Das ist der gesamte Nutzen des Tools: Er kann ein Repository klonen, Code editieren, Tests ausführen, Fehlermeldungen lesen und den Code in einer Schleife reparieren, ohne dass Sie jeden Befehl selbst tippen müssen. Falls Sie es noch nicht auf einem Server eingerichtet haben, behandelt das Ausführen von Claude Code auf einem VPS mit tmux die Installation und die Session-Handhabung. Diese Seite beschreibt die Berechtigungen, die Sie dem Tool übertragen, sobald es installiert ist.

Das Risiko ist die Wiederholung desselben Satzes: Ein Prozess, der Shell-Befehle als Ihr Benutzer ausführt, kann alles tun, was Ihr Benutzer tun kann. Er kann ~/.ssh/id_ed25519, ~/.aws/credentials und jede .env Datei lesen, die Ihr Benutzer öffnen 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 Text, den er während der Arbeit gelesen hat, Anweisungen von jemand anderem enthält: eine abgerufene Webseite oder ein Kommentar in einem Issue, das er beheben soll. Dieser zweite Fall wird Prompt Injection genannt; deshalb ist der Satz „das Modell ist normalerweise vernünftig“ kein Sicherheitskonzept. Planen Sie für den Fehlerfall, nicht für den Normalfall.

Das Berechtigungssystem einfach erklärt

Standardmäßig fragt Claude Code vor jeder Aktion nach. Das Lesen von Dateien innerhalb des Projekts erfolgt lautlos, aber das Editieren einer Datei oder das Ausführen eines Shell-Befehls zeigt Ihnen zuerst die exakte Änderung oder den Befehl an und wartet auf eine Bestätigung. Sie können eine einzelne Aktion oder diese Art von Aktion für die restliche Session freigeben. Diese Freigaben gelten nur für die aktuelle Session: Beenden Sie das CLI, startet die nächste Session wieder im vorsichtigen Modus. Für Regeln, die dauerhaft gelten sollen, speichert die Settings-Datei persistente Allow-, Ask- und Deny-Listen. Zum Beispiel: allow git status, ask bei git push, deny reads von .env. Deny-Regeln haben immer Vorrang.

Dieses Design setzt voraus, dass ein Mensch das Terminal überwacht; auf einem Laptop ist das der Fall. Auf einem Server ist es oft so, dass niemand zuschaut. Sie starten eine langwierige Aufgabe in tmux und gehen schlafen; ein Agent, der um 2 Uhr morgens eine Frage stellt, macht bis zum Morgen keine Fortschritte. Die Pause kostet sowohl Zeit als auch Geld, da eine inaktive Claude Code Session ihren warmen Prompt-Cache verliert und der nächste Turn die Rekonstruktion kostet. Das ist der reale Grund, warum Nutzer auf Servern zum Skip-Flag greifen. Der Rest dieser Anleitung befasst sich mit der Lösung dieses Problems, ohne alle Schutzmaßnahmen aufzugeben.

Was --dangerously-skip-permissions ändert

claude --dangerously-skip-permissions schaltet den Bestätigungsschritt aus. Edits erfolgen ohne Prompt. Shell-Befehle laufen ohne Prompt. Die Protected-Path-Prüfungen, die normalerweise sensible Orte schützen, werden ebenfalls übersprungen. Ihre expliziten Deny-Regeln gelten weiterhin, und einige extreme Aktionen unterbrechen den Vorgang dennoch für eine Abfrage, aber die Zusammenfassung ist einfach: Was immer das Modell ausführen möchte, wird ausgeführt.

Zwei Fakten zum Flag sind auf einem Server wichtig. Erstens wird es blockiert, wenn Claude Code als root oder unter sudo auf Linux und macOS läuft, da root ohne Prompts jede Datei oder jeden Dienst auf der Maschine ändern kann. Der Agent benötigt ohnehin ein eigenes unprivilegiertes Konto, und das Flag erzwingt dies. Zweitens ändert das Flag das Verhalten des Modells nicht. Es entfernt den Menschen aus dem Prozess und ändert sonst nichts, sodass jeder Fehler, den ein Prompt abgefangen hätte, nun ausgeführt wird.

Hier ist die ehrliche Kalkulation: Wenn Sie die Berechtigungen überspringen, ändert sich die Sicherheitsfrage von „wird der Agent etwas Schlimmes tun“ zu „wie viel Schaden kann eine einzige schlechte Aktion anrichten“. Sie versuchen nicht mehr, jede Entscheidung zu kontrollieren, sondern kontrollieren den Blast Radius. Containment ist die Lösung, und diese erfolgt in Stufen.

Die integrierte Claude Code Sandbox

Bevor wir zu den Stufen kommen: Claude Code liefert jetzt eine Sandbox auf Betriebssystemebene für die ausgeführten Befehle mit, was die meisten Gründe für das Skip-Flag eliminiert. Auf Linux verwendet es bubblewrap für die Dateisystem-Isolation sowie socat, um den Netzwerkverkehr über einen Proxy zu leiten. Innerhalb der Sandbox kann ein Befehl nur in das Projektverzeichnis und ein Session-Temp-Verzeichnis schreiben; der Netzwerkzugriff ist nur über einen Proxy möglich, der jede Domain gegen eine Allow-Liste prüft. Wenn ein Befehl zum ersten Mal eine neue Domain aufrufen möchte, fragt Claude Code Sie.

Aktivieren Sie dies mit dem /sandbox Befehl innerhalb einer Session. Installieren Sie auf Ubuntu und Debian zuerst die beiden benötigten Pakete:

sudo apt install bubblewrap socat

Auf Ubuntu 24.04 und neuer verhindert die Standard-AppArmor-Policy, dass bubblewrap die benötigten User-Namespaces erstellt. Das Sandbox-Panel zeigt an, wenn etwas fehlt; die Claude Code Sandboxing-Dokumentation enthält das kurze AppArmor-Profil, das dies behebt.

Die Sandbox hat einen Auto-Allow-Modus: Sandboxed-Befehle laufen ohne Prompt, da die erzwungene Grenze die Arbeit übernimmt, die früher der Prompt erledigt hat. Befehle, die nicht in der Sandbox laufen können, fallen auf den normalen Berechtigungsfluss zurück, sodass ungewöhnliche Aktionen weiterhin nachfragen. Für die meisten Server-Workflows ist dies der korrekte Ersatz für das Skip-Flag, da Sie mit einer OS-erzwungenen Grenze deutlich weniger Fragen erhalten als gar keine.

Seien Sie ehrlich bezüglich der Grenzen. Standardmäßig kann ein sandboxed Befehl immer noch den Großteil des Dateisystems lesen, einschließlich Credential-Dateien, sofern Sie diese Pfade nicht verweigern; die sandbox.credentials Einstellung ist genau dafür da. Der Netzwerk-Proxy prüft Domainnamen, inspiziert aber nicht den Traffic selbst; ein breites Allow wie github.com lässt weiterhin Raum, um Daten zu exfiltrieren. Docker funktioniert innerhalb der Sandbox nicht. Die Sandbox erhöht das Sicherheitsniveau erheblich, ist aber keine vollständige Isolationsgrenze, weshalb die folgenden Stufen wichtig bleiben.

Die Containment-Leiter

Drei Stufen in zunehmender Isolation. Wählen Sie die niedrigste Stufe, die zu Ihrer restlichen Server-Konfiguration passt.

Stufe 1: ein dedizierter unprivilegierter Benutzer. Der Agent erhält ein eigenes Konto, ein eigenes Home-Verzeichnis, ein eigenes Projektverzeichnis und kein sudo:

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

Die Kontogrenze hält den Agenten von Ihren Dateien fern: Ihren SSH-Keys und jedem anderen Projekt auf der Maschine. Zudem macht sie das Skip-Flag überhaupt erst nutzbar, da das Flag den Lauf als root verweigert. Dies ist dasselbe Prinzip wie jeder Dienst als unprivilegierter Benutzer auszuführen, angewendet auf einen Agenten. Was Stufe 1 nicht begrenzt: das Netzwerk und alles auf der Maschine, das für alle lesbar ist.

Stufe 2: ein Container. Anthropic veröffentlicht einen Referenz-Devcontainer, der Claude Code als Non-Root-User mit Firewall-Regeln ausführt, die den erreichbaren Host einschränken; ein selbst gebauter Container erfüllt denselben Zweck. Das Dateisystem schrumpft auf die gemounteten Volumes, und der Egress schrumpft auf das, was die Container-Regeln erlauben. Dies ist die richtige mittlere Stufe, wenn der Server andere wichtige Dienste hostet. Die Grenze liegt darin, dass Container den Host-Kernel teilen und ein unvorsichtiger Mount die Isolation aufhebt; geben Sie dem Container /var/run/docker.sock, kann er den gesamten Host erreichen.

Stufe 3: ein dedizierter VPS. Die stärkste Stufe ist die simpelste: Geben Sie dem Agenten eine komplette Maschine, die nichts enthält, was Ihnen wichtig ist. Ein kleiner VPS kostet nur wenige Dollar im 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. Nichts anderes lebt dort. Kein persönlicher SSH-Key, nur ein Deploy-Key, der auf das eine Repository beschränkt ist. Keine Cloud-Credentials, keine Produktionsdaten. Wenn ein Run fehlschlägt oder Sie einen sauberen Zustand benötigen, stellen Sie den Snapshot wieder her oder zerstören und bauen Sie die Maschine in Minuten neu auf. Der Blast Radius ist die Mietgebühr. Dies ist das Setup, bei dem --dangerously-skip-permissions nicht mehr beängstigend ist, da das schlimmste realistische Ergebnis ein neu aufgesetzter Server und ein widerrufener Token ist.

Die Stufen bauen aufeinander auf. Ein sandboxed Agent, der als unprivilegierter Benutzer auf einem disposable VPS läuft, kostet fast nichts extra und macht Fehlerszenarien langweilig. Langeweile ist das Ziel.

Credentials schützen

Die Regel, die alles andere rechtfertigt: Der Benutzer des Agenten darf keine Secrets lesen können, die zu anderen Diensten gehören.

Geben Sie den API-Key nur dem Agenten und sonst niemandem. Speichern Sie ihn in einer Datei, die dem Agent-User gehört (Mode 600), und laden Sie ihn beim Start der 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

Schließen Sie dann die andere Richtung. Auf Debian und Ubuntu sind Home-Verzeichnisse oft für jeden Benutzer auf der Maschine lesbar; verschärfen Sie Ihr eigenes: chmod 750 /home/youruser. Prüfen Sie dies mit ls -ld /home/* und korrigieren Sie alles, was das Agent-Konto auflisten kann.

Beschränken Sie jedes Token. Ein feingranulares GitHub-Token, das auf ein Repository beschränkt ist, oder ein pro Repository spezifischer Deploy-Key bedeutet, dass ein geleaktes Credential nur ein Projekt und nicht Ihr gesamtes Konto gefährdet. Wenn Sie die Sandbox nutzen, fügen Sie deren Credential-Einstellungen hinzu, damit ~/.ssh und ~/.aws selbst für Lesezugriffe verweigert werden. Und halten Sie Produktions-Credentials komplett vom Server fern, da ein Agent kein Secret stehlen kann, das nie dort war.

Git ist das Sicherheitsnetz

Jede Änderung, die der Agent vornimmt, sollte überprüfbar und rückgängig machbar sein. Git bietet Ihnen beides kostenlos, wenn der Agent auf einem Branch arbeitet:

git switch -c agent/refactor-auth

Überprüfen Sie den Run danach mit git diff main...agent/refactor-auth, mergen Sie das Gute und löschen Sie den Branch, wenn der Run zu nichts geführt hat. Schützen Sie den Main-Branch auf der Plattform (Forge), damit der Agenten-Token nicht darauf pushen kann und keine Force-Pushes durchführen kann. Die Commit-Historie dient gleichzeitig als Audit-Log dessen, was während Ihres Schlafs passiert ist, was mehr wert ist als jeder Terminal-Scrollback.

Das Netzwerk ist Teil des Blast Radius

Ein Agent kann curl ausführen. Dieser Satz beschreibt das gesamte Egress-Problem: Was immer der Agent lesen kann, kann er auch irgendwohin senden, und ein durch Prompt Injection manipulierte Agent könnte das tun. Ein einfacher unprivilegierter Benutzer begrenzt dies überhaupt nicht, da jeder Benutzer alles erreichen kann, was der Server erreichen kann. Die Sandbox begrenzt dies nach Domain über ihren Proxy. Ein Container kann dies mit eigenen Firewall-Regeln begrenzen. Ein dedizierter VPS begrenzt das, was überhaupt erst geleakt werden kann, was die robusteste der drei Antworten ist.

Versuchen Sie nicht, den Egress allein mit ufw zu lösen. ufw erlaubt standardmäßig den gesamten ausgehenden Traffic; das Schreiben von Outbound-Regeln, die gleichzeitig apt, npm, git und die Claude API zulassen, ist mühsame Arbeit, die oft lautlos fehlschlägt. Wählen Sie stattdessen die Grenze auf Sandbox-, Container- oder Maschinenebene, wo eine Domain-Allow-Liste oder eine nackte Maschine die gleiche Aufgabe sauber erledigt.

Wenn Sie Ihren eigenen Agenten gegen die API bauen, anstatt Claude Code auszuführen, gilt dasselbe Prinzip. Einen KI-Agenten mit Claude auf einem VPS bauen beschreibt diesen Weg, und dessen Agent verdient denselben dedizierten Benutzer, dieselben beschränkten Tokens und denselben disposable Box.

Erst den Server härten

Egal für welche Stufe Sie sich entscheiden, die Maschine selbst benötigt die Grundlagen, bevor der Agent einzieht: Nur SSH-Keys, kein Root-Login, eine Default-Deny-Firewall, automatische Sicherheitsupdates. Erstellen Sie hier Ihre Checkliste und arbeiten Sie sie einmal ab:

ToolHarden the box before the agent moves in

FAQ

Ist --dangerously-skip-permissions auf einem Server sicher?

Nicht für sich allein. Das Flag entfernt jede Bestätigung, sodass der erste fehlerhafte Befehl ausgeführt wird, sobald das Modell ihn generiert. Es wird zu einem vertretbaren Kompromiss, wenn der Blast Radius begrenzt ist: mindestens ein dedizierter unprivilegierter Benutzer und für unattended Arbeit ein Container oder ein disposable VPS, der nur ein Projekt und ein beschränktes Token enthält. Nutzen Sie es niemals auf einer Maschine, die Produktions-Credentials oder Daten enthält, die Sie nicht verlieren können.

Verfügt Claude Code über eine Sandbox?

Ja. Claude Code liefert eine integrierte Sandbox für Shell-Befehle mit, die mit dem /sandbox Befehl aktiviert wird. Sie verwendet bubblewrap auf Linux und Seatbelt auf macOS, beschränkt Schreibzugriffe auf das Projektverzeichnis und leitet den Netzwerkzugriff über einen Proxy, der nur freigegebene Domains zulässt. Der Auto-Allow-Modus führt sandboxed Befehle ohne Prompts aus, wodurch er Unterbrechungen so reduziert wie das Skip-Flag, aber eine OS-erzwungene Grenze beibehält. Es ist keine vollständige Isolationsgrenze; kombinieren Sie es daher mit einem dedizierten Benutzer oder einer dedizierten Maschine für unattended Runs.

Warum verweigert das Skip-Flag den Lauf als root?

Da root ohne Bestätigung die Dateien und Dienste des Systems modifizieren kann, blockiert Claude Code --dangerously-skip-permissions, wenn es als root oder unter sudo auf Linux und macOS läuft. Die Lösung ist nicht, die Prüfung zu bekämpfen. Erstellen Sie einen unprivilegierten Benutzer für den Agenten und führen Sie ihn dort aus; diese Kontogrenze ist die erste und günstigste Schicht der Isolation.

Kann Claude Code meine SSH-Keys und .env-Dateien lesen?

Er kann alles lesen, was der Benutzer, unter dem er läuft, lesen kann. Selbst die Standard-Policy der Sandbox erlaubt Lesezugriffe auf Credential-Pfade, bis Sie diese verweigern. Führen Sie den Agenten also als eigenen Benutzer aus, halten Sie Ihr eigenes Home-Verzeichnis auf Mode 750 oder strenger, verweigern Sie Credential-Pfade in den Sandbox-Einstellungen und halten Sie Produktions-Secrets komplett vom Server fern. Ein Secret, das die Maschine nie besaß, kann nicht gelesen oder geleakt werden.

Was ist der sicherste Weg, Claude Code unattended auszuführen?

Ein günstiger dedizierter VPS, der nur für Agenten-Arbeit genutzt wird: in zehn Minuten gehärtet, sauber als Snapshot gesichert, Claude Code unter einem unprivilegierten Benutzer mit aktivierter Sandbox, eine Mode-600 Datei für den API-Key, ein pro Repository spezifischer Deploy-Key und alle Arbeiten auf Branches, die Sie vor dem Mergen prüfen. Wenn ein Run fehlschlägt, widerrufen Sie einen Token und stellen Sie den Snapshot wieder her; nichts anderes, was Ihnen gehört, ist betroffen.