Aufgefallen ist die Funktion durch Plattenplatz. Auf einem MacBook Air mit 256 Gigabyte belegte das Verzeichnis ~/.zcode über 700 Megabyte. Ferstar zerlegte daraufhin das Client-Paket und fand den Ablauf: Der Client packt das Arbeitsverzeichnis mitsamt vollständigem Git-Verlauf, LFS-Zwischenspeicher, Reflogs und globalen Einstellungen zusammen, verschlüsselt das Paket und lädt es zum Objektspeicher Aliyun OSS.
Der Kern des Problems ist die Verschlüsselung. Der Inhalt wird mit einem Einmalschlüssel per AES-256-CTR verschlüsselt, dieser Schlüssel wiederum mit einem RSA-Schlüssel, den der Server bei der Anfrage ausliefert. Der zugehörige private Schlüssel verlässt die Cloud nie. In Ferstars Fall lagen 313 Megabyte Chiffrat auf der eigenen Platte, die weder er noch der Client öffnen konnte.
Z.ai entschuldigte sich, erklärte die Sache für behoben und legte den Quellcode offen. Das am 20. September angelegte Repository zai-org/ZCode trug zunächst genau zwei Commits: einen leeren und einen, der 6.973 Dateien auf einmal einspielt; am 23. September kam eine Aktualisierung auf Fassung 3.14.3 hinzu. Pull Requests sind gesperrt, die Issues abgeschaltet. Ferstars Durchsicht findet darin keine Spur des Upload-Pfads mehr; die Indizierung läuft wieder lokal über ripgrep und bfs.
Zwei von Z.ai selbst beauftragte Prüfer bestätigen die Aufräumarbeit. Die China Academy of Information and Communications Technology meldet, der Speicherbereich sei leer und die Client-Fassung 3.14.0 erzeuge keine Abzüge mehr; der Sicherheitsanbieter NSFOCUS bestätigt, dass Bereich und Objekte gelöscht sind. Keine der beiden Prüfungen beantwortet, wer den privaten Schlüssel hält.