Ein Verpackungsfehler enthüllte 512.000 Zeilen TypeScript – und bestätigt, wie Agent-Systeme wirklich funktionieren
Am 31. März 2026 enthielt Version 2.1.88 des npm-Pakets @anthropic-ai/claude-code versehentlich eine 59,8 MB große Source Map sowie einen öffentlich zugänglichen Link zu einem Zip-Archiv auf Anthropics Cloudflare R2. Sicherheitsforscher Chaofan Shou entdeckte die Datei wenige Stunden nach dem Release und teilte sie auf X – der Post erreichte 28,8 Millionen Aufrufe, GitHub-Mirrors entstanden in Minuten.
Anthropic bestätigte: kein Hack, kein kompromittiertes System, sondern ein klassischer Build-Fehler. Ein fehlendes .npmignore-Eintrag, eine falsch konfigurierte files-Angabe in package.json – der Kompilierungsschritt ließ die Map-Datei im veröffentlichten Artefakt stehen.
Das Ergebnis: rund 1.900 TypeScript-Dateien, 512.000+ Zeilen Code, öffentlich lesbar.
Das eigentlich Interessante daran ist nicht der Vorfall selbst – Build-Fehler passieren. Interessant ist, was die Dateien über die Architektur moderner AI-Agenten verraten. Denn selten bekommt man einen so klaren Blick in ein produktiv genutztes System dieser Klasse.
Was wirklich im Source Code stand
Das technische Fundament
Claude Code läuft nicht auf Node.js, sondern auf Bun. Das Terminal-Interface ist mit React und Ink gebaut – klassische React-Komponenten, die ins Terminal rendern statt ins DOM. Schema-Validierung übernimmt Zod v4. Wer Claude Code täglich nutzt, interagiert mit einer React-Applikation (ausgerechnet React – aber das ist eine andere Geschichte: React ist kein Fortschritt).
Das ist keine exotische Wahl: Bun bringt deutlich schnellere Startzeiten als Node, Ink abstrahiert Terminal-Layout in ein bekanntes Komponentenmodell, Zod validiert jeden Tool-Input zur Laufzeit. Für ein CLI-Tool kommt ein weiterer Vorteil dazu: Bun verarbeitet Prozess-Signale wie SIGINT und SIGTERM robuster als Node – relevant für Tool-Calls, die bei Abbruch sauber aufräumen müssen, ohne den laufenden Prozess zu beschädigen.
~40 Tools, jedes mit eigenem Permission-Check
Der Kern des Systems ist eine Tool-Bibliothek mit rund 40 einzelnen Tools:
Jedes Tool hat ein eigenes Schema, eine eigene Risikoklassifizierung (LOW / MEDIUM / HIGH) und einen eigenen Permission-Gate. Die Bandbreite reicht von BashTool und PowerShellTool über NotebookEditTool für Jupyter-Notebooks bis hin zu LSPTool, das direkt mit Language-Server-Protokollen kommuniziert.
Es gibt vier Permission-Modi: default, auto, bypass und yolo. Der auto-Modus nutzt einen ML-basierten Classifier, der auf Basis von Gesprächsverläufen entscheidet, ob ein Tool-Aufruf automatisch genehmigt werden kann. yolo deaktiviert alle Checks vollständig – erkennbar als interner Test-Modus, nicht für Produktion gedacht. Die Risikoklassifizierung ist nicht nur pro Tool, sondern auch pfadabhängig: .git/-Verzeichnisse werden grundsätzlich als HIGH eingestuft, unabhängig davon, welches Tool zugreift. Schutzwürdige Dateien wie .gitconfig oder .bashrc erfordern explizite Zustimmung unabhängig vom Modus.
Was das bedeutet: Der Wert des Systems liegt nicht im Modell, sondern in dieser Orchestrierungsschicht. Ein besseres Modell mit schlechtem Tool-Layer ist weniger nützlich als ein mittelmäßiges Modell mit durchdachtem Routing, Fehlerhandling und Permission-System.
Memory: Simpel, aber wirkungsvoll
Das Memory-System schreibt in eine Datei – MEMORY.md. Die Einträge sind auf etwa 150 Zeichen pro Zeile begrenzt, der Index auf maximal 200 Zeilen (rund 25 KB). Diese kleine Datei liegt permanent im Kontext.
Der Konsolidierungsprozess heißt intern autoDream und läuft in vier Phasen:
Drei Bedingungen müssen gleichzeitig erfüllt sein, damit der Prozess überhaupt startet: 24+ Stunden vergangen, 5+ Sessions abgeschlossen, und ein Lock muss erfolgreich gesetzt werden können. Das verhindert, dass das System sich zu häufig selbst unterbricht.
Was das bedeutet: Kein magisches Langzeitgedächtnis. Keine neuronale Repräsentation von Wissen. Logs, Zusammenfassungen, Indizes. Effektiv, nachvollziehbar, selbst zu bauen.
Multi-Agent: Orchestrator koordiniert Workers
Claude Code kann als Koordinator fungieren, der parallele Worker-Agenten startet. Die Architektur folgt einem definierten Ablauf:
Workers kommunizieren über Task-Benachrichtigungen und gemeinsame Scratchpad-Verzeichnisse. Ein interner Kommentar aus dem Code wurde vielfach zitiert: “parallelism is your superpower”. Das ist kein Marketing-Satz – es ist ein Architekturprinzip.
Was noch im Code steckt (feature-flagged)
108 feature-gegatete Module sind im Code vorhanden, aber nicht aktiv. Die bemerkenswertesten:
KAIROS — ein persistenter Hintergrund-Agent-Modus mit einem 15-Sekunden-Blocking-Budget, der periodisch “Tick”-Prompts erhält und eigenständig entscheidet, ob eine Intervention sinnvoll ist. Eigene Tools: SendUserFile, PushNotification, SubscribePR. Nächstliegende Interpretation: ein Assistent, der im Hintergrund PR-Aktivitäten beobachtet und proaktiv informiert.
ULTRAPLAN — lagert langfristige Planung an Claude Opus aus, das in einem Cloud-Container bis zu 30 Minuten arbeitet, bevor der Plan zur Genehmigung vorgelegt wird.
Weitere Gates: VOICE_MODE, WEB_BROWSER_TOOL, DAEMON, AGENT_TRIGGERS.
Der oft zitierte “Undercover Mode” ist technisch banaler: Er aktiviert sich für Anthropic-Mitarbeiter in öffentlichen Repositories und passt Output-Stil und Metadaten an – unter anderem werden Co-Authored-By-Git-Metadaten entfernt und interne Codenamen versteckt.
Was der Leak über moderne Agent-Architektur bestätigt
1. Kein neues Paradigma – der aktuelle Standard
Die Architektur folgt einem Pattern, das seit 2023 dokumentiert und breit diskutiert wird: Tool-Calling + Planner + Memory + Permission-System. Claude Code ist keine Ausnahme, sondern eine professionelle Implementierung des Industriestandards.
Das ist eine wichtige Botschaft: Wer heute ein eigenes Agent-System baut, muss kein neues Paradigma erfinden. Die Grundzüge sind bekannt.
2. Komplexität liegt in der Orchestrierung, nicht im Modell
Das Leak macht deutlich, wo der eigentliche Engineering-Aufwand liegt:
- Welches Tool wird wann aufgerufen?
- Was passiert bei Fehler oder unerwarteter Rückgabe?
- Wie wird State über mehrere Schritte hinweg gehalten?
- Welche Retry-Logik greift wo?
Ein GPT-4-Level-Modell mit einer durchdachten Orchestrierungsschicht übertrifft oft ein besseres Modell mit naiver Kopplung. Die Architektur macht den Unterschied.
3. Memory ist pragmatisch gelöst
Es gibt keine versteckte Vektordatenbank, keine komplexe neuronale Speicherstruktur. Ein flaches Textfile mit strengem Size-Budget, ein Konsolidierungsprozess mit klaren Triggern. Das reicht für die meisten Anwendungsfälle – und es ist transparent, debuggbar und portierbar.
4. Agenten sind deterministischer als ihr Ruf
Durch strukturierte Tools, das Permission-System und explizite Plan-Schritte entsteht ein reproduzierbares Verhalten. Ein Agent, der jeden Schritt logt, jeden Tool-Call validiert und bei Unsicherheit pausiert, ist deutlich verlässlicher als ein Agent, der frei im Kontext denkt.
5. Asynchrone Jobs sind keine Ausnahme, sondern Voraussetzung
ULTRAPLAN mit 30 Minuten Planungshorizont, KAIROS als persistenter Hintergrundprozess – beide zeigen: Agenten, die längere Aufgaben übernehmen sollen, brauchen Job-Queue-Strukturen. Request/Response reicht nicht.
Was überinterpretiert wird
Ein paar Dinge aus dem populären Diskurs verdienen eine nüchterne Einordnung:
“Permanenter Assistent” – KAIROS ist feature-flagged, nicht produktiv. Das Muster erfordert Infrastruktur (Daemon, persistente Verbindung), die ein CLI-Tool nicht mitbringt.
“Dream System” – klingt mystisch, ist Batch-Summarization mit Triggerbedingungen. Der Name ist ein internes Label, keine Beschreibung einer emergenten Eigenschaft.
“Multi-Agent-Swarm” – im Code sind logisch getrennte Rollen, keine vollständig autonomen verteilten Agenten. Die Koordination läuft durch einen zentralen Orchestrator.
BUDDY – das Tamagotchi-Feature mit 18 Tierarten, Seltenheitsstufen und fünf Stats (Debugging, Patience, Chaos, Wisdom, Snark) ist real im Code. Es ändert nichts an der Architektur, aber es zeigt, dass Engineer-Teams bei aller technischen Komplexität Humor behalten.
Wie eine moderne Agent-Architektur aussehen kann
Was lässt sich konkret ableiten, wenn man ein eigenes System bauen möchte?
Sechs Prinzipien, die sich direkt aus dem Leak ableiten lassen:
Tools vor Prompting. Bevor man komplexe System-Prompts schreibt, sollte man klare, kleine Tools definieren. Ein Tool mit Schema ist testbarer und zuverlässiger als ein Prompt, der eine Aktion beschreibt. Das BashTool in Claude Code validiert Kommandos über Schema-Checks, bevor sie ausgeführt werden – ein Muster, das sich für jedes eigene Shell-Tool direkt übernehmen lässt.
Permission-System früh einbauen. Nachträglich einzubauen bedeutet, bestehende Tool-Aufrufe umzubauen. Als Grundlage von Anfang an kostet es wenig und verhindert Sicherheitslücken.
Memory simpel halten. Ein Textfile mit Größenbudget und Konsolidierungsprozess deckt den Großteil der Anforderungen. Vektordatenbanken sind sinnvoll für Retrieval über große Corpora, nicht für Session-übergreifendes Arbeitsgedächtnis.
Plan-Execute-Review als Grundmuster. Kein direktes Ausführen ohne Planung, kein Ausführen ohne Review-Schritt bei risikoreichen Operationen. Dieses Muster macht das Verhalten nachvollziehbar.
Asynchrone Jobs einplanen. Wer heute ein System ohne Queue baut, baut es für einfache Tasks. Sobald Aufgaben mehr als 30 Sekunden dauern oder nicht abgebrochen werden können, braucht man Job-Infrastruktur.
Feature-Gates von Anfang an. 108 gated Module in Claude Code zeigen: Auch Anthropic entwickelt Features, die nicht sofort produktiv gehen. Eine saubere Feature-Flag-Struktur erlaubt experimentelle Entwicklung ohne Produktionsrisiko.
Release-Hygiene. Der Vorfall selbst liefert das letzte Prinzip: Ein fehlendes .npmignore oder ein unvollständiges files-Feld in package.json reicht, um versehentlich internen Code zu veröffentlichen. Source Maps gehören in Build-Pipelines explizit aus dem Release-Artefakt ausgeschlossen – unabhängig davon, ob das Paket auf npm, als Binary oder als Worker deployed wird.
Auf einen Blick
Als Entwickler lassen sich aus dem Leak direkt umsetzbare Erkenntnisse ziehen – ohne den Code zu kopieren, nur die Muster zu übernehmen:
| Bereich | Leak-Erkenntnis | Dein Vorteil |
|---|---|---|
| Sicherheit | Per-Tool-Permissions mit ML-Classifier | Session-basierte Klassifizierung schützt vor unkontrollierten Tool-Aufrufen; yolo zeigt, wo die Grenze liegt |
| Memory | MEMORY.md mit 200-Zeilen-Budget | Kein Vector-DB nötig für Session-Memory; flache Datei ist debuggbar, portabel und versionierbar |
| Multi-Agent | Orchestrator koordiniert parallele Workers | Zentrale Koordination statt losem Swarm – skalierbar ohne Kontrollverlust |
| Feature Flags | 108 gated Module (KAIROS, ULTRAPLAN) | Experimentelle Features isoliert entwickeln, kontrolliert ausrollen – kein Big-Bang-Release |
| Release-Hygiene | .npmignore fehlte im Build | Source Maps und interne Artefakte explizit aus jedem Release-Artefakt ausschließen |
Einordnung
Der Vorfall ist für Anthropic unangenehm, für den Rest der Branche aber ein seltenes Dokument: eine produktiv eingesetzte, in Millionen von Entwickler-Sessions erprobte Agent-Architektur, lesbar als TypeScript.
Die wichtigste Erkenntnis ist keine technische Überraschung. Es gibt keine geheime Zutat. Das System ist gut engineered, durchdacht und konsequent gebaut – aber es folgt Mustern, die bekannt und nachbaubar sind.
Wer AI-Agenten entwickelt oder plant, kann diesen Leak als Architektur-Referenz nutzen: nicht um Code zu kopieren, sondern um zu verstehen, wo die echten Engineering-Entscheidungen liegen.