The most widely reported example needs a critical qualification: the 313 MB archive recorded 564 failed upload attempts, not 564 successful transfers. The South China Morning Post reports that developer and blogger Ferstar found that archive awaiting upload to Alibaba Cloud storage, while a separate 15 KB file had successfully been sent. The finding does not establish that the larger archive reached the server.
What developers found
Ferstar inspected ZCode’s local data directory on September 18 and discovered the encrypted archives, according to the South China Morning Post. Visible filenames led him to identify the larger archive as a snapshot of a commercial project, including its Git history. He could not decrypt the archive to inspect its contents directly; he said the necessary private key was held by Z.ai’s backend.
The Next Web also describes the 313 MB archive as having failed to upload 564 times, with a smaller file already transferred. Both accounts concern Ferstar’s discovery; their publication by multiple outlets should not be mistaken for separate reproductions of his measurements.
Tom’s Hardware, citing the South China Morning Post, reports that another developer, Feng Ruohang, described a similar experience. It also reports that the upload mechanism was enabled by default without an effective off option. These remain attributed developer findings rather than a published, independently audited account of every affected installation.
The distinction between an attempted and completed upload changes the incident assessment. A queued archive demonstrates that data was prepared for transfer, and repeated failures show that the tool kept trying. Neither establishes successful delivery of that archive. Conversely, the reported successful transfer of the smaller file means the account cannot be reduced to local-only snapshot creation.
The reporting identifies ZCode as the affected application. It does not establish equivalent behavior in every product using Z.ai’s GLM models, or in separately downloaded model weights.
Why Git history widens the concern
A workspace snapshot can contain substantially more information than the code a developer deliberately includes in a prompt. In Ferstar’s case, the reported inclusion of Git history is particularly important because a repository’s historical contents can differ from its current files.
Technical coverage by Cocoloop, drawing on developer analyses, reports that ZCode’s snapshots included Git data, large-file caches and local configuration. It also describes concerns about historical credentials, old configuration and unpushed branches. Those details are researcher-reported findings, not a complete inventory independently verified for all ZCode users.
The practical implication is that checking only the current source tree may underestimate potential exposure. A credential removed from a current file can still warrant attention if it remains in the repository history included in a snapshot. That is a reason to assess historical contents where a transfer is suspected—not proof that Ferstar’s archive contained usable credentials.
Encryption also needs to be understood in terms of who controls the key. According to Ferstar’s account in the South China Morning Post, Z.ai’s backend held the private key required to decrypt the archive. Encryption in that arrangement does not prevent the intended recipient from reading the data. It also left the developer unable to directly inspect the encrypted package locally.
The reports do not establish access by an outside attacker, public exposure of a storage bucket, or subsequent misuse of uploaded code. The supported concern is unauthorized workspace transfer to vendor-controlled processing, with the extent of completed transfers still unresolved.
What Z.ai says it changed
According to Tom’s Hardware, Z.ai said it had fixed uploads without consent, destroyed uploaded data, and planned to open-source ZCode’s codebase and invite third-party assessment. The Next Web reports that the company’s apology appeared in its official Feishu community and was reposted on V2EX.
Cocoloop’s account of the apology attributes the behavior to ZCode’s repository-indexing feature. It reports that generating Repo Wiki pages could trigger a repository upload, that the feature was initially enabled by default, and that Z.ai said the cloud data was destroyed after Wiki generation.
These statements describe the company’s explanation and remediation claims. Deletion has not been independently verified in the available reporting, and the promised source release and third-party review should not be treated as completed audits.
The absence of an established fixed-build identifier also limits practical guidance. There is no sufficiently verified version number here that administrators can use as a definitive compliance threshold, nor a complete affected-version or operating-system matrix. A generic instruction to “update and resume work” would therefore offer more certainty than the evidence supports.
ZCode’s published terms, effective June 15, 2026, provide relevant context. They describe collecting information users proactively provide, including code, file contents, logs, terminal output and tool results, and acknowledge file, Git, network and upload operations. Those broad provisions do not establish that this particular automatic snapshot workflow was clearly disclosed or explicitly approved.
How development teams should assess exposure
For an organization that used ZCode on confidential projects, a precautionary pause on sensitive-repository use is a reasonable response while the transfer scope and remediation are established. That is a risk-management recommendation, not a claim that every installation uploaded data.
A focused review should distinguish three questions:
- Determine which repositories ZCode could access, including their history and local configuration, rather than considering only files intentionally submitted in prompts.
- Distinguish locally generated snapshots and failed attempts from completed transfers when reviewing available application, endpoint or network records.
- Assess whether potentially transferred material contained active secrets or confidential project information. Where usable credentials may have been exposed, the company’s deletion assurance should not substitute for credential remediation.
Windows administrators should avoid assuming that a directory path or filesystem workaround reported on another operating system applies to Windows. The evidence does not establish a universal Windows inspection path, a verified opt-out procedure, or a supported local workaround that preserves ZCode’s other functionality.
The company’s planned source release could help reviewers examine what the snapshot mechanism collects and how its controls operate. It would not, by itself, verify deletion of historical cloud uploads. For teams deciding whether to restore ZCode access to private repositories, the relevant evidence is a clearly identified remediation, demonstrable control over transfers, and an exposure assessment that accounts for repository history as well as current code.