Z.ai Open-Sources ZCode After Silent 313MB Workspace Upload
TL;DR
- Binary analysis of ZCode versions 3.12.3 and 3.14.0 confirms the RSA key was held server-side; users cannot decrypt their own uploaded archives.
- One researcher found 93.9% of packaged data was .git history; a separate analysis counted 42,411 workspace files in a single upload session.
- Neither the 'Optimize Experience' nor 'Repo Snapshot Indexing' privacy settings halted snapshot collection or upload attempts, per independent analysis.
Z.ai's ZCode coding agent silently packaged 42,411 files from one developer's workspace into a 313MB encrypted archive and made 564 failed attempts to ship it to Alibaba Cloud, according to Tom's Hardware.
The finding came from a researcher publishing as ferstar. In a reverse-engineering write-up dated September 18, ferstar traced the client requesting upload credentials from zcode.z.ai, receiving an RSA public key and Alibaba Cloud object-storage form signatures, and encrypting the payload with AES-256-CTR before shipping it. The .git directory accounted for 86.6% of the archive; Git LFS caches alone came to 196.1MB, and .git/objects another 102.2MB.
"The corresponding private key was held on the server side, leaving the local user and the ZCode client unable to decrypt the ciphertext stored on the user's own computer," the analysis reported.
The privacy controls did not stop it. Z.ai's "Repo Snapshot Indexing" and "Optimize Experience" toggles, ferstar found, "only control whether data is authorized for model training"; local packaging and upload continued regardless. One active session generated 62 capture events triggered before prompts and after task completion.
Z.ai, the firm behind the GLM models, apologized, open-sourced ZCode under Apache 2.0 on September 21, and said the collected data had been destroyed. Users cannot verify that claim from the released client alone.
What others are reporting
-
ferstar (Code is cheap, let's talk) Read →
Original discovery post with reverse-engineered code from versions 3.12.3 and 3.14.0 confirming server-controlled RSA keys; cross-references company responses against disassembled binaries.
ZCode silently packages your entire workspace, including the complete .git history, LFS asset cache, reflogs, and configs, then encrypts and uploads it to Aliyun OSS.
-
VONNG (Ruohang Feng) Read →
Independent forensic on author's own machine; uniquely documents 93.9% of packaged data was .git history and flags the Grok CLI precedent from two months earlier.
Taking data without telling me, taking all of it, and giving me no way to turn it off.
-
RuntimeWire Read →
Provides the specific file count (42,411) and confirms the RSA private key was held server-side, making client-side decryption of uploaded archives impossible.
The corresponding private key was held on the server side, leaving the local user and the ZCode client unable to decrypt the ciphertext stored on the user's own computer.
-
RuntimeWire Read →
Documents that the published privacy settings ('Optimize Experience', 'Repo Snapshot Indexing') did not actually prevent snapshot collection, a gap not emphasized in other reporting.
Undisclosed full-repository snapshots turn that access into a source-code governance risk for developers and employers.
-
Tokenstead Read →
Frames the incident as a systemic problem for all proprietary AI coding harnesses, noting Z.ai marketed ZCode as a privacy-conscious alternative to Claude Code.
A key that only the server can use serves exactly one purpose: making sure the server can read your code whenever it wants.
Originally reported by tomshardware.com
Read the original article →Original headline: Z.ai Open-Sources ZCode After Users Catch Its Coding Agent Silently Uploading Git Histories