Eine Sandbox für Claude Code: Isolierte Agentenumgebungen auf einem Laptop

Wenn ein Neustart das Arbeitsgedächtnis löscht

Stellen Sie sich sechs oder sieben gleichzeitig geöffnete Claude Code-Sessions vor. Einige laufen in Terminals, ein paar im VS Code, eine weitere in IntelliJ – schließlich arbeitet das Team in mehreren Programmiersprachen und hat jeweils seinen Lieblingseditor. Sie bearbeiten unterschiedliche Repositories, verschiedene Aufgaben sowie verschiedene halbfertige Ideen. Dann wird der Laptop neu gestartet.

Am Code selbst liegt nichts falsch. Verloren geht lediglich der Überblick über alles: Welche Session war mitten in einer Refaktorierung, welche wartete auf einen Build, welche hatte eine Frage gestellt, deren Antwort nie gelesen wurde. Zwanzig Minuten vergehen damit, das Arbeitsgedächtnis aus der Shell-Historie sowie unvollständigen Git-Branches wiederherzustellen. Zu diesem Zeitpunkt beginnt ein schlechter Tag wie ein Designproblem auszusehen.

Der Neustart war nur das auffälligste Symptom. Drei verschiedene Faktoren zermürbten die Systeme allmählich.

Shuffling. Agenten sind günstig in der Einrichtung, aber teuer im Überwachen. Jeder neue Agent benötigt ein weiteres Terminalfenster, ein weiteres Editor-Fenster sowie Platz im Gedächtnis des Nutzers. Der Laptop verwandelt sich so in einen Haufen Fenster, wobei der Mensch die einzige Integrationsstufe darstellt. Bestehende Tools gehen davon aus, dass es einen Agenten, eine Aufgabe und eine Person gibt, die alles überwacht – doch so läuft die Arbeit in Wirklichkeit nicht.

Das Berechtigungs-Dilemma. In der Standardkonfiguration wird dieses Problem nicht gelöst. Claude Code verlangt Genehmigung für Tool-Aufrufe, fragt den Nutzer jedoch manchmal nach Kleinigkeiten, während er über Aufrufe, die echten Schaden anrichten könnten, schweigt. Das Verhalten hat sich zwar verbessert, doch das grundlegende Problem bleibt bestehen, da der Agent als Vertreter des Nutzers agiert und dessen Berechtigungen besitzt. Ein GitHub-Organisationsadmin kann schließlich nicht sinnvoll jeden API-Aufruf genehmigen und auch nicht so tun, als wäre eine einzige Genehmigung harmlos.

Zwei Wege bleiben. Sie können weiterhin eine Allow-Liste anpassen, bis sie zu einem privaten Dokument wird, das kein Kollege entschlüsseln kann, oder Sie können --dangerously-skip-permissions aktivieren und auf Glück vertrauen. Die Schauergeschichten stammen vom zweiten Weg – wie zum Beispiel der Agent, der eifrig eine Produktionsdatenbank bereinigte. Beide Ansätze scheitern aus demselben Grund: Der Agent trägt Ihre Identität mit sich, und das Einzelgenehmigen von Befehlen hilft nur vorübergehend dagegen.

Installationsmüdigkeit. Mehrere Repositories auf verschiedenen Umgebungen führen zu einem fehlenden JDK, dem falschen Node, diesem oder jenem SDK, einer CLI sowie einer vor einem halben Jahr festgelegten Version, die heute niemand mehr erklären kann. Jeder Wechsel der Arbeitsumgebung kostet Zeit, die man mit dem Beobachten eines Paketmanagers verbringen muss. Das Problem verschärft sich, wenn ein Laptop verloren geht oder ersetzt werden muss, da jede Umgebung Werkzeug für Werkzeug neu aufgebaut werden muss. Nach Monaten der Anpassung einer bevorzugten Coding-CLI bleibt unklar, ob die Konfiguration überhaupt noch reproduziert werden kann oder man von vorn anfangen und hoffen muss, sich die wichtigen Teile noch zu erinnern.

