Seit ich Claude Code & Co. in meinem Docker/CI-Alltag einsetze, kristallisieren sich immer wieder dieselben Probleme heraus. Kurzer Überblick, keine Theorie – alles selbst erlebt.

1. Zustand, den der Agent nicht sieht

Ein Agent kennt nur, was er über seine Tools abfragt. Ein Image wurde außerhalb seiner Session neu gebaut, ein Volume manuell gemountet, ein Container von Hand gestoppt? Der Agent merkt das nicht automatisch und arbeitet munter mit veralteten Annahmen weiter. Führt zu Debugging-Sessions, in denen der Agent ein Problem “löst”, das längst nicht mehr existiert – oder ein neues erzeugt, weil die reale Umgebung anders aussieht als sein letzter Tool-Call.

2. Destruktive Kommandos ohne Rückfrage

docker system prune, docker compose down -v, rm -rf in einem gemounteten Volume – ein Agent mit vollem Shell-Zugriff kann das genauso schnell ausführen wie ein ls. Ohne klare Guardrails (Freigabe-Schritt, eingeschränkte Berechtigungen) ist das der größte Blast-Radius im ganzen Setup. Bei mir gilt: alles, was Volumes oder laufende Container über die aktuelle Aufgabe hinaus betrifft, braucht eine explizite Bestätigung.

3. Secrets landen im Log

Agenten arbeiten viel mit Shell-Output. Ein docker exec mit einem Passwort als Env-Var, ein cat .env zum Debuggen, ein API-Key in einem Build-Argument – und schon steht das Secret im Tool-Output, in Logs, vielleicht sogar in der Konversation. CI/CD-Variablen maskieren hilft nur, wenn sie tatsächlich als solche markiert sind; im lokalen Agenten-Workflow gibt’s dieses Netz nicht automatisch. Disziplin: nie Klartext-Secrets in Kommandos, die der Agent selbst zusammenbaut.

4. Ad-hoc-Fixes statt Dockerfile-Änderungen

Ein Agent debuggt einen fehlenden Package, installiert es schnell per docker exec -it ... apt install, das Problem ist “gelöst” – aber nur im laufenden Container, nicht im Image. Nächster Rebuild, gleicher Fehler. Ohne explizite Anweisung, Änderungen ins Dockerfile zurückzuspiegeln, driftet der laufende Zustand vom reproduzierbaren Build auseinander.

5. UID/Permission-Chaos

Prozesse im Container laufen oft als root, erzeugte Dateien landen root-owned auf dem Host-Volume. Ein Agent, der im Container arbeitet und dann versucht, dieselben Dateien vom Host aus zu editieren, scheitert an Berechtigungen – oder schlimmer, umgeht das Problem mit chmod 777, was neue Probleme schafft, statt das eigentliche UID-Mapping zu fixen.

6. Verwaiste Container und Ressourcenverbrauch

Ein Agent startet einen Dev-Server detached zum Testen, vergisst ihn zu stoppen, macht dasselbe in der nächsten Session nochmal. Nach ein paar Wochen laufen fünf Instanzen desselben Ports-Konflikts gleichzeitig. Braucht explizite Aufräumroutinen oder zumindest eine Erinnerung im Workflow, nicht nur im Kopf des Agenten.

Fazit

Keiner dieser Punkte ist neu – das sind klassische Docker-Fallstricke. Der Unterschied mit Agenten: die Geschwindigkeit, mit der destruktive oder inkonsistente Aktionen passieren können, ist deutlich höher als bei manueller Arbeit. Die Lösung ist nicht “keine Agenten im Docker-Umfeld”, sondern klare Grenzen: Freigabe für alles Destruktive, Secrets nie im Klartext durch den Agenten, und die Erwartung, dass jede Änderung reproduzierbar im Dockerfile/Compose-File landet statt nur live im Container.