ZCode Reportedly Uploads Git History in the Background; Vendor Says It Is Fixed, but Patched Version Remains Unclear

ZCode’s background repository snapshot mechanism drew scrutiny from developers on September 18. Researcher ferstar published a reverse-engineering analysis alleging that, after login, the desktop application packages the workspace and Git history, then sends an encrypted snapshot to Alibaba Cloud OSS. Another user also submitted local reproduction records to the official feedback repository. [Original analysis](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/), [issue report](https://github.com/zai-org/feedback/issues/707)

The data at issue extends beyond the currently visible code. One manifest examined by ferstar contained 42,411 files, with the Git directory accounting for 86.6% of the data volume, including the object database, large-file caches, and local operation logs. These contents could retain deleted sensitive configuration settings or traces of work that had not yet been pushed. The 313 MB sample was still in the pending upload queue at the time, with 564 failed attempts recorded, so this sample alone does not establish that an upload succeeded. [Sample evidence](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/)

A separate GitHub report provides different evidence: a user said ZCode 3.12.3 on macOS and 3.10.0 on Linux retained status records indicating that snapshots had been accepted by the remote service, and that related records continued to appear after repository snapshot indexing was disabled. This supports further investigation into the discrepancy between the setting and the upload process, but it remains a user report and does not establish how many users were affected or how all versions behave. [Reproduction environments and status fields](https://github.com/zai-org/feedback/issues/707)

Encryption does not eliminate the data governance concerns. The reverse-engineering analysis describes content being encrypted with AES-256-CTR, with the symmetric key then wrapped using an RSA public key supplied by the server. This design suggests that the vendor controls the means to decrypt the data. Users therefore cannot assume that the cloud service cannot read the contents simply because the data is encrypted on disk. Whether training is permitted, whether indexing occurs, and whether data is transmitted must each be verified separately. [Analysis of encryption and settings](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/)

An official response published by IT Home attributed the issue to a codebase indexing feature that was enabled by default in early versions, saying that Repo Wiki generation could trigger uploads. The company said it had fixed the issue, that data is destroyed immediately after pages are generated in the cloud, and that it would release source code and commission a third-party review. These are vendor statements, not independently audited findings. [Report on the official response](https://www.ithome.com/1/004/310.htm)

At the time of verification, the latest version listed in the public changelog was still 3.12.3, dated September 17, with no clear indication of which version contained this fix. Engineering teams should next confirm whether the fix is on the client or server, whether disabling the feature stops pending uploads, and what evidence demonstrates deletion of previously collected data. Acceptance testing needs to examine both network traffic and local manifests, rather than relying solely on the settings interface. [Official changelog](https://zcode.z.ai/cn/changelog)