Eine eigene Maschine für den Agenten

Es begann nicht als Plattformprojekt. Capsule war ein persönliches Werkzeug, das entwickelt wurde, um die Woche eines Ingenieurs etwas angenehmer zu gestalten. Die Idee war einfach: Dem Agenten eine eigene Maschine geben – nicht Ihre –, auf der er weder Ihren Dateisystemzugriff hat noch Ihre Anmeldedaten nutzen kann, und bei der es nicht unverantwortlich ist, einfach „Machen Sie weiter, fragen Sie nicht“ zu sagen. Zudem musste es kostengünstig genug sein, damit mehrere davon problemlos gleichzeitig laufen konnten.

Kollegen bemerkten es und baten um eigene Instanzen, anschließend taten andere dasselbe. Es wuchs über seine ursprüngliche Funktion als Werkzeug einer einzigen Person hinaus und öffnet sich heute morgen auf den Bildschirmen immer mehr Ingenieure – von einigen frühen Nutzern auf einige Dutzend, wobei der größte Teil der Ingenieurgruppe vermutlich bald folgen wird. Niemand wird dazu gezwungen, es zu verwenden; die Leute übernehmen es, weil dadurch die Arbeit einfacher wird – das einzige glaubwürdige Zeichen für eine Übernahme. Ein Neuzugang installiert Capsule auf einem Laptop und kann bereits ab dem ersten Tag vollständig autonom arbeiten.

In einem Satz ausgedrückt bietet Capsule Claude Code einen abgeschirmten, fertiggestellten Sandbox, in dem es selbstständig an Ihren Repos arbeiten kann, sodass es nicht mehr mit Ihrem vollen Berechtigungssatz läuft.

Das Bild zeigt die Capsule Station. Die Kapseln sind entlang der linken Kante aufgelistet, die Terminal des ausgewählten Agenten befindet sich in der Mitte, und die Pull Requests, die Ihnen gehören oder die Sie überprüfen sollen, sind unten links zu finden – somit gibt es ein einziges Fenster für die gesamte Flotte.

Ihr Anwendungsbereich ist absichtlich begrenzt. Es handelt sich weder um ein Framework zur Orchestrierung von Agenten noch um ein Produkt für mehrere Agenten – zumindest vorerst, obwohl bald einige Orchestrierungsfunktionen hinzukommen könnten. Es ist weder eine IDE noch bietet es Integrationen für Plugins oder Editor, und es ersetzt oder spaltet Claude Code nicht, da das, was darin läuft, einfach nur Claude Code ist, das auf bestimmte Weise konfiguriert wurde. Es ersetzt auch keine CI/CD-Systeme und ist kein SaaS-Dienst, da alles auf Ihrem Laptop abläuft.

Dieser letzte Punkt erwies sich als wichtiger, als erwartet. Da es keine Gebühr pro Sitzplatz gibt und nichts laufen muss, kostet eine zehnte Kapsel genauso viel wie die erste – dadurch wird paralleles Arbeiten von einem Luxus zur Routine. Die Maschine ist bereits bezahlt, und die Repositorien bleiben auf dem Hardware-Gerät, wo sie begonnen haben.

In einer Kapsel läuft Claude mit --dangerously-skip-permissions und fragt niemals, ob es einen Befehl ausführen darf. Seine einzigen Fragen betreffen die Absicht, also was zu tun ist, niemals jedoch die Berechtigung. Dieser vernünftige Standard existiert nur aufgrund von zwei zugrunde liegenden Faktoren.

Der Sandkasten

Jede Kapsel fungiert als Pod im Kubernetes-Cluster, den OrbStack bereits auf dem Mac bereitstellt. Dadurch bleibt alles lokal – es werden keine zusätzlichen Infrastrukturen benötigt und es entstehen keine Cloud-Kosten. Auf das Host-Dateisystem ist kein Zugriff möglich, und zwei deklarierte Volumes speichern dauerhafte Daten: ein Arbeitsbereich sowie ein Docker-Image-Cache. Drei Ebenen begrenzen den Ausgangsverkehr:

• Kernel-iptables-Regeln blockieren die direkten Ausgangsportale 80 und 443 für die Benutzer-ID des Agents.
• Eine Kubernetes NetworkPolicy beschränkt den verbleibenden Verkehr auf DNS, 80 und 443.
• Alles, was übrig bleibt, wird durch einen Squid-Proxy geleitet, der eine explizite Domain-Allowliste durchsetzt.

Die Allowliste umfasst GitHub, npm, Maven, ECR sowie die Anthropic-API; alle anderen Ziele werden standardmäßig abgelehnt. Ein Agent hat keinen einfachen Weg, auf einen beliebigen Endpunkt zuzugreifen und seine Quelldateien hochzuladen – dazu wäre echte Kreativität erforderlich.

Drei Ebenen verhindern den Datenabfluss: zuerst die Kernel-Regeln, anschließend die Netzwerkrichtlinie und zuletzt der Allowlisting-Proxy.

Beschränkte Berechtigungen für Anmeldedaten

Hier liegt der eigentliche Wert. Die Authentifizierung erfolgt auf dem Host unter Ihrem eigenen Namen mit allen üblichen Rollen. Diese Rollen bleiben im macOS Keychain und gelangen niemals in die Capsule. Stattdessen erstellt der Host einen eng begrenzten, kurzlebigen Token und injiziert diesen:

• einen temporären AWS STS-Anmeldedaten-Token, der auf eine nur zum Lesen geeignete Produktionsrolle beschränkt ist
• einen GitHub-Token, dessen Berechtigungen vor der Verwendung überprüft werden
• einen nur zum Lesen geeigneten BigQuery-Dienstkontoinhaber, den der Agent vortäuscht, sodass Ihre eigenen Anmeldedaten nicht betroffen sind

Wenn man etwas Breiteres anbietet, wie eine SSO-Produktions-Administratorenrolle oder einen Token mit zusätzlichen Berechtigungen, weigert sich der Host, diesen überhaupt einzusetzen. Schutz ist die Standardhaltung, und von innen aus hat der Agent keine Möglichkeit, sich erneut zu authentifizieren oder auf umfassendere Zugriffsrechte zuzugreifen. Die Identität bleibt erhalten, sodass das Audit-Log die Anfrage weiterhin Ihnen zuordnet, doch was beschädigt werden kann, beschränkt sich auf die Rolle und betrifft Sie nicht.

Man meldet sich auf dem Host selbst an, und der Agent erhält lediglich einen eng gefassten, kurzlebigen Token, der daraus erstellt wird. Dieser Kompromiss sorgt dafür, dass alles andere funktioniert. Dass ein Agent unüberwacht laufen darf, beruht nicht darauf, ihm mehr zu vertrauen, sondern darauf, den schlimmsten Fall unbedeutend zu machen.

Reibungsverlust beseitigen

Sicherheit gewährt die Erlaubnis, autonom zu handeln, macht das Erlebnis aber nicht besser. Der größte Teil der Anstrengungen galt der Beseitigung von Reibungsverlusten.

Das Basismodell, von dem die Kapseln starten, enthält bereits festgelegte Versionen der Toolchains: Go, Rust, Node, das JDK, Maven, sbt und Scala. Zusätzlich läuft ein Docker-in-Docker Sidecar, das jeder Kapsel ihren eigenen lauffähigen Docker bereitstellt, sodass Integrationstests und Testcontainers-Suiten ohne Beeinflussung der Nachbarkapseln ausgeführt werden können. Ebenfalls verfügbar sind eingeloggte Kommandozeilenwerkzeuge, nämlich die GitHub CLI, AWS CLI, gcloud und bq. Aus der Box heraus sind außerdem Sprachserver vorhanden (Metals, jdtls, gopls, rust-analyzer, vtsls), die es dem Agenten ermöglichen, mithilfe von Funktionen wie go-to-definition, find-references und Aufrufhierarchien gezielt durch den Code zu navigieren, anstatt blind nach Mustern zu suchen.

