ZCode lädt Git-Historie heimlich hoch

Ein Entwickler mit dem Pseudonym ferstar hat den Desktop-Coding-Agenten ZCode von Z.ai (Zhipu, GLM-Modelle) reverse-engineert und dabei eine Upload-Pipeline gefunden, die im Hintergrund läuft, sobald man eingeloggt ist: ZCode packt den kompletten Workspace samt vollständiger .git-Historie, LFS-Cache und Reflogs ein, verschlüsselt das Paket und lädt es zu Aliyun OSS hoch, dem Objektspeicher von Alibaba Cloud. Der Beitrag erschien am 18.09.2026 und stand auf Hacker News mit zwei separaten Einreichungen bei 294 und 259 Punkten.

Was tatsächlich hochgeladen wird

Bei ferstar lag ein 313 Megabyte großes, verschlüsseltes Archiv aus 42.411 Dateien eines kommerziellen Repositories auf der Platte. Laut seinem Manifest bestand die Payload zu 86,6 Prozent aus dem .git-Verzeichnis, davon 56,8 Prozent Git-LFS-Binärdateien und 29,6 Prozent Commit-Objekte. Nur 13,4 Prozent waren tatsächlicher Quellcode.

Das unabhängige Forensik-Repository zcode-upload-forensics von Zuixi bestätigt den Mechanismus auf zwei eigenen Testmaschinen und ergänzt Details aus dem Client selbst: Der Ablauf läuft in vier Schritten. Der Client holt sich vom Z.ai-Server einen öffentlichen RSA-Schlüssel und eine OSS-Formularsignatur, packt und verschlüsselt lokal mit AES-256-CTR, verpackt den zufälligen Inhaltsschlüssel per RSA-OAEP-SHA256 und postet direkt an den Objektspeicher-Host, ohne dass der eigentliche Z.ai-API-Server das Paket je zu sehen bekommt. Der private Schlüssel dazu existiert ausschließlich serverseitig. Das bedeutet auch: Wer sich das verschlüsselte Archiv später selbst ansieht, kann es nicht entschlüsseln, nur Z.ai kann das.

Mitgeschickt wird laut demselben Repository außerdem ein zweites Manifest mit der globalen Client-Konfiguration, darunter settings.behavior.json, skills.json und globale Instruktionsdateien wie AGENTS.md. Der Upload beschränkt sich also nicht auf das gerade geöffnete Repository.

Die 564 fehlgeschlagenen Uploads: was offen bleibt

In ferstars Metadaten steht für sein Archiv ein failureCount von 564, der Status blieb auf "pending" stehen. Was das bedeutet, ist bei ihm nicht abschließend geklärt: Ob bei ihm selbst tatsächlich Daten angekommen sind, lässt sich aus seinem eigenen Fund nicht sicher sagen.

Das Forensik-Repository liefert dafür den entscheidenden technischen Anhaltspunkt, unabhängig vom Einzelfall: Der Client schreibt das Feld lastAcceptedManifestHash in seine lokale Zustandsdatei ausschließlich dann, wenn der Upload zuvor mit einem 2xx-Status quittiert wurde. Ein leerer "pending"-Ordner heißt also nicht, dass nichts verschickt wurde, und ein gefüllter lastAcceptedManifestHash heißt, dass die verschlüsselte Datei den Bucket erreicht hat. Auf den beiden vom Repository gemessenen Maschinen stand dieses Feld jeweils auf "uploaded", unabhängig vom Stand der beiden UI-Schalter.

Zwei Schalter, die nicht das tun, was sie versprechen

Genau hier liegt der eigentliche Befund. ZCode zeigt zwei Einstellungen, die nach einem Ausschalter aussehen: "Optimize Experience" und "Repo Snapshot Indexing". Laut der Analyse steuert "Optimize Experience" nur, ob Daten fürs Training verwendet werden, und "Repo Snapshot Indexing" nur die serverseitige Indexierung der Snapshots. Das lokale Packen und Hochladen läuft in beiden Fällen unverändert weiter. Das Forensik-Repository hat das auf einer Testmaschine mit deaktiviertem "Repo Snapshot Indexing" nachvollzogen: Der Snapshot wurde trotzdem akzeptiert. Ferstars Fazit dazu, sinngemäß: Solange man eingeloggt ist, läuft diese Pipeline dauerhaft im Hintergrund, und keine UI-Einstellung schaltet sie ab.

