Zhipu's AI coding tool ZCode was called out by developers on September 18 for silently packaging and uploading a user's entire workspace in the background, including the full Git history, LFS large-file cache, and local configuration. Later that day, ZCode issued an apology confirming the uploads had happened, attributing them to a "repository indexing" feature, and saying the issue had been fixed.
What developers dug up
Tech blogger Ferstar was first to lay out the details. In a post, he reverse-engineered ZCode's local snapshot mechanism: after login, a background process launched alongside the app packages the entire workspace, encrypts the file contents with AES-256-CTR, wraps the key with a server-issued RSA public key, and uploads the package directly to Alibaba Cloud OSS via a form submission. The private key needed to decrypt it lives only on the server side — the .enc file sitting on a user's machine can't be opened locally.
One sample he provided was specific: an uncompressed 345MB workspace came out to 313MB encrypted, listing 42,411 files. The .git directory accounted for the bulk of it — 86.6% in total, with a 196.1MB LFS cache and 102.2MB of Git objects, versus just about 46MB of actual source code and configuration. Snapshots fire at two points: before every prompt submission, and after a task finishes when the Repo Wiki updates. A single session logged as many as 62 snapshots.
The same day, a developer filed an issue in Zhipu's public feedback repository with a title that asked three "why"s in a row: why upload the entire Git history silently, why encrypt it so even the user can't open it, and why not even offer a toggle to turn it off. The issue noted that after a failed local upload, the snapshot retried 564 times. Another developer reproduced the behavior on their own machine — one project's snapshot came to 748MiB, with .git making up 98.91% of it, on ZCode version 3.12.3.
The broken toggle is the sharpest point in the controversy. According to Ferstar, the "improve experience" and "repository snapshot indexing" switches in the interface only control whether the server uses the data for model training — the local packaging and upload happen regardless. A Git history can still hold keys deleted long ago, abandoned old configs, unpushed branch records, and internal domain names — invisible in the current codebase, but still sitting there in .git.
What Zhipu says
ZCode's apology attributed the uploads to its "repository indexing" feature: generating Repo Wiki pages could trigger a repository data upload, with the data destroyed immediately after the Wiki was generated on the server and never retained. The feature was on by default when it first launched, some users were affected, and the issue has now been fixed.
The stated remedies: open-source the ZCode codebase soon, invite a third-party assessment and publish the review's progress, and give every user one extra weekly quota reset that same day. Several things the statement didn't address remain unverifiable — how many users and repositories were affected, how long the data actually sat on OSS, whether the "destruction" has been independently audited, and which version number the fix shipped in. The open-source timeline was only given as "soon."
That same day, Zhipu also released a new model, GLM-5.3-FlashX, touting an output speed of 200 tokens per second. One developer put the two events side by side in a blog post, quipping that "the whole internet is asking where its code went, while Zhipu is busy shipping a new model."
What developers in China can do now
Many ZCode users tried it out on company projects, where Git history is often more sensitive than the current codebase. For anyone still on an older version, the safer moves are three: upgrade to the patched version first; check the local ~/.zcode/v2/checkpoints directory for snapshots still waiting to be uploaded; and rotate any keys and tokens that ever showed up in the history — don't assume "destroyed" covers what's already gone out the door.
Ferstar offered a harder fix: lock the snapshot directory read-only at the filesystem level, using chflags uchg on macOS or chattr +i on Linux, to block snapshot generation outright. The trade-off is that checkpoint rollback and timeline features stop working too.
Coding agents like this need to read a repository to do their job, so local indexing isn't unusual by itself. The disagreement is about boundaries: reading locally and uploading to the cloud are two different things, and uploading current code versus an entire history are two different things again. If Zhipu's promised open-sourcing actually happens, outsiders will at least be able to check for themselves which paths the snapshot module packages and where its toggles actually connect.
Sources: Ferstar's technical blog reverse-engineering the snapshot mechanism and file composition, the public issue on zai-org/feedback, Phoenix News Tech (ifeng), CocoLoop, and Elliot's Harness Lab; attribution, fix status, and compensation measures verified against ZCode's apology statement.