Caches für Abhängigkeiten werden über ein Host-Volumen zwischen den Kapseln geteilt. Das klingt nach einer unwichtigen Kleinigkeit, ist es aber nicht. In der ersten Version lud jede neue Umgebung alles erneut herunter, und ein Tool, das vor jeder Aufgabe zwanzig Minuten mit Maven verbringt, wird nicht übernommen. Heute wird eine bereits vorbereitete Kapsel in etwa zwanzig bis dreißig Sekunden bereitgestellt.

Was das Verhalten des Agents am meisten veränderte, war ein echter Feedback-Zyklus. Eine interne Plattform-CLI läuft innerhalb der Kapsel: Das SSO-Token des Hosts wird überprüft, in seinem Umfang eingeschränkt und injiziert, wodurch der Agent eine Sandbox-Umgebung erstellen kann, die gerade erstellte Branch bereitstellen sowie dort Smoke-Tests durchführen kann. Auch das Integrationstest-Tool läuft darin, zieht echte Bilder heran und startet tatsächliche MySQL-, Kafka- und Cassandra-Instanzen im Sidecar. Zunächst ist die Leistung langsam, da die Bilder über den Proxy geleitet werden müssen, danach jedoch schnell. Das unterscheidet einen Agenten, der plausiblen Code erzeugt, von einem, der melden kann, ob der Code funktioniert.

Auch die Abfragemöglichkeit ist bereits integriert. Jede Kapsel verfügt über ein internes MCP-Gateway, das ausschließlich zum Lesen dient und einige Dutzend Tools anbietet. Es ermöglicht den Zugriff auf Protokolle von Services und Pods, Metriken über PromQL und Thanos, Grafana-Dashboards, Kubernetes-Ereignisse, den Status von CI-Builds, Informationen darüber, wer im Bereitschaftsdienst ist und welche Alarme ausgelöst werden, Angaben zur Serviceverantwortung sowie Suchfunktionen in Confluence und Slack. Da nichts geschrieben werden kann, barg das Einrichten dieser Funktion überall keinerlei Risiko. Ein Plugin-Marktplatz bietet zudem Teamfähigkeiten für Maven-Builds, Service-Scaffolding, Sandbox-Management und PR-Überprüfungen, sodass die internen Richtlinien dem Agenten bereits von Minute eins an vertraut sind.

Hier ist eine Gewohnheit, die es wert ist, übernommen zu werden. Halten Sie ein privates Repository mit persönlichen Slash-Befehlen und Planvorlagen bereit – Capsule wird es in jede erstellte Umgebung klonen. So folgt Ihnen Ihr eigener Arbeitsablauf stets. Pläne und Erinnerungen werden ebenfalls über dieses Repository zwischen den Kapseln übertragen, und eine Übergabefunktion kann festhalten, wo eine Sitzung endete, sowie die Zusammenfassung speichern, sodass die nächste Kapsel mit Kontext startet und nicht von vorne beginnen muss. Es handelt sich dabei um ein gewöhnliches Git-Repository, sodass der Agent auch seine eigenen Tools verwalten kann – bereits eine Anweisung wie „Füge einen Build- und Test-Befehl hinzu, commite ihn, pushe ihn“ reicht aus.“

Parken ist besser als neu anfangen

Es trat eine unerwartete Folgeerscheinung ein. Da es nun kostengünstig ist, isolierte Agenten zu erstellen, und jeder von ihnen weiterhin existiert – unabhängig davon, ob jemand zuschaut oder nicht – wird die Arbeit nicht mehr einzeln durchgeführt.

An einem typischen Nachmittag sind vier oder fünf Kapseln aktiv. Eine arbeitet ohne Benutzerinteraktion an der Behebung eines Fehlers, eine dient für eine SSH-Sitzung zum echten Pair Programming, eine führt einen instabilen Integrationstest erneut aus und öffnet bei Bestehen einen Pull Request, und eine bearbeitet mühsam ein Problem mit Abhängigkeitsänderungen, das niemand verfolgen möchte. Etwa zehn weitere bleiben gestoppt: eine Idee, zu der man zurückkehren könnte, ein Experiment, das auf interessante Weise fehlgeschlagen ist, ein Design, das nur halb überlegt wurde. Das Stoppen bewahrt Repositorien, Sitzungen und Caches, und das Wiederaufnehmen dauert nur Sekunden – somit wird ein Gedankengang nicht einfach deshalb aufgegeben, weil er heute keine Priorität hat.

