Es ist März 2026 und alle benutzen Claude Code oder experimentieren zumindest damit. Aber Claude Code bringt einige erhebliche Sicherheitsrisiken mit sich. In diesem Artikel geht es darum, wie ich persönlich entschieden habe, mit diesen Risiken umzugehen.
tldr;
Wenn du nur eine Lösung suchst, um einfach Claude Code sessions in podman containern laufen zu lassen, schau dir ai-pod an.
Bestehende Lösungen
Schauen wir uns die naheliegenden Optionen an und warum sie für mich nicht ausreichend waren:
Einfach individuelle Berechtigungen pro Befehl setzen
Claude Code fragt den/die Entwickler:in standardmäßig für jeden Befehl um Erlaubnis und schlägt Standardberechtigungen für wiederholte Verwendungen vor, z.B. erlaubt es generell Lese- und Schreibzugriffe sowie spezifische Bash-Befehle mit Wildcards wie ls *, git add * usw.
Dieses Setup hat drei Nachteile:
Es gibt keine praktische Möglichkeit zu verhindern, dass Claude das gesamte Dateisystem liest.
Es wird schnell unsicher, weil Claude sehr viele Berechtigungen anfordert, was zu Ermüdung führt: Man beginnt nach einer Weile, alle Anfragen einfach zu akzeptieren.
Es ist ineffizient, weil Claude ständig um Erlaubnis bittet, was meinen Workflow ausbremst.
Claude's eigene Sandbox
Claude Code kommt mit einem /sandbox-Befehl, der Claude in eine isolierte Shell versetzt.
Das funktioniert für mich nicht, weil
Claude damit immer noch das gesamte Dateisystem lesen und alle meine Geheimnisse an Anthropic (und möglicherweise andere Parteien durch Prompt Injection und Web Fetch / curl) weitergeben kann.
Ich mich häufig gezwungen sehe, die Sandbox zu verlassen, weil Claude nicht auf Host-Ports und andere Ressourcen zugreifen kann.
container-use
container-use ist ein Tool, um Befehle in einem dedizierten Container/VM mit dagger/docker auszuführen. Es stellt einen MCP bereit, über den Claude sich selbst in eine isolierte Umgebung versetzen kann.
Claude richtet dann seine eigene abgeschottete Umgebung ein, arbeitet an Änderungen, und ich kann diese Änderungen mit normalen Git-Befehlen auf den Host übernehmen.
Das ist ziemlich clever, aber ich hatte Schwierigkeiten mit dem Setup und merkte außerdem, dass ich eine direktere Zusammenarbeit möchte. Ich will tatsächlich, dass Claude gegen ein Repo in meinem lokalen Dateisystem arbeitet, damit ich die Änderungen sofort sehen und mitverfolgen kann.
Ein weiteres Problem mit diesem Ansatz ist, dass viele meiner Apps Secrets benötigen, um zu laufen. Damit Claude eine solche App in seiner isolierten Umgebung ausführen kann, müsste ich die Secrets an Claude übergeben – was ich nach Möglichkeit vermeiden möchte.
Online-Sandboxes
IaaS/PaaS-Anbieter liefern sich zur Zeit ein Rennen, ihren Kund:innen KI-taugliche Sandbox-VMs anzubieten, wie zum Beispiel die Angebote von vercel oder fly.io.
Diese Sandboxes sind gut isoliert und bieten einige nützliche Features.
Aber auch hier möchte ich die Secrets zum Betrieb meiner Apps nicht in die Sandbox geben, und ich möchte Ergebnisse sofort sehen, ohne einen Git-Workflow dazwischen.
Meine Lösung
Ich habe festgestellt, dass podman genau das Tool sein könnte, das ich brauche – und ich habe es ohnehin eingerichtet, weil ich es zum Hosten der Entwicklungsumgebungen meiner Projekte nutze (Postgres-Datenbanken etc.). Es bietet Isolation durch das Ausführen einer unprivilegierten VM (genannt Podman Machine), in der alle Container laufen, sowie eine sehr komfortable Möglichkeit, nur die spezifischen Ordner, die ich brauche, in den Container einzubinden, der Claude Code ausführt.
Das Setup, das ich gebaut habe, funktioniert so:
Ich baue ein Docker-Image pro Projekt. Dieses Image enthält alle möglichen Tools, die für Claude in diesem speziellen Projekt nützlich sind. In einem Next.js-Repo könnte es auf dem node Docker-Image basieren und den Next.js MCP-Server vorinstalliert haben. Es erstellt einen Benutzer
claude, der das eigentliche CLI ausführt.Ich habe ein Docker-Volume für das Home-Verzeichnis (
/home/claude), das Einstellungen und Authentifizierung zwischen mehreren Sessions persistiert.Ich führe einen Container pro Session aus. Meistens ist das einer pro Projekt, manchmal mehrere parallel, manchmal trenne ich die Verbindung und lasse sie im Hintergrund laufen.
Das Projektverzeichnis wird als Volume in den Container eingebunden.
Alle dotenv-Dateien werden an einem zentralen Ort (
~/.env-files) gespeichert und per Symlink in die Projektverzeichnisse verlinkt, sodass sie im Container nicht sichtbar sind.Ich starte den Dev-Server auf dem Host und weise Claude an, ihn unter
http://host.containers.internalzu erreichen – die URL, die in Podman-Netzwerken auf den Host verweist. So kann Claude sehen, was es baut, ohne Zugriff auf die Secrets zu haben.Dann gebe ich Claude einfach alle Berechtigungen, die es möchte – insbesondere lasse ich es bei Bash-Befehlen freie Hand, da alle Befehle in seiner isolierten Container-Umgebung ausgeführt werden.
Ist das vollkommen sicher?
Nein, ist es nicht.
Claude kann aus dem Container ausbrechen und zumindest auf alle anderen Container zugreifen, die in derselben VM laufen.
Es kann schlechten Code in mein Repo einchecken (dieses Risiko ist dem agentischen Entwickeln inhärent und unvermeidbar – weshalb ich sicherstelle, dass ein Mensch den Code geprüft hat, bevor er gemergt wird).
Es kann den Code so modifizieren, dass er Schaden anrichtet, und diesen Code sofort ausführen, indem es eine Route auf dem Dev-Server abruft, den ich auf dem Host betreibe. Mit diesem Risiko lebe ich vorerst, suche aber nach Gegenmaßnahmen.
Dennoch scheinen die größten Schwachstellen im Moment diese zu sein:
Extraktion von Umgebungsvariablen durch Prompt-Injection-Angriffe. Der Angreifer müsste mein Setup ziemlich genau kennen und Claude zu einer Menge unerwünschtem Verhalten überreden, um mit meinem Setup an meine Umgebung zu gelangen.
Claude scheint ab und zu große Teile des Dateisystems seiner Nutzer zu löschen (
rm -rf). Das kann mit meinem Setup nicht passieren.
Das klingt kompliziert
Ich habe ein Tool namens ai-pod gebaut, das die schwere Arbeit übernimmt (erstellt ein Beispiel-ai-pod.Dockerfile, führt die Container mit den richtigen Mounts aus und leitet sogar Benachrichtigungen weiter, wenn Claude fertig ist).
Ich nutze ai-pods inzwischen für alle meine Claude-Sessions und es fühlt sich im Vergleich zum nativen Ausführen von Claude nicht wie eine Zusatzlast an. Es verhindert sogar die (für mich persönlich unerwünschte) kontextuelle Überschneidung zwischen Projekten – jedes Projekt hat seine eigenen Claude-Einstellungen und seinen eigenen Verlauf.
Fazit
Claude Code in einem Container auszuführen ist der Ansatz, der für mich am besten funktioniert. Er gibt Claude die Freiheit, Bash-Befehle auszuführen, ohne ständige Berechtigungsabfragen, und hält es gleichzeitig von meinen Secrets, meinem Home-Verzeichnis und dem Rest meines Systems fern.
Die entscheidende Erkenntnis ist die Trennung dessen, was Claude braucht, um das Projekt zu bauen, von dem, was das Projekt braucht, um zu laufen – indem Secrets vollständig aus dem Container herausgehalten und der Dev-Server auf dem Host betrieben werden, kann Claude effektiv iterieren, ohne jemals an sensible Zugangsdaten zu gelangen.
Es ist keine perfekte Sandbox und gibt auch nicht vor, eine zu sein. Aber es reduziert die Angriffsfläche für die Bedrohungen, die mir am wichtigsten sind, erheblich: die Extraktion von Secrets durch Prompt Injection und versehentliche oder böswillige Zerstörung des Dateisystems. Für alles andere bleibt Code-Review die letzte Verteidigungslinie.
Wer dieses Setup selbst ausprobieren möchte, schaut sich ai-pod an. Es kümmert sich um den Boilerplate, damit man sich aufs Bauen konzentrieren kann.
