ZCode kept uploading full git history with the setting switched off
A researcher found ZCode uploading full git history to Zhipu's cloud with its own privacy setting switched off, encrypted with a key only Zhipu holds.
ZCode's own setting said no uploads. Zhipu's servers said otherwise, and only Zhipu holds the key.
Most AI coding agents keep some local index of a project so they do not have to re-read every file on each request. ZCode, the desktop coding agent from Zhipu AI's GLM family, does something different. A researcher publishing at blog.ferstar.org on September 18, 2026 found that ZCode packages a workspace's entire git history, including old commits and its LFS cache, into an encrypted archive and uploads it to Zhipu's own cloud storage, whether or not the user asked it to.
A setting that read false anyway
The researcher checked ZCode's own settings panel, where a toggle called Repository Snapshot Indexing promises to turn this behavior off. Across 1,339 separate checks on his own machine, the setting read false the entire time. The uploads happened anyway.
The key nobody but Zhipu holds
The archive itself is encrypted, AES-256-CTR, wrapped with an RSA public key that ZCode's server supplies. That sounds like a safeguard until you notice who holds the matching private key: Zhipu, not the person whose repository just left their machine. A user cannot decrypt their own upload even if they wanted to check what it contained.
Ruohang Feng, a second researcher writing at blog.vonng.com, reproduced the finding the same day on his own machine: the setting still read false, and the encryption scheme matched. Zhipu, which trades as Z.ai, confirmed that uploads had occurred in a statement issued that afternoon. It described the behavior as "codebase indexing" meant to support a Wiki feature, said the data was "destroyed immediately," and called the issue already fixed.
What Zhipu has not said is how a setting displaying false could have triggered an upload anyway, or whether any archives uploaded before September 18 still sit on its servers. "Destroyed immediately" and "already fixed" are Zhipu's own words about its own systems, and neither researcher has independently confirmed either claim.
Why a build studio cares
Our Deep and Full Audits map exactly this: what data actually leaves a system, compared against what the vendor's own settings claim happens. A toggle reading false is not evidence of anything by itself. It only means something once you trace where the bytes actually go, the way ferstar's reverse engineering did here. That is the check a screenshot of a settings panel can never replace, and it is the reason "we have a setting for that" is not the same claim as "we verified the setting works."
Next step: read the original disclosure at blog.ferstar.org for the full reverse engineering trail, including the network captures. If you run an AI coding agent inside your own repositories and have never actually checked what it sends home, write to us at hello@gattyworks.com.