Warum KI nur im Container laufen sollte

2026-08-05

Ein KI-Agent, der Code schreibt, ist inzwischen Alltag. Ein KI-Agent, der dafür eigenständig Shell-Befehle ausführt, Pakete installiert, Dateien löscht und Git-Commits erstellt, ist etwas anderes: Er handelt autonom auf meinem System, nicht mehr nur als Autovervollständigung im Editor. Genau deshalb lasse ich solche Agenten grundsätzlich nur noch in Containern laufen, nie direkt auf meinem Host. Nicht aus Misstrauen gegenüber der KI selbst, sondern weil Autonomie und ein begrenzter Blast Radius zusammengehören.

Der Grund: Blast Radius statt Vertrauen

Ein Agent, der rm -rf, git push --force oder curl | sh ausführen kann, macht früher oder später einen Fehler, der nicht am Modell liegt, sondern an der Aufgabe: eine falsch interpretierte Anweisung, ein Prompt-Injection-Versuch aus einer Webseite, die er gerade liest, oder schlicht ein zu weit gefasster Auftrag. Die Frage ist also nicht, ob so etwas passiert, sondern wie teuer es wird, wenn es passiert.

Auf dem Host kann ein solcher Fehler die SSH-Keys treffen, das dotfiles-Repo, andere Projekte im selben ~/dev-Ordner oder die Shell-Konfiguration. Im Container ist der Schaden auf genau diesen einen, jederzeit wegwerfbaren Container begrenzt. Ich muss dem Agenten damit nicht weniger Handlungsspielraum geben, im Gegenteil: Weil der Blast Radius klein ist, kann ich ihm mehr Autonomie erlauben, etwa Shell-Zugriff ohne Rückfrage bei jedem einzelnen Befehl, ohne dass sich das Risiko entsprechend erhöht. Isolation ist damit keine Bremse für Produktivität, sondern deren Voraussetzung.

Mehr als nur Sicherheit: Vorteile für die Entwicklung

Der Sicherheitsaspekt ist der Grund, warum ich überhaupt angefangen habe, aber im Alltag sind es die Entwicklungsvorteile, die das Setup tragen:

Reproduzierbarkeit statt “geht bei mir”: Node-, Go- oder Hugo-Version stecken im Devcontainer-Image, nicht in meinem lokalen PATH. Ein Projekt von vor sechs Monaten baut heute noch genauso wie damals, egal auf welchem Rechner ich gerade sitze.
Wegwerfbarkeit: Ein Container, den der Agent zerlegt hat, wird nicht repariert, sondern gelöscht und neu gebaut. Das dauert eine Minute und ist damit die einfachste Form von Fehlerbehandlung, die es gibt.
Sauber getrennte Secrets: Statt globaler API-Keys in der Shell-Umgebung wird gezielt gemountet, was ein Projekt wirklich braucht, etwa die ~/.claude-Config für Claude Code. Ein anderes Projekt sieht diese Daten gar nicht erst.
Schnelles Onboarding: devpod up . reicht, um von einem leeren Rechner zu einer voll konfigurierten Umgebung mit allen Tools, Extensions und dem passenden KI-Agenten-Feature zu kommen, egal ob macOS, Linux oder ein Cloud-Rechner.
Mehrere Projekte, keine Versionskonflikte: Jedes Projekt bekommt seinen eigenen Container mit seinen eigenen Toolversionen, parallel, ohne dass sich globale Installationen gegenseitig überschreiben.

Mein Setup: DevPod, Podman und Zed

Konkret sieht mein Setup so aus: DevPod orchestriert die Workspaces, Podman baut und betreibt die Container, und Zed ist der Editor, der sich remote in den laufenden Container verbindet.

Warum Podman statt Docker

Podman ist rootless und daemonless: Es läuft ohne dauerhaft im Hintergrund laufenden, privilegierten Daemon, und Container laufen standardmäßig ohne Root-Rechte auf dem Host. Für Container, in denen ein Agent selbstständig Befehle ausführt, ist das genau die zusätzliche Schicht Isolation, die ich will, ganz unabhängig vom Container-Inhalt selbst. In diesem Website-Repo sieht man das an einem Detail im .devcontainer/devcontainer.json:

"runArgs": ["--userns=keep-id:uid=1000,gid=1000"],

Das sorgt dafür, dass die UID im rootless Podman-Container sauber auf meinen Host-User gemappt wird, Dateien, die der Container schreibt, gehören danach nicht root, sondern mir.

DevPod als Orchestrator

DevPod liest denselben devcontainer.json-Standard wie VS Code Dev Containers oder GitHub Codespaces, spricht aber über Provider mit unterschiedlichen Backends, unter anderem Docker, Kubernetes, SSH-Hosts oder eben Podman. Einen neuen Workspace starten heißt bei mir schlicht:

devpod provider add podman
devpod up . --ide zed

Auf macOS läuft Podman selbst nicht nativ, sondern in einer Linux-VM (der “Podman Machine”). Diese VM von Hand zu verwalten ist der lästige Teil: Socket-Pfad korrekt finden, Berechtigungen auf den Socket setzen, SELinux passend konfigurieren, Zeitdrift nach dem Aufwachen aus dem Sleep korrigieren, bevor Paket-Downloads mit Signaturfehlern abbrechen. Genau das automatisiert der DevPod-Podman-Provider von kuju63: Er startet und stoppt die Podman Machine automatisch passend zum Workspace-Lebenszyklus und erlaubt, CPU, RAM und Diskgröße über Optionen wie PODMAN_MACHINE_CPUS oder PODMAN_MACHINE_MEMORY direkt aus DevPod heraus zu steuern, inklusive nicht-destruktiver Anpassung bestehender Maschinen über podman machine set.

Zed als Editor

Zed unterstützt Remote Development über SSH direkt in den laufenden Container, DevPod baut dafür automatisch den passenden SSH-Zugang auf. Die einzige Besonderheit gegenüber Docker ist eine Zeile in den Zed-Settings:

{
  "ssh_connections": [],
  "use_podman": true
}

Für VS Code als Alternative braucht die Dev-Containers-Extension stattdessen einen Docker-Path-Alias, der auf das Podman-Binary zeigt, DevPod übernimmt beide Fälle transparent.

Die Basis: dev-starter und my-dotfiles

Damit ich nicht bei jedem neuen Projekt wieder bei null anfange, liegt die eigentliche Konfiguration in zwei eigenen Repos:

dev-starter ist die Vorlage für neue Devcontainer. Projektdateien landen in einem eigenen project/-Unterverzeichnis, das über einen Rebuild hinweg erhalten bleibt, während Repo-Dateien wie Dockerfile und devcontainer.json auf dem Host bleiben. Das Claude-Code-Feature ist bereits eingebunden, inklusive Mount der lokalen ~/.claude-Config, genau wie es auch im devcontainer.json dieser Website zu sehen ist.
my-dotfiles bringt Git-Aliase, Shell-Konfiguration und Editor-Defaults in jeden neuen Container, ganz ohne Secrets, über DevPods --dotfiles-Flag:

devpod up . --dotfiles https://git.serk-b.de/rev/my-dotfiles.git

So bekommt jeder Container dieselbe vertraute Shell-Umgebung, ohne dass ich Zugangsdaten oder Tokens ins Image backen müsste, die dann in jedem wegwerfbaren Container erneut herumliegen würden.

Fazit

Ein KI-Agent mit Shell-Zugriff ist ein Werkzeug mit echtem Handlungsspielraum, und Handlungsspielraum braucht eine Grenze, an der ein Fehler aufhört, teuer zu sein. Der Container ist diese Grenze. Das Setup aus DevPod, Podman und Zed sorgt dafür, dass diese Isolation nicht auf Kosten von Komfort geht: ein Befehl für einen neuen Workspace, dieselbe Umgebung auf jedem Rechner, und im Zweifel ein Container, der gelöscht statt repariert wird.

← Zurück zur Übersicht