Z.ai's ZCode packed 42,411 of one developer's files and tried 564 times to upload them
A developer who pulled apart Z.ai's ZCode assistant found that it had packed 42,411 files from his workspace into a 313MB encrypted archive and logged 564 attempts to push that archive to Alibaba Cloud object storage. The engineer, who publishes as ferstar, set out the analysis on September 18, and every one of those 564 attempts failed on his machine.
Z.ai published the ZCode client on GitHub on September 20. Image: Z.ai
Most of the package was not his code. The workspace came to 345.5MB before compression, and Git data accounted for 86.6% of it: 196.1MB of cached Git LFS assets, 102.2MB of commit objects and 0.6MB of reflogs, against roughly 46.2MB of source and documents.
Nobody outside Z.ai could open the archive
ferstar says the payload was encrypted with AES-256-CTR and the content key wrapped with RSA-OAEP-SHA256, using a public key the server handed down with temporary Alibaba Cloud credentials, so the upload went straight to the storage bucket rather than through Z.ai's own servers. He reports that the matching private key exists only in Z.ai's cloud, which leaves the company as the only party able to unwrap a snapshot, and leaves nobody else able to say what a successful upload would have carried.
He puts the capture on ZCode 3.12.3, running before every prompt and again whenever a Repo Wiki task finished, up to 62 times in a single active session. His figures come from one test machine and one method, so they describe what that install did rather than every copy of ZCode in the wild.
The privacy toggles did not stop the packaging
Two settings look like they should have covered this, and ferstar says neither did. "Optimize Experience" governed consent to training on user data, and "Repository Snapshot Indexing" governed what the server did with a snapshot once it arrived, so the packaging and the upload attempt ran whichever way either was set. He found no switch in the interface that turned the uploader off.
Z.ai is the trading name of Zhipu AI, the Beijing company behind the open-weight GLM models that first drew attention with GLM-130B in 2022. ZCode is its coding agent, sold as a desktop, browser and terminal workspace.
Z.ai apologised and put the client on GitHub
The company answered the same day, through ZCode's own announcement channels: an apology, an explanation that the uploads came from repository indexing and the Repo Wiki feature, and a claim that data received in the cloud was destroyed as soon as a wiki had been generated. That destruction claim is Z.ai's own, and since Z.ai holds the only key, nobody outside the company can check it.
What followed is easier to verify. Z.ai published the ZCode client on GitHub on September 20 under an Apache 2.0 licence, where it has passed 5,900 stars, and ferstar reports that version 3.14.0 drops the upload code and that the endpoint issuing snapshot credentials now returns a 404. The repository starts from scratch, with two commits on its main branch and none of ZCode's own development history.
The gap ferstar describes is between a setting's name and its job: "Repository Snapshot Indexing" governed what happened to a snapshot after it arrived, while ZCode built and sent one either way. The same question sits over any assistant with the run of a whole repository, including the Codex and Claude Code plugins Unity now ships. ZCode is the one somebody has measured.
