Etwas hat sich in meiner Art zu programmieren verändert. Nicht nur bei den Tools, die ich nutze – sondern auch in meiner Einstellung zur Arbeit selbst.
Es ist nicht wirklich ein Agent. Aber es fühlt sich so an.
Ich habe kürzlich darüber geschrieben, warum Kontext die fehlende Ebene in KI-gesteuerter Arbeit ist – die Idee, dass die Abfolge Daten → Analyse → Kontext → Aktion lautet und dass ohne Kontext selbst intelligente Systeme begrenzt bleiben. Du kannst diesen Beitrag hier lesen.
Claude Code ist ein gutes Beispiel dafür in der Praxis. Es ist kein wirklich autonomer Agent. Es plant keine mehrstufigen Strategien von selbst. Es verfügt standardmäßig nicht über ein sitzungsübergreifendes Gedächtnis. Aber wenn man ihm den richtigen Kontext gibt – die Codebasis, die Anforderungen, die Fehlerprotokolle, die Hardware-Spezifikationen – passiert etwas Interessantes. Es fängt an zu handeln, anstatt nur zu antworten. Es schreibt, führt aus, liest die Ausgabe, passt sich an und iteriert. Diese Rückkopplungsschleife – Code, Ausführen, Beobachten, Korrigieren – ist es, was es wie einen Agenten wirken lässt, auch wenn es technisch gesehen keiner ist.
Die Intelligenz war schon immer im Modell vorhanden. Was sie freisetzt, ist der Kontext. Und darum geht es in diesem Beitrag: darum, den richtigen Rahmen für diesen Kontext zu schaffen – im wörtlichen wie im übertragenen Sinne.
Die alte Methode war frustrierend
Ich habe schon früh angefangen, mit Claude Code zu experimentieren. Das Konzept ist großartig: Gib einer KI eine Aufgabe, lass sie Code schreiben, ihn ausführen, schau, was kaputtgeht, behebe es, wiederhole. Vollständig autonom.
Aber die Standarderfahrung war nervig. Ständige Bestätigungsaufforderungen. „Soll ich fortfahren?“ – ja. „Bist du sicher?“ – ja, mach es einfach. Das zerstört jegliches Gefühl von Flow.
Dann hörte ich von --dangerouslySkipPermissions. Das entfernt alle Sicherheitsbarrieren. Claude führt einfach aus. Was großartig klingt – bis dir klar wird, dass du einen autonomen KI-Agenten mit vollem Zugriff auf deinen eigentlichen PC laufen lässt. Dein Home-Verzeichnis. Deine SSH-Schlüssel. Alles.
Ich habe auch versucht, Claude auf einem isolierten Rechner zu laufen – einem alten Raspberry Pi –, was zwar funktionierte, aber umständlich war und keine richtige Entwicklungsumgebung bot. Keine langfristige Lösung.
Ein Schweizer auf YouTube hatte die richtige Idee
Ich bin zufällig auf dieses Video gestoßen. Andreas Spiess – seltsamer Akzent, tolle Ideen –, der Claude Code einfach in einer virtuellen Maschine installiert und dort mit vollen Berechtigungen ausgeführt hat. Saubere Isolation. Kein Risiko für den Host.
Die Richtung war richtig. Aber eine vollständige VM ist schwerfällig. Ich wollte etwas Leichteres, das schneller hochfährt und entwicklerfreundlicher ist.
Nach ein bisschen Recherche fand ich VS Code Dev Containers – und sie erwiesen sich als perfekte Lösung.
Was ist ein Dev Container?
Ein Dev Container ist einfach ein Docker-Container – aber mit einem speziellen .devcontainer/ Konfigurationsordner in deinem Projekt. Wenn du das Projekt in VS Code öffnest, erkennt es diese Konfiguration und fragt: „Im Container erneut öffnen?“
Du klickst auf „Ja“. VS Code öffnet sich erneut. Derselbe Editor. Dieselben Erweiterungen. Dasselbe Terminal. Aber jetzt läuft alles innerhalb von Docker. Der Container ist von deinem Host isoliert. Dein eigentliches Dateisystem, dein Home-Verzeichnis, deine anderen Projekte – unsichtbar und von innen nicht erreichbar.
Du merkst gar nicht, dass du dich in einem Container befindest. Genau darum geht es.
Das ist genau die Sandbox, die Claude Code benötigt, um sicher mit vollen Berechtigungen zu laufen.
Die Vorlage, die ich erstellt habe
Ich habe auf GitHub eine wiederverwendbare Vorlage erstellt – eine einsatzbereite Dev-Container-Konfiguration für Claude Code mit einem klaren Sicherheitsmodell und einer praktischen Projektstruktur.
Sicherheitsmodell – was geschützt ist:
- Host-Dateisystem: Nur der
./projectOrdner wird eingebunden – nichts anderes auf deinem PC ist innerhalb des Containers sichtbar - Kein
privileged-Modus: Der Container kann nicht in den Host-Kernel entkommen - SSH-Schlüssel: werden nie kopiert – der SSH-Agent-Socket des Hosts wird weitergeleitet, die Schlüssel bleiben auf deinem Rechner
- GitHub-Token: wird als Umgebungsvariable übergeben, niemals im Container gespeichert
- USB-Zugriff: Hot-Plug-Unterstützung für ESP32 und Arduino über
device_cgroup_rules– kein vollständiger/devZugriff erforderlich
Es gibt außerdem eine optionale Outbound-Firewall, die Claude auf Domains der Whitelist beschränkt (Anthropic API, GitHub, npm, VS Code). Ich lasse sie normalerweise deaktiviert und beobachte einfach, was Claude macht – aber sie ist da, falls du sie nutzen möchtest.
Die Projektstruktur – Der Kontext ist alles
Der Container bietet Claude einen sauberen, isolierten Arbeitsbereich. Aber der eigentliche Einblick liegt darin, was sich im project/ Ordner. Hier befindet sich der Kontext – und der Kontext ist es, der Claude Code von einer beeindruckenden Demo zu einem echten Werkzeug macht.
project/
CLAUDE.md ← session bootstrap: tells Claude what to read at startup
requirements.md ← what you're building — written by you, for Claude
memory.md ← live session memory — Claude writes here
skills/ ← working conventions, loaded every session
knowledge/ ← confirmed config and integration notes
external-docs/ ← raw reference material (API docs, specs)
src/ ← the actual source codeBei jeder Sitzung liest Claude CLAUDE.md zuerst. Diese Datei weist ihn an, requirements.md, alle Skill-Dateien und alle Wissensdateien zu laden, bevor er irgendetwas anderes tut. Claude kennt den vollständigen Projektkontext, bevor er auch nur eine einzige Zeile Code schreibt.
requirements.md ist die Schlüsseldatei – und sie zu schreiben ist jetzt deine Hauptaufgabe. Du schreibst keinen Code mehr. Du schreibst, was du willst. Du beschreibst die Funktion. Du denkst die Architektur durch. Du definierst Einschränkungen. Du legst das Verhalten fest. Claude liest es und setzt es um.
Das ist die Veränderung, die ich am Anfang erwähnt habe. Du wechselst vom Programmierer zum Architekten. Die Arbeit ändert sich – es geht nicht mehr um Syntax, sondern um klare Gedanken. Wenn du genau beschreiben kannst, was du willst, kann Claude es umsetzen. Wenn deine Anforderungen vage sind, wird auch das Ergebnis vage sein. Gutes Denken führt zu gutem Code.
Skills sind wiederverwendbarer Kontext. Eine Skill-Datei kann definieren, wie Code für ein bestimmtes Hardware-Board strukturiert werden soll, welche GPIO-Pins verfügbar sind, welche Bibliotheken verwendet werden sollen und welche Fallstricke zu vermeiden sind. Du schreibst den Skill einmal – und fügst ihn in jedes Projekt ein, das dieses Board verwendet. Claude arbeitet sofort effizienter, weil es die Umgebung bereits kennt, bevor du beginnst.
Wissensdateien sammeln Wissen. Wenn Claude eine knifflige Integration herausfindet – eine funktionierende Konfiguration für eine Bibliothek, eine bestätigte Pin-Zuordnung, ein getestetes Setup – schreibt es das in knowledge/. Bei der nächsten Sitzung startet es mit diesen bereits geladenen Informationen. Kein erneutes Herausfinden.
Ein neues Projekt starten: Drei Schritte
Die Vorlage ist so konzipiert, dass sie pro Projekt kopiert wird. Ein Neuanfang geht schnell:
- Kopiere den Vorlagenordner und benenne ihn nach deinem Projekt
- Bearbeite
.env: SetzeCOMPOSE_PROJECT_NAMEauf einen eindeutigen Namen - Öffne den Ordner in VS Code → „Reopen in Container“ → gib den API-Schlüssel ein → starte Claude mit
--dangerouslySkipPermissions
Jedes Projekt erhält einen eigenen isolierten Container, ein eigenes Claude-Konfigurationsvolume und einen eigenen Shell-Verlauf. Keine gegenseitige Beeinflussung zwischen den Projekten.
Die ESP32-Rückkopplungsschleife – Hardware wird spannend
Der USB-Passthrough ist das, was Hardware-Projekte wirklich spannend macht.
Claude Code schreibt nicht nur Firmware – er flasht sie über USB auf den ESP32, liest das serielle Debug-Protokoll und reagiert automatisch auf Fehler. Der Kreislauf sieht so aus:
Code schreiben → flashen → serielle Ausgabe lesen → Fehler beheben → erneut flashen.
Und das alles, ohne dass ich etwas anfassen muss. Claude steuert den gesamten Zyklus.
Ich arbeitete an einem Touchdisplay-Projekt. Claude konnte den Bildschirm natürlich nicht sehen. Also fragte es mich einfach: „Ich kann das Display nicht sehen. Sieht es richtig aus? Sag einfach Ja oder Nein.“ Ansonsten war es vollkommen zufrieden damit, den Debug-Port auszulesen und selbstständig zu iterieren.
Diese Rückkopplungsschleife ist die konkrete Hardware-Version desselben Prinzips aus meinem anderen Beitrag. Das Modell ist intelligent. Aber was es zum Handeln bringt, ist der Kontext: der Code, das Fehlerprotokoll, die serielle Ausgabe, die bestätigte Hardwarekonfiguration in knowledge/. Nimm irgendetwas davon weg, und die Schleife bricht ab.
Echte Projekte, die so umgesetzt wurden
Das ist keine Theorie. Ich habe dieses Setup verwendet, um mehrere echte Projekte zu realisieren:
- Soundbox – Hardware-Audio-Projekt mit ESP32: Claude hat die Firmware geschrieben, sie per USB geflasht, das serielle Protokoll gelesen und autonom debuggt
- PyLearn – eine Python-Lern-App, hier auf 44-2.de gepostet – an ein paar Abenden erstellt
- Eine Firefox-Erweiterung, die die Perplexity-Chat-Seitenleiste auf die gesamte Bildschirmbreite erweitert – an einem Abend fertig
Projekte, für die ich früher Wochen gebraucht hätte, dauern jetzt zwei oder drei Abende. Und die Codequalität? Ehrlich gesagt, mindestens so gut wie meine. Oft besser strukturiert. Manchmal besser dokumentiert, als ich mir die Mühe gemacht hätte.
Vorsicht
Ein paar echte Risiken, die du kennen solltest:
- API-Kosten: Claude ruft die Anthropic-API frei aus dem Container heraus auf. Lege ein Ausgabenlimit auf console.anthropic.com fest – im Ernst, tu das, bevor du anfängst.
- Git-Push-Risiko: Claude hat Zugriff auf deinen weitergeleiteten SSH-Schlüssel und kann Remote-Branches pushen oder löschen. Schütze deine wichtigen Branches auf GitHub oder richte
ENABLE_GIT=falsein.env. - USB-Sicherheit: Das
/devDateisystem ist für die USB-Unterstützung als Bind-Mount eingebunden. NurttyACMundttyUSBGeräteklassen sind über cgroup-Regeln zugänglich – aber sei dir bewusst, was du damit aktivierst. - Firewall-Umgehung: Wenn du
NET_ADMINfür die optionale Firewall, könnte Claude theoretisch seine eigenen iptables-Regeln löschen. Akzeptabel, wenn du dem Modell vertraust. Entferne die Fähigkeit, wenn du das nicht tust.
Die Container-Isolation ist sehr gut. Es ist keine Zauberei. Sei dir der Kompromisse bewusst.
Was kommt als Nächstes
Ein paar Dinge, die ich untersuchen möchte:
- Mehr Skill-Dateien für verschiedene Hardware-Boards – ESP32-S3, RP2040, verschiedene Arduino-Varianten – jeweils mit Pinbelegungen, bewährten Bibliotheken und bereits geladenen Fallstricken
- Bessere Firewall-Profile: projektspezifische Zulassungslisten statt einer globalen Liste
Der tiefergehende Gedanke dahinter ist, dass Skill-Dateien zu einer Community-Ressource werden könnten. Teile den Skill für dein Board, dein Framework, dein Setup – und die Claude-Sitzungen aller werden sofort smarter in Bezug auf diese Umgebung.
Die Vorlage findest du auf GitHub: happychriss/claude-code-container
Kopiere sie. Bearbeite requirements.md , ändere die .env-Datei mit deinem Projektnamen und aktualisiere bei Bedarf dein USB-Gerät. Beschreibe, was du erstellen möchtest (und wenn du möchtest – welche Plattform oder Sprache). Schau zu, was passiert.