Der teure Teil war nie der Start der Arbeit, sondern das Aufhalten derselben. Und wenn etwas fertig ist, löscht man die Kapsel – ohne Chaos im Git-Worktree und ohne Aufräumarbeiten – wodurch alle Nebenprodukte gleichzeitig verschwinden.

Vollständige Autonomie beseitigt alle verbleibenden Hindernisse. Es gibt keine Bestätigungsanfrage für eine git-Befehl, kein Durchsuchen von Browsertabellen nach einer Zahl auf einer CI-Seite und keine Suche im Build-Log nach der entscheidenden Zeile. Der Agent erledigt die Aufgabe, und dank Sandbox sowie eingeschränkter Token führt das nicht einfach zu Glücksspiel.

Vier Kapseln, vier Zustände – keiner muss auf den Menschen warten.

Ein einziger Engine verfügt über zwei Modi. Man kann neben dem Agenten in einer interaktiven tmux-Sitzung arbeiten oder ihm eine Anweisung geben und ihn danach in Ruhe lassen.

Deshalb war die Benutzeroberfläche so effektiv. Die CLI war zwar leistungsstark, doch das wiederholte Ausführen von list, ssh und status in einer Terminalanwendung ist keine geeignete Methode zur Verwaltung einer Flotte. Capsule Station schließt diese Lücke mit einem einzigen Fenster: Die Kapseln sind in einer Seitenleiste zu sehen, für jede gibt es ein eingebettetes Terminal, sowie Pull-Requests und Überprüfungsanfragen daneben. Das Wechseln zwischen Agenten erfolgt wie das Wechseln von Browsertabellen. Die App nutzt Tauri, wiegt etwa zehn Megabyte und stützt sich auf den System-Webview – schließlich sollte das Anzeigen einer Liste nicht einen vollständigen Chromium-Browser sowie ein Gigabyte Speicherplatz erfordern. Sie bleibt in der Regel den ganzen Tag über geöffnet, während das IDE dies nur selten tut.

Ebenso zu Recht lässt sich sagen, was unberührt bleibt: Die Qualität des generierten Codes verbessert sich nicht. Was verschwindet, ist die damit verbundene Arbeit – das Umordnen, Genehmigen, Installieren, Neuauthentifizieren sowie das Verlieren des Überblicks, was sich als größte Hürde herausgestellt hat.

Warum bauen statt kaufen

Hostete Lösungen existieren tatsächlich und werden immer besser – beispielsweise Cloud-Agent-Sandboxen von verschiedenen Anbietern sowie Agenten, die für Sie remote laufen. Sie bringen kein Betriebsaufwand mit sich und ermöglichen echte Skalierbarkeit. Doch Code und Zugangsdaten verlassen Ihr Sicherheitsumfeld, die Toolchains sind generisch, wodurch lange Ladezeiten bei großen Codebasen entstehen, und ein internes Identitätsmodell lässt sich nicht umsetzen. Es gibt auch Open-Source-Projekte wie Kubernetes-native Sandboxen, Dev-Container-Tools sowie lokale Sandboxing-Primitiven, die von Anbietern bereitgestellt werden. Sie sind anbieterunabhängig und auf solide Primitiven basierend, bleiben aber auf niedriger Ebene, wodurch Sie für das Image, die Authentifizierung sowie die gesamte Benutzererfahrung verantwortlich sind. Bei jeder Option stellt sich die berechtigte Frage, ob sie in sechs Monaten noch gewartet wird – schließlich starten alle irgendwelche Initiativen, doch nur wenige halten lange an.

