Ant-Ingenieur reverse-engineered Claude Code-Quellcode: Auto Mode vierschichtiges Entscheidungs-Pipeline und Sicherheitsklassifizierungsmechanismus enthüllt

Laut CoinWorld, basierend auf Überwachung durch 1M AI News, hat Ingenieur von Ant Group, der Entwickler des Frontend-Frameworks Umi.js, Chen Cheng, den Quellcode von Claude Code 2.1.81 rückentwickelt und vollständig rekonstruiert, was nach Drücken des Auto-Modus passiert. Zentrale Erkenntnis: Jede Tool-Anfrage durchläuft eine vierstufige Entscheidungs-Pipeline. Nur wenn die ersten drei Stufen keine Entscheidung treffen können, wird ein unabhängiger KI-Klassifikator zur Sicherheitsüberprüfung aufgerufen. Die vier Stufen sind: Erstens, Überprüfung der bestehenden Berechtigungsregeln; bei Treffer erfolgt sofort Freigabe. Zweitens, Simulation des acceptEdits-Modus (also die Berechtigung zum Bearbeiten von Dateien); wenn die Anfrage in diesem Modus genehmigt wird, ist das Risiko gering und der Klassifikator wird übersprungen. Drittens, Überprüfung der Whitelist für Lesetools (Read, Grep, Glob, LSP, WebSearch etc.); diese ändern keinen Status und werden bedingungslos freigegeben. Wenn keine dieser Bedingungen erfüllt ist, erfolgt die vierte Stufe: eine API-Anfrage an Claude Sonnet zur Sicherheitsklassifikation. Wichtige Design-Details des Klassifikators: Es wird stets Sonnet statt Opus verwendet, um Kosten und Latenz abzuwägen; die Temperatur ist auf 0 gesetzt, um deterministische Ausgaben zu gewährleisten; der Klassifikator wird als „Sicherheitsüberwacher autonomer KI-Programmieragenten“ definiert, der drei Risikokategorien schützt (Prompt-Injection, Scope-Expansion, unbeabsichtigte Schäden). Die CLAUDE.md-Konfigurationsdatei des Nutzers wird in den Klassifikator-Kontext injiziert, um die Nutzerabsicht zu beurteilen. Die Blockierungsregeln umfassen über 22 Kategorien, darunter Force Push, direkte Pushes auf den Main-Branch, Herunterladen und Ausführen externer Codes, Produktionsdeployments, Datenlecks, Selbstmodifikation der Berechtigungen, Erstellen von Remote-Code-Execution-Interfaces, Credential-Leaks usw. Ausnahmen bei Freigaben gibt es in 7 Kategorien: Hardcoded Keys für Tests, lokale Dateizugriffe im Arbeitsverzeichnis, reine GET-Anfragen, deklarierte Abhängigkeiten, offizielle Toolchain-Installationen, Lesen von Konfigurations-Credentials und Senden an Zielanbieter, Push auf den aktuellen Branch. Zudem gibt es eine Fail-Safe-Mechanik: Nach drei aufeinanderfolgenden oder insgesamt 20 Ablehnungen schaltet das System auf manuelle Bestätigung um; im Headless-Modus wird der Agent direkt gestoppt. Wenn der Klassifikator nicht verfügbar ist, steuert ein Feature-Flag, ob im „fail-closed“-Modus (direktes Verweigern) oder im „fail-open“-Modus (Downgrade auf manuelle Bestätigung) verfahren wird. Im Auto-Modus gibt es zudem eine feine Frequenzkontrolle für die Injection von Verhalten-Trigger-Wörtern: alle 5 Dialogrunden erfolgt eine Injection, wobei die erste der 5 eine vollständige Version (ca. 800 Wörter, inklusive Anweisungen wie „sofort ausführen, Unterbrechungen minimieren, Aktion vor Planung“) enthält, die restlichen vier sind vereinfachte Versionen, um ein Gleichgewicht zwischen Kontextbelegung und Verhaltensstabilität zu wahren.