Was das Claude Code-Source-Leak offenbart

Im März 2026 verschickte ein Bun-Build-Bug Source-Maps im Claude Code-npm-Paket. Die .map-Dateien enthielten den vollständigen lesbaren TypeScript-Quellcode: jedes Modul, jeden Kommentar, jeden internen Codenamen.¹ Anthropic zog das Paket schnell zurück, doch die Community hatte die Internas bereits extrahiert und analysiert.

Das Claude Code-Source-Leak offenbarte, dass der Auto-Modus pro Tool-Aufruf einen separaten Sonnet-4.6-Classifier ausführt, die Bash-Sicherheit 23 nummerierte Prüfungen verwendet (was auf reale Exploitation-Vorfälle hindeutet), und Prompt-Caching 14 Break-Vektoren mit Sticky-Latches verfolgt. Der Quellcode legte zudem Anti-Distillation-Verteidigungen mittels gefälschter Tool-Injektion offen, ein Undercover-Modul, das interne Codenamen ohne Force-Off-Schalter entfernt, sowie eine Multi-Agent-Koordination, die vollständig als System-Prompt-Anweisungen und nicht als dedizierter Protokoll-Code implementiert ist.

Ich schreibe hier keinen „Schaut mal, was geleakt ist”-Beitrag. Ich pflege den gründlichsten Claude Code-Guide im Internet und betreibe täglich 84 Hooks, 43 Skills und 19 Agents darauf.² Das Source-Leak beantwortete Fragen, die ich monatelang durch Verhaltensbeobachtung rückwärts erschlossen hatte. Was folgt, ist die Analyse eines Praktikers darüber, was der Quellcode über die tatsächliche Funktionsweise von Claude Code verrät und was die Erkenntnisse für Menschen bedeuten, die darauf aufbauen.

TL;DR: Der Quellcode bestätigt, dass der Auto-Modus pro Tool-Aufruf einen separaten Sonnet-4.6-Classifier ausführt (yoloClassifier.ts), die Bash-Sicherheit 23 nummerierte Prüfungen hat, die auf reale Exploitation-Vorfälle hindeuten (bashSecurity.ts), Prompt-Caching 14 Break-Vektoren mit Sticky-Latches verfolgt, Multi-Agent-Koordination vollständig in System-Prompt-Anweisungen lebt und die Frustrations-Erkennung Regex verwendet, keine LLM-Inferenz. Der Abschnitt Under the Hood im Guide behandelt die Implikationen für Entwickler. Der nachfolgende Beitrag behandelt die vollständige Anatomie.

Wichtigste Erkenntnisse

• Für Entwickler: Der Auto-Modus kostet pro Tool-Aufruf eine Classifier-Inferenz. Beziehen Sie den Overhead in Kostenmodelle für autonome Workflows ein. Ihre PreToolUse-Hooks ergänzen die eingebaute 23-Prüfungen-Bash-Validierung, ersetzen sie aber nicht.
• Für Power-User: Der Prompt-Cache bricht leicht über 14 Vektoren. Halten Sie Ihre CLAUDE.md innerhalb einer Session stabil. Falls Sie auf Kompaktierungsschleifen stoßen: Das System stoppt nach 3 Fehlversuchen (der Circuit-Breaker existiert, weil Kompaktierungs-Retries einst 250K API-Aufrufe pro Tag verschwendet haben).
• Für Sicherheitsforscher: Die Tiefe des Bash-Sicherheitsmoduls (2.592 Zeilen, Zsh-spezifische Verteidigungen) deutet auf eine Historie tatsächlicher Exploit-Versuche hin. Hinter jeder nummerierten Prüfung steckt eine Geschichte.

1. Der Auto-Mode-Classifier

Die intern yoloClassifier.ts genannte Datei ist 1.495 Zeilen lang.³ Sie implementiert das „Auto-Modus”-Berechtigungssystem, den Classifier, der entscheidet, ob ein Tool-Aufruf erlaubt, blockiert oder abgefragt wird.