Wer es selbst nachprüfen will, kann das Forensik-Repository nutzen, das ausdrücklich als Selbsttest-Werkzeug gedacht ist und ohne echte Nutzerdaten auskommt (python3 scripts/diagnose.py --out report.html). Es warnt allerdings auch, dass die Beweise vergänglich sind: Auf einer gemessenen Maschine wurde das Checkpoint-Verzeichnis zwei Minuten nach Beenden des Clients gelöscht und leer neu angelegt.

Ein wirksamer, wenn auch unbequemer Workaround ist, das Checkpoint-Verzeichnis auf Dateisystemebene unveränderlich zu machen:

# macOS
chflags uchg ~/.zcode/v2/checkpoints

# Linux
sudo chattr +i ~/.zcode/v2/checkpoints

Das blockiert den Schreibzugriff auf Kernel-Ebene und verhindert damit auch das Anlegen neuer lokaler Checkpoints, für die man dann aber gegebenenfalls den lokalen Rollback-Komfort von ZCode verliert.

Die Stellungnahme von Z.ai

Als der Fund die Runde machte, meldete sich zunächst nur ein ZCode-nahes Konto mit den Worten "hey I am sorry to let you find it", was in der Berichterstattung eher als Bestätigung des Mechanismus gelesen wurde denn als Widerlegung. Eine wirkliche offizielle Reaktion kam am selben Tag über Zhipus eigene Kanäle: Laut chinesischer Berichterstattung, etwa bei IT之家, entschuldigte sich das Unternehmen am 18.09.2026 bei betroffenen Nutzern und erklärte, die Ursache liege in der "Codebase-Indexierung", genauer in der Repo-Wiki-Funktion, die für die Erstellung von Wissensdatenbank-Seiten Repository-Daten hochladen könne. Diese Funktion sei zum Start standardmäßig aktiv gewesen. Die Daten seien direkt nach der Verarbeitung gelöscht und nicht dauerhaft gespeichert worden. Z.ai kündigte an, den ZCode-Quellcode in Kürze zu veröffentlichen, externe Prüfer für eine Systemprüfung einzuladen und allen Nutzern einmalig das wöchentliche Nutzungslimit zurückzusetzen.

Diese Erklärung deckt sich nur teilweise mit dem, was die unabhängige Analyse zeigt. Z.ai beschreibt eine einzelne Funktion mit einem inzwischen behobenen Standardwert. Die Forensik-Daten zeigen dagegen einen Upload, der laut den Testmaschinen unabhängig vom Stand des zugehörigen Schalters lief, und ein Archiv, das serverseitig verschlüsselt bleibt statt sofort gelöscht zu werden, jedenfalls ließ sich Löschung von außen nicht bestätigen. Ob der angekündigte Fix diese Lücke tatsächlich schließt, lässt sich ohne eigene Nachprüfung an einer aktuellen Client-Version nicht sagen. Die angekündigte Open-Source-Veröffentlichung und externe Prüfung wären der Punkt, an dem sich das objektiv klären ließe.

Warum das der Client ist, nicht die offenen Gewichte

Wichtig für die Einordnung: Das Problem sitzt im Desktop-Client, nicht im Modell. GLM, die Modellfamilie hinter ZCode, gibt Z.ai inzwischen als offene Gewichte frei, die sich selbst hosten lassen, ganz ohne Anbieter-Telemetrie. Wer GLM über die eigene Infrastruktur betreibt, hat mit dieser Upload-Pipeline nichts zu tun, sie steckt im ZCode-Client, nicht im Modellgewicht. Das deckt sich mit dem größeren Bild, das wir zu selbst hostbaren Modellen als Souveränitätsoption schon eingeordnet haben: Ein Modell, das ihr selbst betreiben könnt, bleibt eine Option. Ein Hersteller-Client, der zusätzlich eure Repositories abgreift, ist dagegen ein eigenständiges Datenabfluss-Risiko, unabhängig davon, wie offen das dahinterliegende Modell ist.

Bin ich betroffen, und was tue ich jetzt

Der Vorfall betrifft in erster Linie den ZCode-Client, ändert an der Einschätzung zu selbst hostbaren GLM-Gewichten also nichts. Was er zeigt, ist eine altbekannte Regel, die bei Coding-Agenten neu relevant wird: Ein Werkzeug mit Schreibzugriff auf eure Repositories verdient denselben kritischen Blick wie jede andere Software, die Kundendaten oder Geschäftsgeheimnisse sehen könnte, ganz unabhängig vom Herkunftsland oder vom Modell dahinter.