Zhipus KI-Coding-Tool ZCode steht seit dem 18. September in der Kritik: Ein Entwickler deckte auf, dass die Software im Hintergrund den gesamten Arbeitsbereich hochlädt – einschließlich der kompletten Git-Historie, des LFS-Caches für große Dateien und lokaler Konfigurationsdateien. Noch am selben Abend veröffentlichte ZCode eine Entschuldigung, bestätigte die Uploads, machte eine Funktion namens „Repository-Indexierung" dafür verantwortlich und erklärte, das Problem sei inzwischen behoben.
Was Entwickler aufgedeckt haben
Als Erster brachte der Tech-Blogger Ferstar Details an die Öffentlichkeit. In seinem Blog zerlegte er den lokalen Snapshot-Mechanismus von ZCode: Nach dem Login startet ein Hintergrundprozess zusammen mit dem Programm, packt den gesamten Arbeitsbereich, verschlüsselt die Dateiinhalte mit AES-256-CTR und umschließt den Schlüssel anschließend mit einem vom Server ausgegebenen RSA-Public-Key, bevor das Paket per Formular-Upload direkt zu Alibaba Cloud OSS geschickt wird. Der private Schlüssel zur Entschlüsselung liegt ausschließlich in der Cloud – Nutzer können ihre eigenen .enc-Dateien nicht selbst öffnen.
Ein von ihm vorgelegtes Beispiel ist konkret: Der unkomprimierte Arbeitsbereich war 345 MB groß, verschlüsselt noch 313 MB, mit 42.411 Dateien im Manifest. Den größten Anteil macht das .git-Verzeichnis aus, insgesamt 86,6 Prozent, davon 196,1 MB LFS-Cache und 102,2 MB Git-Objekte; Quellcode und Konfiguration kommen nur auf rund 46 MB. Ausgelöst wird der Vorgang zu zwei Zeitpunkten – vor jedem abgeschickten Prompt und nach Abschluss einer Aufgabe beim Aktualisieren des Repo-Wikis –, in einer einzigen Sitzung wurden bis zu 62 Snapshots registriert.
Am selben Tag eröffnete ein Entwickler im öffentlichen Feedback-Repository von Zhipu ein Issue, dessen Titel gleich drei „Warum"-Fragen aneinanderreiht: warum die gesamte Git-Historie stillschweigend hochgeladen wird, warum so verschlüsselt wird, dass selbst der Nutzer sie nicht öffnen kann, und warum es nicht einmal einen Schalter zum Abschalten gibt. Im Issue heißt es zudem, dass fehlgeschlagene lokale Uploads wiederholt neu versucht wurden – 564 Mal protokolliert. Ein weiterer Entwickler reproduzierte das Verhalten auf seinem eigenen Rechner: Ein Projekt-Snapshot kam auf 748 MiB, der .git-Anteil lag bei 98,91 Prozent, die Version war ZCode 3.12.3.
Der wirkungslose Schalter ist der schärfste Kritikpunkt an dem Fall. Ferstar zufolge steuern die Schalter „Erfahrung optimieren" und „Repository-Snapshot-Indexierung" in der Oberfläche lediglich, ob der Server die Daten zum Trainieren von Modellen nutzt – das lokale Packen und Hochladen läuft davon unberührt weiter. In der Git-Historie können längst gelöschte Schlüssel, veraltete Konfigurationen, nie gepushte Branch-Stände und interne Domainnamen liegen, die im aktuellen Code nicht mehr sichtbar sind, im .git-Verzeichnis aber unverändert erhalten bleiben.
Was Zhipu dazu sagt
In der Entschuldigung führt ZCode die Uploads auf die Funktion „Repository-Indexierung" zurück: Beim Generieren einer Repo-Wiki-Seite könne ein Upload von Repository-Daten ausgelöst werden; die Daten würden in der Cloud unmittelbar nach der Wiki-Erstellung gelöscht und nicht gespeichert. Die Funktion sei bei Einführung standardmäßig aktiviert gewesen, wodurch einige Nutzer betroffen waren; sie sei nun behoben.
Als Abhilfe nennt Zhipu drei Maßnahmen: das ZCode-Repository in Kürze quelloffen zu machen, einen externen Prüfer einzuladen und den Fortschritt öffentlich zu machen, sowie noch am selben Tag allen Nutzern ein zusätzliches Zurücksetzen des Wochenkontingents zu gewähren. Mehrere Punkte lässt die Mitteilung offen und sind bislang nicht überprüfbar: wie viele Nutzer und Repositories betroffen waren, wie lange die Daten tatsächlich auf OSS lagen, ob die „Löschung" unabhängig geprüft wurde und welche Versionsnummer nach der Behebung gilt. Auch der Zeitplan für die Offenlegung des Quellcodes bleibt mit „in Kürze" vage.
Am selben Tag stellte Zhipu zudem das neue Modell GLM-5.3-FlashX vor, das mit einer Ausgabegeschwindigkeit von 200 Token pro Sekunde beworben wird. Ein Entwickler stellte beides in seinem Blog nebeneinander und spottete, während das ganze Netz frage, wohin der Code verschwunden sei, sei Zhipu damit beschäftigt, ein neues Modell zu veröffentlichen.
Was Entwickler in China jetzt tun können
Viele ZCode-Nutzer testen das Tool an Firmenprojekten, und die Git-Historie ist für Unternehmen oft heikler als der aktuelle Code selbst. Wer noch eine ältere Version installiert hat, sollte laut Empfehlungen drei Schritte gehen: zunächst auf die reparierte Version aktualisieren, dann prüfen, ob im lokalen Verzeichnis ~/.zcode/v2/checkpoints noch nicht hochgeladene Snapshots liegen, und schließlich sämtliche Schlüssel und Tokens rotieren, die in der Historie aufgetaucht sind – denn die Zusage, Daten seien „gelöscht", deckt nicht ab, was bereits übertragen wurde.
Ferstar nennt eine noch drastischere Methode: Unter macOS mit chflags uchg, unter Linux mit chattr +i das Snapshot-Verzeichnis schreibgeschützt sperren und so die Snapshot-Erzeugung schon auf Dateisystemebene blockieren. Der Preis dafür: Checkpoint-Rollback und die Timeline-Funktion fallen dann ebenfalls aus.
Dass Coding-Agents ein Repository lesen müssen, um zu funktionieren, ist für sich genommen nichts Ungewöhnliches – auch nicht eine lokale Indexierung. Der Streitpunkt liegt an der Grenze: Lokales Lesen und Hochladen in die Cloud sind zwei verschiedene Dinge, ebenso das Hochladen des aktuellen Codes und das Hochladen der gesamten Historie. Sollte die von Zhipu versprochene Offenlegung tatsächlich kommen, könnte die Öffentlichkeit zumindest selbst nachvollziehen, welche Pfade das Snapshot-Modul tatsächlich erfasst und wo die Schalter wirklich ansetzen.
Quellen: Reverse-Engineering-Analyse des Tech-Blogs Ferstar zu Snapshot-Mechanismus und Dateizusammensetzung, öffentliches Issue auf zai-org/feedback, Ifeng Tech, CocoLoop, Elliot's Harness Lab; Entschuldigungserklärung von ZCode zur Prüfung von Zuschreibung, Reparaturstatus und Ausgleichsmaßnahmen.