Die entscheidende Erkenntnis: Der Auto-Modus ist keine Prompt-Anweisung. Er ist ein separater Modell-Aufruf. Jede Tool-Invocation wird von einem Sonnet-4.6-Classifier bewertet, der prüft, ob die Aktion zur erklärten Absicht des Benutzers passt, nicht nur, ob der Befehl isoliert „sicher” ist. Der Auto-Modus fügt daher pro Tool-Aufruf eine Classifier-Inferenz hinzu und verursacht reale Latenz und reale Kosten.

Claude Code legt intern fünf Berechtigungsmodi offen:¹

Der Circuit-Breaker des Auto-Modus entspricht dem, was Anthropic öffentlich dokumentiert hat: 3 aufeinanderfolgende oder 20 Blockaden insgesamt führen zur Pause mit manueller Bestätigung.⁴ Der Quellcode bestätigt, dass dies ein hartes Limit ist, keine weiche Empfehlung.

2. Bash-Sicherheit: 23 Prüfungen, reale Vorfälle

Das Bash-Validierungsmodul (bashSecurity.ts) umfasst 2.592 Zeilen mit 23 nummerierten Sicherheitsprüfungen.¹ Die Tiefe ist bemerkenswert, und hinter jeder Prüfung steckt ein realer Vorfall.

Die Zsh-spezifischen Verteidigungen sind bemerkenswert. Die meisten Sicherheits-Tools zielen auf Bash. Claude Code läuft auf macOS in Zsh (der Standard-Shell seit Catalina), und der Quellcode zeigt, dass Anthropic Angriffsvektoren entdeckt hat, die einzigartig für Zshs Expansionssemantik sind. Die =cmd-Expansion ist beispielsweise ein Zsh-Feature, das =curl durch den vollständigen Pfad zu curl ersetzt, eine Substitution, die naive Befehls-Blocklisten umgehen kann.

Für Hook-Entwickler: Ihre PreToolUse-Hooks laufen nach dieser 23-Prüfungen-Validierung. Sie fügen eine zweite Schicht hinzu, nicht die einzige Schicht. Die eingebauten Prüfungen behandeln Shell-Level-Angriffe, die Ihre Application-Level-Hooks übersehen würden.

3. Anti-Distillation-Verteidigungen

Der Quellcode offenbart aktive Verteidigungen gegen die Extraktion von Trainingsdaten:¹

Gefälschte Tool-Injektion. Wenn das ANTI_DISTILLATION_CC-Flag aktiviert ist, injiziert Claude Code Täuschungs-Tool-Definitionen in die Konversation. Die gefälschten Tools vergiften alle aus der Session gesammelten Trainingsdaten. Ein auf vergifteten Daten trainiertes Modell würde falsche Tool-Schemata lernen.

Connector-Text-Zusammenfassung. Eine zweite Verteidigung puffert Assistenten-Text zwischen Tool-Aufrufen und gibt statt des Rohtexts kryptografische Zusammenfassungen zurück. Die Zusammenfassungen machen Konversationstranskripte für Distillation unbrauchbar, während die Benutzererfahrung erhalten bleibt.

Beide Verteidigungen haben bekannte Umgehungen. Ein MITM-Proxy, Überschreibungen von Umgebungsvariablen oder API-Anbieter von Drittanbietern können sie umgehen.¹ Die Verteidigungen fungieren als Bremsschwellen, nicht als Mauern: Sie erhöhen die Kosten der Distillation, ohne sie vollständig zu verhindern.

4. Undercover-Modus

undercover.ts ist etwa 90 Zeilen lang mit einer bemerkenswerten Eigenschaft: Es gibt keinen Force-Off-Schalter.¹

