ZCode Publishes Source Code and Data Flow Details; Questions About Earlier Upload Incident Remain

With Z.ai’s release of ZCode’s source code, the incident involving workspace snapshot uploads in an earlier version has entered a new phase in which the implementation can be inspected. GitHub records show that the code was imported in a single commit on September 20; the original reporter, ferstar, added a review of the new version’s source code on September 21. The release covers the desktop, web, and terminal interfaces, along with the agent runtime, and is licensed under Apache 2.0. [Official repository](https://github.com/zai-org/ZCode), [commit history](https://github.com/zai-org/ZCode/commits)

The incident began with ferstar’s examination of the 3.12.3 client: the workspace was packaged, including its Git history, and the encryption key was protected using a public key supplied by the server, in preparation for a direct upload to Alibaba Cloud OSS. He specifically clarified that the 313 MB commercial project archive consistently failed to upload. Only a separate test with a small public repository showed a successful receipt. The two cases should not be conflated as evidence that commercial code was leaked. [Original investigation and updates](https://blog.ferstar.org/posts/zcode-silent-workspace-snapshot-upload/)

The official 3.14.0 changelog lists a fix for abnormal uploads associated with the repository wiki feature. Ferstar’s review of the newer version states that the original snapshot generation and upload pipeline has been removed. This evidence supports progress on fixes in specific versions, but does not cover every installation source or runtime environment, nor does it prove that all copies of previously uploaded content have been deleted. [Official changelog](https://zcode.z.ai/en/changelog)

The public code provides another directly verifiable detail: the current checkpoint implementation uses local Git to create tree objects, commits, and hidden refs, while storing metadata locally in JSON. During restoration, it checks for workspace changes and, by default, refuses to overwrite files when conflicts arise. This recovery mechanism does not itself require sending the entire repository to the cloud, but it cannot establish the full behavior of earlier versions. [Checkpoint implementation](https://raw.githubusercontent.com/zai-org/ZCode/main/packages/services/src/git/repo/gitCheckpointRepo.ts), [local storage implementation](https://raw.githubusercontent.com/zai-org/ZCode/main/packages/services/src/git/repo/gitCheckpointStore.ts)

The open-source version still sends data externally as part of normal operation. The official NOTICE explains that model and auxiliary tasks may transmit prompts, code, diffs, and tool results; Coding Plan requests matching specified endpoints are forwarded through the ZCode gateway. Users building from source therefore still need to check endpoint and feature settings. Source code visibility alone does not mean that all data stays local. [Data flow documentation](https://raw.githubusercontent.com/zai-org/ZCode/main/NOTICE.md)

The next points to track are how release artifacts correspond to public commits, reproducible evidence of the earlier upload path, and records of how historical data was handled. The current public history contains only two commits—initialization and the open-source import—so it does not yet allow a version-by-version comparison of the removal process. For those deploying ZCode, this release provides a starting point for an audit; a complete assessment still requires version comparisons and observation of actual network traffic.