Marcel Moré zeigte die direkte Antwort auf den Vorfall vom Vormonat, als ein AI-Agent eine komplette Festplatte gelöscht hatte: Wie man Claude Code in einen Container sperrt, ohne sich die Arbeit unbequem zu machen.

Die Ausgangsüberlegung

Nach dem Datenverlust im Juni stand die Frage im Raum, wie man agentisches Arbeiten absichert. Perfekte Sicherheit ist verlockend – am Ende muss man aber vorwärtskommen und arbeiten. Die Entscheidung fiel deshalb bewusst für den pragmatischen Weg – mit dem Befund, dass man damit schon sehr weit kommt.

Problematisch im konkreten Fall war, dass Claude Code seine eigenen Sicherheitsregeln durch einen trickreich formulierten Aufruf umgangen hatte, und so ein hoch-riskantes Kommando auf der Befehlszeile eigenständig ausgeführt hatte, das in Kombination mit einem unsicheren Pfad in die Katastrophe führte.

Die Lektion dabei: Agenten werden immer autonomer und man kann nicht vorhersehen, welche Schritte sie dabei gehen. Je mehr Zugriffsmöglichkeiten sie haben, desto größer können ungewollte Folgen sein!

Diese Feststellung gilt nicht nur für Claude Code, sondern für jede Art agentischer Arbeit.

Die nun gewählte Absicherung besteht aus meheren Stufen:

  • Fehlerquellen wie unsichere Pfade mit führenden Leerzeichen vermeiden
  • Claude System-Hook mit einem Parser für Bash-Befehle, der kritische Befehlssequenzen blockiert
  • Arbeit im “Auto-Mode” ausschließlich in einer Sandbox ausführen – dies ist der wichtigste Punkt!

Dev Container statt Handarbeit

Grundlage der vorgestellten Sandbox-Umgebung sind die Dev Containers von VS Code – ein Plugin, das standard-mäßig mitgeliefert wird und auf ein installiertes Docker aufsetzt.

Der Mechanismus: Liegt im Repository eine .devcontainer/devcontainer.json, erkennt VS Code das und bietet an, das Projekt als Container zu öffnen. Man muss nur einmal bestätigen, alles andere passiert automatisch. In der Konfigurationsdatei stehen Docker-File, Version, Argumente, Extensions und Settings – beliebig komplex ausbaubar.

Der entscheidende Unterschied zur klassischen Docker-Compose-Handarbeit: Man arbeitet weiter in der gewohnten Dateistruktur des Host-Systems, tatsächlich läuft aber alles in einem Linux-Container. Auch fügt sich die Docker-Umgebung quasi “unter der Haube” in die IDE Arbeitsumgebung ein und stört daher kaum die gewohnten Abläufe. Einige Grenzen sind jedoch zu beachten und lassen sich mit gezielten Eingriffen elegant auflösen.

Das Dilemma der Enge – wenn der Agent nichts mehr darf

Ein zu enger Container ist nutzlos: Der Agent bekommt keinen Input mehr, kommt nicht an das Obsidian-Vault heran und sieht nicht, was außerhalb des Repositories liegt. Die Lösung liegt in fein geschnittenen Mount Points, die nicht nur festlegen, wohin sie zeigen, sondern auch, was sie dürfen:

  • Globales Skill-Verzeichnis – nur lesend eingebunden, damit die gewohnten Claude-Skills im Container verfügbar sind
  • Inbox-Verzeichnis – mit Schreibrechten. Alles, was den Container verlassen soll, landet hier. Ein kleines Raycast-Skript kopiert die Ergebnisse anschließend ins Obsidian-Vault: zwei Tastatur-Klicks, und die Unbequemlichkeit fällt nicht weiter ins Gewicht.
  • Command History – ein virtuelles Volume mit Schreibrechten auf dem Host. Damit bleibt die lokale Claude-Historie persistent in der Host-Umgebung erhalten.
  • Ressourcen – CPU und Memory werden dem Container fest zugeteilt, in der gezeigten Konfiguration 24 GB, damit auch größere Lösungen verarbeitet werden können.

Firewall: der Container darf nicht ins Netz

Neben dem Dateisystem ist das Netzwerk der zweite Schwachpunkt der zur Falle werden kann. Grundlage zur Absicherung ist ein Firewall-Skript aus dem Docker-Repository von VS Code, angepasst auf die eigenen Bedürfnisse. Erlaubt ist nur, was Claude Code zwingend braucht:

  • die Anthropic API
  • die npm-Registry
  • einige Telemetrie-Dienste
  • der Visual Studio Marketplace für Plugin-Updates
  • DuckDB (optional im Projekt)

Alles andere ist abgeriegelt. Wird eine zusätzliche Adresse braucht, trägt man sie in die Whitelist ein – der Container konfiguriert seine Firewall beim Hochfahren selbst.

Aufwand und Vorbereitung

Der Installationsaufwand war überschaubar. Ein passendes Dev-Container Template war mit Hilfe von Claude schnell für die eigenen Zwecke maßgeschneidert angepasst und kann jederzeit ergänzt werden. VS Code erkennt das Template im lokalen Repo automatisch und startet beim nächsten Öffnen die Sandbox-Umgebung inkl. Einrichtung der Firewall.

Damit ist der Container sowohl gegen das Dateisystem als auch gegen das Internet gesperrt. Wenn der Agent etwas falsch macht, bleiben die Auswirkungen überschaubar. Auch das Risiko für böswillige Prompt-Injections und Crendential-Theft wird damit wirksam eingedämmt.

Live vorgeführt

In der Demo wurde der laufende Container samt offener Claude-Sessions gelöscht und neu gebaut – Netzwerke, Mountpoints und Skripte richteten sich selbst ein. Nach wenigen Sekunden war die Oberfläche exakt so wieder da wie vorher, weil das Arbeitsverzeichnis und die Session-Daten außerhalb des Containers liegen.

Fazit

Es geht nicht um hundertprozentige Sicherheit, sondern darum, den Blast Radius so klein wie möglich zu halten. Dev Container sind dafür eine ausgesprochen bequeme Möglichkeit: reproduzierbar, portabel und mit sehr überschaubarem Einrichtungsaufwand. Das Sicherheitsgefühl steigt und ein Agent im “Auto-Mode” ist weniger riskant zu betreiben – zumal die Modelle mit jeder Generation kreativer und schlagkräftiger werden.

Weitere Infos:

Developing inside a Container
https://code.visualstudio.com/docs/devcontainers/containers

Dev Containers Plugin
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers

Docker Sandboxes
https://www.docker.com/products/docker-sandboxes/