Coding-Agenten sind im Arbeitsalltag längst angekommen, der Umgang mit ihnen ist jedoch sehr unterschiedlich. So reicht das Spektrum von komplettem Blindflug über agentische Code-Reviews bis zur menschlichen Kontrolle aller Anpassungen.
Der Coding-Agent wird in der Regel mit einem Harness betrieben, das als Laufzeitumgebung der Agenten dient und Berechtigungen prüfen soll. Auch wer jede Aktion einzeln freigibt, kann die Auswirkungen komplexer Bash-Kommandos oft nur schwer überblicken. Ebenso ist nicht immer klar, welche Informationen vom Entwicklerrechner in den Kontext der Unterhaltung gelangen. So liegen auf dem Entwicklerrechner oft SSH-Keys und andere Credentials, Werte in Umgebungsvariablen und Daten anderer Projekte, die nicht nach außen gelangen sollten.
Insbesondere wenn auf einem Rechner Projekte unterschiedlicher Kunden entwickelt werden, ist eine zusätzliche Isolationsschicht sinnvoll um Problemen und unbefugtem Zugriff entgegenzuwirken. Eine Option den Zugriff und Aktionsmöglichkeiten auf den direkten Projektkontext zu beschränken ist es den Agenten in einem eigenen Container laufen zu lassen, in dem nur für das Projekt relevante Inhalte zur Verfügung stehen. Zur effizienten Problemlösung ist es allerdings hilfreich, wenn der Agent im Container das Projekt auch bauen und ausführen kann. Zusätzlich ist eine IDE-Integration zur besseren Übersicht der Änderungen oft wünschenswert.
An der Stelle kommen Dev Containers ins Spiel, deren Idee es ist, eine (im simpelsten Fall) per JSONC konfigurierte Entwicklungsumgebung, als Container bereitzustellen. Dabei handelt es sich um eine offene Spezifikation, die neben VS Code auch von anderen IDEs unterstützt wird. Eine einfache Entwicklungsumgebung für eine Java-Webanwendung auf Port 8080 mit Claude Code können wir in VS Code mit folgender Datei einrichten.
{
"name": "Claude Dev Container Demo",
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"features": {
"ghcr.io/devcontainers/features/node:2": {},
"ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {},
"ghcr.io/devcontainers/features/java:1": {
"version": "25",
"jdkDistro": "tem",
"installMaven": "true",
"installGradle": "false",
"mavenVersion": "latest"
}
},
"forwardPorts": [8080]
}
.devcontainer/devcontainer.json
Es kann alternativ auch ein eigenes Image mit einem Dockerfile konfiguriert werden. Mithilfe von Features können bestimmte Konfigurationen aber auch an bestehenden Images vorgenommen werden. Hier ist allerdings zu beachten, dass nur vertrauenswürdige Quellen für Features genutzt werden sollten.
Auch IntelliJ liefert eine Unterstützung für Dev Containers, die Integration ist aber noch etwas schlechter als in VS Code. Im Native-Modus (aktueller Default) geöffenete Dev Container Projekte ermöglichen z.B. die IDE-Integration von Claude im Container nicht (Stand: IntelliJ 2026.2, Claude Code 2.1.289).
Damit nicht nach jedem Bauen des Containers der Login und Einstellungen von Claude zurückgesetzt werden, können wir diese zum Beispiel als Volume mounten. Falls gewünscht kann z. B. auch der Maven-Cache des Hosts mit dem Container geteilt werden. Wichtig ist an dieser Stelle natürlich bei jeder dieser Entscheidungen zu überlegen, welche weiteren Möglichkeiten und Zugriffe wir dem Agenten damit geben und ob diese gewünscht sind. Liegen in ~/.m2/settings.xml Credentials sollte der Ordner vielleicht nicht als Mount hinzugefügt werden. Eine isoliertere Alternative wäre ein separates Volume für den Cache.
[...]
"mounts": [
// Achtung, wenn ~/.m2/settings.xml Credentials enthält
{
"source": "${localEnv:HOME}${localEnv:USERPROFILE}/.m2",
"target": "/home/vscode/.m2",
"type": "bind"
},
// Claude config
{
"source": "claude_devcontainer-${devcontainerId}",
"target": "/home/vscode/.claude",
"type": "volume"
}
],
"containerEnv": {
"CLAUDE_CONFIG_DIR": "/home/vscode/.claude"
}
[...]
.devcontainer/devcontainer.json
Ein Problem ergibt sich z. B. bei der Entwicklung von Quarkus-Projekten. Ein viel genutzter Vorteil in Quarkus-Projekten ist der Dev-Modus, der automatisch Dienste wie Datenbank-Instanzen oder Authentifizierungsprovider in einer Containerumgebung starten kann, um mit minimaler Konfiguration eine produktionsähnliche Umgebung zur Entwicklung bereitgestellt zu bekommen. Damit innerhalb des Containers einfach weitere Container gestartet werden können, kann z. B. das docker-in-docker Feature verwendet werden. Dazu wird der Container auf dem Host allerdings als --privileged gestartet. Den Host-Socket direkt bereitzustellen (docker-outside-of-docker) ist noch weniger isoliert, letztlich erlauben aber beide Wege einem Prozess vom Container auf den Host zuzugreifen. Jede Erweiterung erhöht auch hier die Anzahl an Möglichkeiten, die einem Agenten im Container gegeben werden.
Insgesamt ist natürlich auch ein Betrieb im Container kein Garant dafür, dass ein darin ausgeführter Agent keine Nebeneffekte erzeugt. Schon ein einfacher Netzwerkzugriff genügt, um auch entfernte Systeme zu beeinflussen (Claude-Code Dokumentation um Netzwerkbeschränkungen einzurichten). Es erzeugt allerdings in jedem Fall eine klarere Trennung zwischen dem konkreten Projektkontext und anderen Inhalten auf dem Entwicklerrechner. Zugriffe und Möglichkeiten können effektiver eingegrenzt werden ohne darauf vertrauen zu müssen, dass das Harness unbefugte Zugriffe fehlerfrei unterbindet. Der Container ersetzt keine Permissions, er ergänzt sie.
Das Beispiel gibt es wie immer auch auf GitHub.