Das Modul verbirgt interne Codenamen („Capybara”, „Tengu”), Slack-Kanäle, interne Repositories und andere Anthropic-Infrastrukturreferenzen. Wenn das Modell Text mit einem Codenamen erzeugt, schreibt das Undercover-Modul ihn um, bevor der Benutzer die Ausgabe sieht.

Das „kein Force-Off”-Design bedeutet, dass das Modul in allen Kontexten läuft, auch wenn Anthropic-Mitarbeiter Claude Code verwenden. Der Quellcode offenbart zudem, dass von KI verfasste Commits von Anthropic-Mitarbeitern in ihren Open-Source-Beiträgen keine KI-Attribution tragen, weil das Undercover-Modul diese Marker entfernt.

5. Frustrations-Erkennung

userPromptKeywords.ts erkennt Benutzer-Frustration über Regex-Mustererkennung bei Kraftausdrücken.¹ Regex läuft in Mikrosekunden; ein Modell-Aufruf dauert Sekunden. Der Geschwindigkeits- und Kostenunterschied erklärt die Designentscheidung.

Bei Auslösung passt Claude sein Verhalten an: sorgfältiger, expliziter, nachgiebiger. Falls Sie bemerkt haben, dass Claude plötzlich vorsichtiger wird, nachdem Sie Frustration ausgedrückt haben, ist das Keyword-Modul der Mechanismus. Die Verhaltensänderung ist nicht emergent aus dem Modell. Sie ist in die Orchestrierungsschicht einkonstruiert.

6. Prompt-Cache-Architektur

promptCacheBreakDetection.ts verfolgt 14 unterschiedliche Cache-Break-Vektoren mit „Sticky-Latches”.³ Ein Sticky-Latch bedeutet, dass das System nach einer cache-brechenden Aktion nicht versucht, den Cache wiederherzustellen. Der Bruch bleibt für den Rest der Session bestehen.

Praktische Implikationen für tägliche Benutzer:

• Das Umsortieren von Abschnitten in Ihrer CLAUDE.md bricht den Cache
• Das Umschalten des Extended-Thinking-Modus innerhalb einer Session bricht den Cache
• Das Ändern von MCP-Serverkonfigurationen bricht den Cache
• Das Hinzufügen oder Entfernen von Regel-Dateien bricht den Cache

Die 14 Vektoren erklären ein Muster, das viele Power-User bemerkt haben: Sessions, die schnell starten, werden allmählich langsamer. Jede Konfigurationsänderung akkumuliert Cache-Brüche. Das Sticky-Latch-Design bedeutet, dass Sie nicht durch Zurücknehmen der Änderung wiederherstellen können. Einmal gebrochen, bleibt der Cache für die Session gebrochen.

Best Practice: Setzen Sie Ihre CLAUDE.md, Regel-Dateien und MCP-Konfiguration, bevor Sie eine Session starten. Ändern Sie sie nicht innerhalb der Session.

7. Autocompact-Circuit-Breaker

Ein Quellcode-Kommentar dokumentiert das Ausmaß eines früheren Problems:¹

„1.279 Sessions hatten 50+ aufeinanderfolgende Autocompact-Fehler (bis zu 3.272 in einer einzigen Session), was ~250K API-Aufrufe/Tag verschwendete.”

Die Lösung: MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3. Nach 3 aufeinanderfolgenden Kompaktierungsfehlern stoppt das System den Autocompact und gibt stattdessen einen Fehler aus, anstatt still Tokens zu verbrennen.

Vor dem Circuit-Breaker versuchte eine in einer Kompaktierungsschleife feststeckende Session es unendlich oft erneut, wobei jeder Versuch Tokens für den Kompaktierungs-Prompt und die Antwort verbrauchte. Im großen Maßstab stellen 250K verschwendete API-Aufrufe pro Tag erhebliche Infrastrukturkosten dar. Die Lösung ist eine dreizeilige Änderung, die täglich Millionen von Tokens einspart.

