Mein KI-Coding-Assistent läuft in Docker – und das ist kein Zufall

Jul 18, 2026 ai coding agents docker claude code developer productivity containerization yolo mode workflow optimization ai tools

Warum ich meinen AI-Coding-Assistenten in Docker laufen lasse (Und warum du das auch tun solltest)

Lass uns ehrlich sein. Bei AI Coding Agents gibt es nur zwei Fraktionen: Die einen haben sämtliche Sicherheitsvorkehrungen deaktiviert und lassen den Agenten frei auf ihrer Maschine wüten. Die anderen sitzen vor dem Bildschirm und klicken alle dreißig Sekunden auf „Genehmigen" – als würden sie eine Zeitbombe entschärfen. Beide Ansätze sind auf ihre eigene Art furchtbar.

Ich war lange der Genehmigungs-Klicker. Und ja, das war verantwortungsbewusst. Aber es hat meine Produktivität massiv ausgebremst. Jedes Mal, wenn Claude Code einen Bash-Befehl ausführen, ein Package installieren oder eine Datei ändern wollte, wurde ich aus meinem Flow gerissen.

Dann hab ich Freunde beobachtet, die den umgekehrten Weg gegangen sind – volle YOLO-Methode, keine Sicherheitsnetze, nur Hoffnung und Gebet. Ehrlich gesagt hat mich das noch mehr beunruhigt. Diese Agenten sind mächtig, aber auch autonom genug, um echten Schaden anzurichten, wenn etwas schiefgeht.

Der Mittelweg, der alles verändert hat: Den Coding-Agenten in einem Container laufen lassen.

Die Grundidee

Anstatt den AI Coding Assistant direkt auf deinem Host-System zu betreiben, startest du ihn in einem Docker Container. Das Workspace-Verzeichnis wird als Volume eingebunden. Der Agent arbeitet innerhalb des Containers, wo seine destruktiven Fähigkeiten eingedämmt sind. Beschließt er, alles zu löschen? Kein Problem – er löscht das Dateisystem des Containers, nicht deine tatsächliche Maschine.

Das bedeutet: Du kannst Features wie --dangerously-skip-permissions tatsächlich nutzen, ohne den nervigen Gedanken, dass gleich dein Home-Verzeichnis verschwindet.

Lass mich zeigen, wie das funktioniert.

Claude Code in Docker einrichten

Der einfachste Startpunkt ist ein Dockerfile. Hier ist die Basis:

FROM node:20-bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends git curl ca-certificates && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://claude.ai/install.sh | bash

ENV PATH="/root/.local/bin:${PATH}"

WORKDIR /workspace

ENTRYPOINT ["claude", "--dangerously-skip-permissions"]

Einmal bauen:

docker build -t claude-code .

Dann mit gemountetem Arbeitsverzeichnis starten:

docker run -it -v "$PWD:/workspace" claude-code

Fertig. Claude Code läuft mit Zugriff auf deine Projektdateien. Der Container kann lesen, schreiben und ausführen – aber nur innerhalb des Workspaces. Dein eigentliches System bleibt untouched.

Das Authentifizierungs-Problem

Jetzt wird es spannend. Auf dem Mac speichert Claude Code Credentials im Keychain. Linux Container können damit nichts anfangen. Du brauchst also einen anderen Weg für die Authentifizierung.

Die Lösung: Ein API Token als Environment-Variable übergeben. Zuerst holst du dir das Setup-Token:

claude setup-token

Dann erstellst du ein kleines Entrypoint-Script, das das Token ausliest und die Credentials-Datei im Container beschreibt:

#!/bin/bash
echo "${ANTHROPIC_TOKEN}" > /root/.claude/credentials.json
exec claude --dangerously-skip-permissions

Beim Container-Start übergibst du einfach das Token:

docker run -it -v "$PWD:/workspace" -e ANTHROPIC_TOKEN="$(claude setup-token)" claude-code

Damit es bequem wird

Mal ehrlich – du willst das nicht jedes Mal abtippen. Leg dir einen Alias oder eine Shell-Funktion an:

cc() {
    docker run -it \
        -v "$PWD:/workspace" \
        -v "$HOME/.claude:/root/.claude" \
        -v "$HOME/.claude/skills:/root/.claude/skills" \
        -v "$HOME/.claude/settings.json:/root/.claude/settings.json:ro" \
        -e ANTHROPIC_TOKEN="$(claude setup-token 2>/dev/null)" \
        --env-file ~/.claude/env \
        claude-code "$@"
}

Was passiert hier:

  • Dein aktuelles Verzeichnis wird als /workspace eingebunden
  • Deine Claude-Konfiguration und Skills werden durchgeschleift
  • Environment-Variablen werden geladen (praktisch für API Keys, die der Agent braucht)
  • Du tippst einfach cc von überall und hast sofort einen funktionierenden Coding-Agenten

Was das NICHT abdeckt

Ich möchte hier ganz transparent sein. Containerisierung schützt deinen Host vor den Aktionen des Agenten. Was sie NICHT abfängt:

  • Prompt Injection Angriffe: Kann ein Angreifer beeinflussen, was der Agent sieht, könnte er ihn dazu bringen, deinen Code oder Secrets abzuzapfen
  • API Key Offenlegung: Der Agent hat weiterhin Zugriff auf alle Keys, die er in Workspace oder Environment finden kann
  • Netzwerkbasierte Angriffe: Der Container behält seinen Netzwerkzugang
  • Supply Chain Probleme: Bösartige Packages, die der Agent im Container installiert, bleiben bösartig

Was du gewinnst: Schutz vor „Ups, der Agent hat mein Home-Verzeichnis gelöscht" oder „er hat rm -rf / ausgeführt und jetzt ist alles weg". Für mich hat sich der Setup-Aufwand schon mehrfach gelohnt.

Ist das Overkill?

Ehrlich? Kommt drauf an. Für schnelle Skripte und einmalige Aufgaben nutze ich Claude Code weiterhin direkt mit den normalen Berechtigungs-Abfragen. Aber bei ernsthafter Feature-Entwicklung, Refactoring-Arbeiten oder wenn ich in einem Repo unterwegs bin, das mir wichtig ist? Die Container-Methode hat mir Stunden des genervten Klickens gespart und mir echtes Kopf-Freiheit gegeben.

Das Beste daran: Sobald du das Konzept verstanden hast, kannst du es anpassen. Verschiedene Coding Agents haben verschiedene Fallstricke – Credential-Speicherorte, Config-Formate, Entrypoint-Anforderungen – aber das Grundprinzip bleibt gleich: Isoliere den Agenten, gib ihm kontrollierten Zugriff auf deine Arbeit, und lass ihn laufen, ohne dass du ständig über seiner Schulter schaust.

Fazit

Wir befinden uns in einer interessanten Übergangsphase bei AI Coding Tools. Die konservativen Sicherheitseinstellungen gibt es aus gutem Grund – diese Agenten sind mächtig und autonom. Aber konservative Defaults bedeuten oft „entworfen für Leute, die das Tool ausprobieren" statt „entworfen für den täglichen professionellen Einsatz".

Containerisierung ist ein Weg, diese Lücke zu überbrücken. Es ist keine perfekte Sicherheit, aber praktischer Schutz, der dich die Produktivitätsgewinne dieser Tools wirklich nutzen lässt – ohne das ständige Berechtigungs-Whack-a-Mole.

Probier es aus. Sobald du den Alias eingerichtet hast und cc in dein Terminal tippst, um einen voll einsatzfähigen Coding-Agenten in Sekunden zu bekommen, gibt's kein Zurück mehr.


Wie sieht dein Setup für AI Coding Agents aus? Klickst du noch auf Genehmigen? Volle YOLO-Methode? Hast du einen Containerisierungs-Trick, der mir fehlt? Ich würde gerne hören, wie andere dieses Gleichgewicht finden.

Read in other languages:

HU IT FR ES DA ZH-HANS EN