If you installed Z.ai’s ZCode coding assistant this year, your local git history, large-file cache, and reflog may have already been packaged, encrypted, and put on a one-way ticket to Alibaba Cloud. The number that brought this home is 564: that is how many times the assistant tried to upload a 313-megabyte archive of one developer’s workspace before anyone at Z.ai was asked. The discovery, by an independent Chinese blogger who goes by Ferstar, has now forced the company to disable the upload workflow, delete the cloud bucket, and open the source for community review. The deeper question is not “does my AI coding assistant train on my code?” It is: what else is it doing in the background while you are not looking?
What Ferstar found
The story begins on 18 September 2026, when Ferstar published a reverse-engineering write-up titled “zcode-silent-workspace-snapshot-upload.” Ferstar had noticed abnormal disk usage on a development machine and traced it to background processes inside ZCode. The forensics, summarised by The Next Web, showed a default-enabled workflow that packaged the entire local workspace into a single encrypted archive on every login and queued it for upload to an Alibaba Cloud OSS bucket named zcode-prod.
The archive weighed 313 megabytes and contained 42,411 files. Roughly 86.6 percent of that was git data: a 196.1-megabyte large-file cache, 102.2 megabytes of git objects (the full commit history, not just the current tree), plus reflog entries that record every branch checkout, reset, and rebase. As Ferstar put it: “Whenever you are logged in, ZCode silently packages your entire workspace.”
The encryption scheme was AES-256-CTR for the contents, with the key wrapped using RSA-OAEP-SHA256. The private key, InfoWorld reports, was held only by Z.ai, which means the local archive was unreadable to the developer who owned it. Upload attempts were triggered automatically by two workflows: a pre-prompt capture step and the “Repo Wiki” generation task.
What got out, and what did not
Tom’s Hardware’s reporting gives the headline number for one developer’s machine: 564 failed upload attempts. The archive sat in a pending state on disk because the bucket refused to accept it, but the retry loop kept firing on every login. So the data did not cross the network, in this developer’s case, but the system kept trying.
According to The Next Web’s reconstruction, one snapshot did reach the server: a public repository, 538 files, about 15 kilobytes compressed. That is the only confirmed successful upload Ferstar was able to verify. A separate claim by Chinese firm Chengming Technology, that six workspaces containing “complete source code, database passwords, employee personal data” had reached the cloud, was retracted on Monday, with the company citing “wrong evidence.” The only verified exfiltration on the public record is one small public-repo archive.
What Z.ai changed
Z.ai posted its response on the ZCode official account on the Monday after Ferstar’s write-up went live. The apology: “In response to the ZCode product security issues reported by the community, we have completed the necessary remediation and sincerely apologize to all our users.” Three concrete changes followed:
- The repository-upload workflow and the “Repo Wiki” entry-point generator were removed in ZCode v3.14.0. The checkpoint mechanism now relies on local git only.
- The
zcode-prodAlibaba Cloud OSS bucket was deleted. Z.ai asked the China Academy of Information and Communications Technology (CAICT) and NSFOCUS to confirm the deletion. NSFOCUS: “NSFOCUS confirmed that all data objects in the zcode-prod Alibaba Cloud OSS bucket, as well as the bucket itself, have been deleted.” - The full ZCode codebase was open-sourced at
github.com/zai-org/ZCodeunder an Apache-2.0 license. Ferstar’s follow-up on 21 September noted that the public repository carries only two commits and that development history was erased before publication.
The company also stated that no data “has ever been used for model training.” That is a separate claim from “no data left your machine.” Z.ai has confirmed only that the encrypted archive could not be read by anyone but Z.ai, and that the bucket it would have been stored in is now empty.
Why this is different from a normal data leak
Two things make this case more useful than the average “vendor exposed customer data” story. The first is what Cris Thomas of Semgrep told InfoWorld: “This isn’t really an AI model problem, it’s an old-fashioned security architecture problem.” The encrypted upload was not a side effect of how the assistant worked. It was a feature, written into the application, that ran on every login by default and asked no permission. The fix is not “better AI safety.” The fix is to not ship the feature at all.
The second is the audit chain. Z.ai did not just disable the upload and call it done. It deleted the bucket, asked two outside firms to confirm the deletion, and open-sourced the codebase so the community can confirm the offending code is actually gone. That is more transparency than most vendors offer when something like this happens.
The third point - the one a privacy-focused reader has to sit with - is that “open-sourced now” does not undo what shipped before. Anyone who used ZCode before v3.14.0 has to assume their local git history sat in an encrypted archive on disk, with a private key Z.ai held. Whether the encrypted data left the machine depends on what actually happened on each install, and only Z.ai’s logs could tell you. The third-party audits have not addressed that, and neither has the open-sourcing.
What This Means
The shape of the Z.ai case is worth sitting with, because it is not really about one vendor. ZCode shipped with a default-enabled background upload, packaged the developer’s full git history and reflog into an encrypted archive, and queued it for an overseas cloud bucket on every login. The trigger was a workflow the developer never consented to. The discovery came from an external researcher reverse-engineering the binary, not from any audit, telemetry, or disclosure Z.ai itself produced.
For anyone using an AI coding assistant on a code repository they do not fully own - employer IP, client work, anything under NDA - the questions to ask are not “which model is best?” but “what does this assistant send off the machine by default, where does it go, how long is it kept, and who can read it?” Z.ai’s case shows the limits of asking those questions of a closed product: the answers are in the binary, and you only find them when someone reverse-engineers it.
The Bottom Line
Z.ai’s ZCode assistant packaged local workspaces - full git history, reflogs, LFS caches, and app configuration - into encrypted archives and tried to upload them to Alibaba Cloud OSS on every login. Ferstar found the behaviour, Z.ai disabled the workflow in ZCode v3.14.0, deleted the bucket, commissioned third-party confirmation from CAICT and NSFOCUS, and open-sourced the codebase. The only verified successful upload was a small public-repo archive; the larger claim of mass exfiltration was retracted. For anyone who ran ZCode before the patch, the safe assumption is that their encrypted archive sat on disk waiting for an upload that did not go out, with whether anything else ever did depending on Z.ai’s logs.