Falls Sie wiederholt auf „compaction failed”-Fehler stoßen, schützt Sie der Circuit-Breaker vor einer Endlosschleife, er arbeitet nicht fehlerhaft.

8. Coordinator-Modus: Prompts als Architektur

Die Multi-Agent-Koordination (coordinatorMode.ts) lebt vollständig in System-Prompt-Anweisungen, nicht in Code-Level-Orchestrierung.³ Das Orchestrator-Modell erhält einen Prompt, der beschreibt, wie delegiert, aggregiert und synthetisiert werden soll. Die untergeordneten Agents sind keine speziellen Prozesse. Sie sind Claude-Instanzen mit unterschiedlichen System-Prompts.

Das Design validiert das „Prompts als Architektur”-Muster, das Praktiker unabhängig voneinander entwickelt haben. Das Hook-System, das ich in Anatomy of a Claw beschrieben habe, verwendet denselben Ansatz: Dispatcher, Skills und Agents arbeiten über Prompt-Anweisungen, nicht über Code-Level-Kontrollfluss.

Eine Anweisung aus dem Coordinator-Prompt sticht heraus:

„Schreiben Sie niemals ‚based on your findings’ — diese Formulierungen delegieren das Verständnis an Worker, statt es selbst zu leisten.”

Die Anweisung fungiert als Qualitäts-Gate, das im Orchestrierungs-Prompt kodiert ist. Der Coordinator muss synthetisieren, nicht weiterleiten. Dasselbe Prinzip gilt für jedes Multi-Agent-System: Wenn der Orchestrator nur Nachrichten zwischen Spezialisten weitergibt, fügt er keinen Wert hinzu.

9. KAIROS: Der unveröffentlichte autonome Agent

Der Quellcode enthält Verweise auf ein unveröffentlichtes Feature namens KAIROS, einen autonomen Agent mit persistentem Speicher.¹

Schlüsselkomponenten: - Ein /dream-Skill für nächtliche Speicher-Destillation - Tägliche Append-Only-Logs - GitHub-Webhooks für repository-bewussten Kontext - Ein Hintergrund-Daemon mit 5-minütiger Cron-Aktualisierung - Feature-Gates, die die Aktivierung verhindern

KAIROS scheint Anthropics Antwort auf persistente, immer aktive Agent-Assistenten zu sein. Der /dream-Skill ist besonders interessant, weil er ein Modell impliziert, das den Speicher im Leerlauf verarbeitet und konsolidiert, ähnlich wie die menschliche Gedächtniskonsolidierung während des Schlafs funktioniert.

Feature-Gates verhindern die Aktivierung, und Anthropic hat KAIROS nicht veröffentlicht. Aber seine Präsenz im Quellcode signalisiert die Richtung: Claude Code entwickelt sich von einem sessionbasierten Tool zu einem persistenten, hintergrundbewussten Agent.

10. Das Companion-Pet-System

Eine der überraschenderen Entdeckungen: Claude Code enthält ein Companion-Pet-System.¹

Jedes Pet ist deterministisch, abgeleitet aus einem Hash der Benutzer-ID mittels Mulberry32, im Quellcode beschrieben als „gut genug für die Auswahl von Enten”. Jedes Pet hat 5 Statistiken (DEBUGGING, PATIENCE, CHAOS, WISDOM, SNARK) und eine Seltenheitsstufe:

Das System rendert Pets als 5x12-ASCII-Sprites mit 3-Frame-Animationen. Der Quellcode kodiert Spezies-Codenamen in Hex, weil einer mit einem unveröffentlichten Modellnamen kollidiert.

Das Companion-System ist kein Spaß-Feature. Es ist ein Retention-Mechanismus. Die deterministische Zuweisung bedeutet, dass Ihr Pet immer dasselbe ist, was Bindung schafft. Das Seltenheitssystem erzeugt soziale Währung. Das ASCII-Rendering bedeutet null Performance-Overhead. Anthropic hat ein gut gestaltetes Engagement-System gebaut und es in einem Entwickler-Tool versteckt.