Das Gebäude befand sich zwischen den beiden. Die Kapsel besteht größtenteils aus Komponenten, wobei DevPod für den Entwicklungscontainer sowie das Lebenszyklusmanagement der Pods zuständig ist, Squid für den Ausgangsverkehr, das von OrbStack bereits bereitgestellte Kubernetes-Cluster sowie ein benutzerdefiniertes Arbeitsumgebungsimage, die vom Host vermittelte Authentifizierung und Station als oberste Schicht. Die Abhängigkeit bleibt gering, und Komponenten können ausgetauscht werden. Dies passt zum Codebase- und Authentifizierungsmodell, wobei der Code weiterhin auf dem Laptop bleibt – abgesehen von dem, was der Agent an die Modell-API sendet, wie bei jeder anderen Option hier auch.

Anmeldeinformationen werden auf dem Host erstellt, während alles, was der Agent berührt, in einem Pod hinter einem Proxy mit einer Allow-Liste läuft.

Ein weiterer Vorteil ist die Flexibilität, die sich als wichtiger herausstellte, als erwartet. Wenn jemand eine Funktion wünscht, erstellt er einen Pull Request und diskutiert sie – anschließend wird sie implementiert. Niemand verbringt drei Wochen damit, einem Produktmanager zu erklären, dass sie vielleicht in die Roadmap des nächsten Jahres aufgenommen werden könnte.

Das Risiko ist real und muss erwähnt werden: Das Team trägt die Verantwortung dafür, und es handelt sich im Grunde um ein Ein-Personen-Projekt mit Unterstützung des Unternehmens. Die Entwicklung war noch nie günstiger, doch die Wartungskosten bleiben das eigentliche Unbekannte. Niemand hat bisher eine Antwort darauf.

Was kommt als Nächstes

Vor uns liegt eine ausgeweitete Einführung von Dutzenden Nutzern auf die gesamte Organisation, mehr Funktionen und Tools, die direkt in das Image integriert werden, sowie weitere Anbindungen. Letzteres ist schwieriger, als es klingt, da für jede Anbindung eine klare Regelung erforderlich ist, was ein Agent im automatisierten Modus damit tun darf. Nur Leserechte sind einfach umzusetzen, doch jegliche Schreibfunktion erfordert eine gründliche Diskussion sowie eine Möglichkeit, zerstörerische Aktionen zu kennzeichnen. Die Fernsteuerung ist mit Abstand die am meisten gewünschte Funktion, sodass die Kapseln auch mit geschlossenem Laptop weiterlaufen könnten.

Warnung vor Sicherheitslücken

Das System ist absichtlich defensiv gestaltet, und sein Aufbau bringt eine unangenehme Lektion mit sich: Ein Werkzeug, das Agenten Autonomie gewährt, stützt sich am stärksten auf die Schwachstellen eines Sicherheitsmodells. Eine gute Zugriffskontrolle erleichtert die Integration, während ihr Fehlen sofort Schäden verursacht und genau erklärt, warum.

Trotzdem hat eine Sandbox ihre Grenzen. Das Ausführen eines Agenten mit vollständigen Berechtigungen ist wie das Tragen geladener Waffen – egal ob abgefeuert oder nicht. Capsule beseitigt diese Probleme. Fügen Sie jedoch einen Admin-Token in das Chat-Fenster ein und weisen Sie den Agenten an, ihn zu verwenden, dann werden die volle Kontrolle und Berechtigungen wiederhergestellt.

Nun los – bauen!

Es sind bemerkenswerte Zeiten – man kann kaum überschätzen, was ein einzelner Ingenieur erreichen kann. Alles begann mit der Frustration einer Person an einem gewöhnlichen Nachmittag und entwickelte sich zu etwas, das immer mehr Kollegen jeden Morgen nutzen. Es gibt zwei Voraussetzungen: Man muss wissen, welches Problem gelöst werden soll, und man benötigt Unterstützung, da Tokens Geld kosten und jemand zustimmen muss, dass sie sich lohnen. Mit beidem hat sich die Aufgabe dauerhaft verändert – also finden Sie die Probleme und beheben Sie sie.