# ZCode Uploads Your Git History: Settings Do Nothing > Source: > Published: 2026-09-18 14:09:46+00:00 ZCode, the free GLM-5.2 coding agent from Z.ai, is silently packaging your entire git history and uploading it to Alibaba Cloud. A security researcher published the reverse-engineering proof today. The encrypted archive lands on Aliyun OSS using a key only Z.ai holds — meaning you cannot decrypt it yourself. And the two privacy settings ZCode provides do nothing to stop it. If you installed ZCode and logged in at any point since July 2026, your complete repository lineage — every commit, every deleted secret, every binary asset cached in LFS — may already be on Z.ai’s cloud storage. Here is what the researcher found, why the settings are theater, and how to actually stop the upload. ## What ZCode Is Actually Sending Researcher ferstar’s [reverse-engineering writeup](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/) analyzed a 313MB encrypted archive generated from a single commercial workspace: 42,411 files, 86.6% of which came from the .git directory. The breakdown is specific: - **.git/lfs/** — 196.1 MB (56.8%) — binary assets, LFS large file cache - **.git/objects/** — 102.2 MB (29.6%) — every commit ever made, including deleted content - **.git/logs/** — 0.6 MB (0.2%) — reflogs and branch history - **Source code and docs** — ~46.2 MB (13.4%) This is not sending your current code for AI context. The .git/objects directory contains everything you have ever committed — rotated API keys that still live in history, unpushed branch content, internal hostnames from configurations you long forgot. ZCode triggers the capture before every prompt and after every completed task, generating up to 62 upload events per session. Moreover, failed uploads are queued and retried automatically — one analyzed session logged 564 failed upload attempts sitting in the retry queue. ## Your Privacy Settings Don’t Stop the ZCode Upload ZCode exposes two toggles that users would reasonably expect to control this behavior. However, neither works as advertised. “Optimize Experience” sounds like a telemetry opt-out. In reality, it only controls whether Z.ai is authorized to use your data for model training — the upload continues either way. “Repo Snapshot Indexing” sounds like it disables snapshots. It only controls whether Z.ai’s servers index the uploaded content after receiving it. According to [tokenstead.ai’s mitigation analysis](https://tokenstead.ai/guides/zcode-silent-git-history-upload), the capture sidecar starts unconditionally at login and checks only for a valid JWT authentication token — user preferences are never consulted. Earlier, a Z.ai executive posted publicly that the company would not implement “anything beyond what’s listed” on the ZCode website. Workspace snapshotting is not listed anywhere in the policy, FAQ, or changelog. No official statement has been issued since today’s disclosure. A ZCode team affiliate responded to ferstar’s post with “hey I am sorry to let you find it” — which the developer community on [Hacker News](https://news.ycombinator.com/item?id=49752422) read as confirmation, not denial. ## The Key Z.ai Holds The encryption architecture makes the concern concrete. ZCode uses envelope encryption: AES-256-CTR for archive content, with the symmetric key wrapped using RSA-OAEP-SHA256. The RSA public key is supplied dynamically by Z.ai’s servers at upload time. The private key never touches your machine. You have a multi-hundred-megabyte ciphertext sitting on your local disk. You cannot open it. Z.ai can. As ferstar put it: *“A key that only the server can use serves exactly one purpose: making sure the server can read your code whenever it wants.”* This is not a user-side backup feature — it is a collection architecture. Furthermore, if you have previously read ByteIota’s coverage of [ZCode and China’s intelligence law](https://byteiota.com/zcode-glm-52-china-data-risk/), the encryption setup makes that legal exposure considerably more concrete: the data that law could reach is now decryptable on demand. ## How to Actually Stop the Upload Deleting the checkpoints directory does not help — ZCode recreates it within 30 minutes and resumes uploads. The only reliable fix is making the directory immutable at the OS kernel level, blocking ZCode’s writes entirely. **macOS:** ``` rm -rf ~/.zcode/v2/checkpoints mkdir -p ~/.zcode/v2/checkpoints chflags uchg ~/.zcode/v2/checkpoints ``` **Linux:** ``` rm -rf ~/.zcode/v2/checkpoints mkdir -p ~/.zcode/v2/checkpoints sudo chattr +i ~/.zcode/v2/checkpoints ``` This prevents kernel-level writes to the checkpoints directory. ZCode’s core chat and autocomplete remain functional. The checkpoint rollback UI becomes unavailable — a reasonable trade-off. To reverse the lock: `chflags nouchg` on macOS or `sudo chattr -i` on Linux. For teams with stricter compliance requirements: GLM-5.2 carries an MIT license. Self-hosting the model on your own infrastructure eliminates the data problem entirely — an option neither Cursor nor Claude Code can offer. ByteIota’s earlier [ZCode developer guide](https://byteiota.com/zcode-developer-guide-glm-5-2-free-trial-data-risks/) covers the self-hosting path in detail. ## Key Takeaways - ZCode uploads your entire .git history to Alibaba Cloud — not just current code context — including deleted secrets, unpushed branches, and binary LFS caches - The “Optimize Experience” and “Repo Snapshot Indexing” toggles do not stop the upload; they control only training authorization and server-side indexing - The archive is encrypted with a key held exclusively by Z.ai’s servers — you cannot decrypt your own data - Fix: Use `chflags uchg` (macOS) or`sudo chattr +i` (Linux) on`~/.zcode/v2/checkpoints` — core functionality survives - Z.ai has not issued a statement; a team affiliate’s response amounted to implicit confirmation