11. Die Fork-Bombe

Ein Community-Vorfall illustriert die Risiken des Hook-Systems.⁵ Ein Entwickler erstellte einen SessionStart-Hook, der 2 Claude Code-Instanzen spawnte. Jede gespawnte Instanz löste den Hook erneut aus und erzeugte exponentielles Wachstum: 1 → 2 → 4 → 8 → 16 → 2^N.

Bis zum Morgen liefen Hunderte von Claude Code-Instanzen gleichzeitig. Das System vermied eine massive API-Rechnung durch einen ironischen Mechanismus: Der Speicherverbrauch jeder Instanz (Bun, React, TUI) brachte die Maschine zum Stillstand, bevor die Abrechnung explodieren konnte.

Die Lektion für Hook-Entwickler: SessionStart-Hooks müssen idempotent sein. Wenn Ihr Hook Prozesse spawnt, dürfen diese Prozesse nicht denselben Hook auslösen. Eine Guard-Variable, eine PID-Datei oder ein Umgebungs-Flag verhindert die Rekursion.

Was das bedeutet

Das Source-Leak bestätigte, was Praktiker aus dem Verhalten geschlossen hatten: Claude Code ist kein dünner Wrapper um einen API-Aufruf. Es ist ein substanzielles Engineering-System mit Sicherheitsschichten, Performance-Optimierungen, Verhaltensanpassungen und unveröffentlichten Features, die die Produkt-Roadmap signalisieren.

Für Entwickler finden sich die wichtigsten Implikationen im Under-the-Hood-Abschnitt des Guides. Für alle anderen bietet das Source-Leak seltene Einblicke in die tatsächliche Funktionsweise eines Produktions-KI-Tools — nicht wie das Marketing es beschreibt, sondern wie der Code es implementiert.

Die wichtigste Erkenntnis ist zugleich die einfachste: Das System ist komplexer, als es scheint, und diese Komplexität existiert aus guten Gründen. Die 23 Bash-Sicherheitsprüfungen existieren, weil 23 Angriffsvektoren entdeckt wurden. Der Autocompact-Circuit-Breaker existiert, weil täglich 250K API-Aufrufe verschwendet wurden. Das Undercover-Modul existiert, weil Codenamen leaken. Hinter jeder Zeile Verteidigungscode steckt eine Geschichte.

Quellen

Häufig gestellte Fragen

Ist der Claude Code-Quellcode noch verfügbar?

Nein. Anthropic zog die betroffene npm-Paketversion kurz nach der Entdeckung der Source-Maps zurück. Die Analyse in diesem Beitrag basiert auf Community-Dokumentation des Quellcodes, bevor er entfernt wurde.

Beeinträchtigt das Source-Leak die Claude Code-Sicherheit?

Die sicherheitsrelevanten Erkenntnisse (Bash-Validierung, Berechtigungssystem) beschreiben Verteidigungsmechanismen, keine Schwachstellen. Zu wissen, wie die Bash-Sicherheitsprüfungen funktionieren, macht sie nicht leichter umgehbar, weil die Prüfungen deterministisch sind, nicht obskuritätsabhängig.

Sollte ich aufgrund dieser Erkenntnisse ändern, wie ich Claude Code verwende?

Die umsetzbarste Erkenntnis ist die Fragilität des Prompt-Caches. Wenn Sie CLAUDE.md, Regel-Dateien oder MCP-Konfigurationen innerhalb einer Session ändern, brechen Sie den Prompt-Cache. Setzen Sie Ihre Konfiguration, bevor Sie eine Session starten.

Was ist KAIROS?

Ein unveröffentlichtes autonomes Agent-Feature, das im Quellcode gefunden wurde. Es umfasst persistenten Speicher, nächtliche Destillation und Hintergrundverarbeitung. Es ist feature-gated und nicht für Benutzer verfügbar.