ZCode, an AI coding tool under Zhipu (智譜), was recently exposed for silently packaging a user’s entire workspace in the background while logged in, including the complete .git history, encrypting it, and uploading it to Alibaba Cloud OSS object storage, with the privacy setting toggle completely unable to stop it. After the news exploded in the developer community on September 18, Zhipu quickly issued an apology statement, admitting that the problem lies in the “code repository indexing” feature enabled by default, and promised to open-source ZCode’s code in the near future, introduce third-party review, and reset usage quota once for all users.
Silently packaging the entire workspace: an investigation starting from 700MB of disk usage
The incident began when a developer codenamed ferstar discovered ZCode’s data root directory while clearing disk space. ~/.zcode It was abnormally using more than 700MB of disk space. After investigating further, he v2/checkpoints/ Found a 313MB encrypted archive in the directory (.enc), the status file next to it records the workspace path, the encrypted size, and as many as 564 failed upload retries.
🚨 Stop using ZCode on your Mac until you read this.
I’ve had ZCode open on my Mac pretty much all day for a while now. It’s a nice app, and Zhipu gives away a lot of free tokens, so it was easy to like.
But someone when reverse engineering the desktop client, found out that… pic.twitter.com/5eCFe3msMm
— netrunner (@plotarmordev) September 18, 2026
According to the records in the status file, ZCode scanned his 10GB commercial project and, after excluding dependency directories such as node_modules, packed the remaining 345MB of content (almost entirely core source code) into a 313MB encrypted archive, marked as “baseline” (full snapshot), and locally pending/ The directory is queued for upload. ferstar said that after deleting this archive, ZCode repackaged a new 313MB archive within half an hour, and the retry count jumped from 564 to 565; deleting the file only treats the symptoms, not the root cause.
He even reverse-engineered the client’s app.asar Packaged file, reconstruct the complete upload process: the ZCode client first sends to zcode.z.ai Request upload credentials; the server returns an OSS form signature, object key, size limit, and a set of RSA public keys; the client locally compresses the workspace into a tar.gz, encrypts it with AES-256-CTR, then wraps the key with RSA-OAEP-SHA256, and finally uploads the encrypted archive directly to Alibaba Cloud OSS via an HTTP POST form; OSS then calls back to the Zhipu backend to register the snapshot. When checking active network connections, also confirm that the ZCode program continues to communicate with zcode.z.ai and remain connected to two Alibaba Cloud OSS nodes.
The most ironic part: the encryption key belongs only to the server.
The most disturbing detail of this incident is the encryption design itself. ferstar pointed out that ZCode uses typical envelope encryption: the content is encrypted with a one-time symmetric key using AES-256-CTR, and the symmetric key is then wrapped with RSA-OAEP-SHA256 using an RSA public key delivered in real time by the server. The corresponding private key never appears on the user’s machine; only Zhipu’s server side holds it.
ferstar tried to decrypt the archive with every local private key on the system, and all attempts failed. That 313MB of ciphertext sitting on the user’s own hard drive cannot be opened by the user or the ZCode client; the only thing that can decrypt it is the Zhipu backend. If this design were really meant to let users roll back or sync across devices, the key should be stored locally (just like Git or Time Machine). The key belongs only to the server, and it serves exactly one purpose: to ensure the server can read your code at any time.
And the composition of the archived contents made matters even worse. Because the manifest is stored locally in plaintext, ferstar was able to break down a snapshot of 42,411 files:.git/lfs/ accounted for 196.1MB (56.8%),.git/objects/ Accounts for 102.2MB (29.6%),.git/logs/ It accounts for 0.6MB (0.2%), while source code and documentation account for only 46.2MB (13.4%). The .git directory alone makes up 86.6% of the archive contents.
This means that far more is uploaded to the cloud than the current working tree: it includes historical API keys and sensitive configuration files that were deleted in later commits, the names of unpushed local branches (which may leak unreleased feature plans), and the internal GitLab hostname and repository path recorded in .git/config. For enterprise users, this amounts to handing over the entire development history and trade secrets packaged up.
Privacy toggle is effectively useless: triggered upon login
ferstar further cross-checked the UI settings against the code and found that neither of the two toggles related to snapshot upload could prevent this behavior. “Optimize Experience” (optimizeAgentExperienceEnabled) only controls whether data is authorized for use in model training; snapshot packaging and upload continue as usual. “Repository Snapshot Indexing” (repoSnapshotIndexingEnabled) only controls whether the server indexes uploaded snapshots; the local packaging and upload process is completely unaffected.
From the main program assembly, the snapshot sidecar program is instantiated unconditionally at startup, with no conditional based on user preferences at all. The only requirement is a valid login token (JWT). In other words, as long as the user is logged in, this background pipeline runs permanently, and no UI setting can turn it off. There are two trigger points: before every prompt (captureBeforePrompt) and when a task completes. A single active session generated 62 snapshot events.
Yet ZCode’s privacy policy explicitly states that it collects “text, files, and code submitted in conversations,” which is common among AI coding tools, but across the entire policy, FAQ, and changelog, there is no mention whatsoever of “silently packaging and uploading the entire workspace and complete Git history”—only a boilerplate statement that “the optimization program is off by default and data will not be used for training without consent.”
Community in uproar: Developers demand answers and complete deletion
After the incident was exposed, it quickly spread through the developer community. ferstar’s original investigative tweet surpassed 276,000 views within 13 hours, and warning tweets in the Chinese-language community accumulated more than 63,000 views. Developer @plotarmordev directly urged everyone to “disable ZCode before reading this,” and noted that he had also been badly affected. On Hacker NewsThreadWithin 20 hours, over 250 points were accumulated, and one developer sarcastically remarked, “Since you took so much code, at least we hope we’ll soon see open-source AGI.”
Some developers have also compared it with the Grok Build incident from two months ago: xAI’s coding agent was likewise found to upload the full Git history to Google Cloud, but Grok’s upload behavior was recorded in its own logs and a toggle to disable it was later provided, making it an “accident of insufficient oversight”; ZCode is the opposite: the encryption keys are held only server-side, the toggle was verified to be impossible to turn off, it keeps retrying even after the archive is deleted, and it is triggered by login rather than by use, leading the community to describe it as “a deliberate design that encrypts its own users’ data against them.”
Facing an overwhelming wave of criticism, the official Zhipu ZCode team released a statement in the community, admitting that the problem stemmed from the “Codebase Indexing” feature, which is enabled by default: the feature was designed to generate a local repository index to support conversation checkpoint recovery and Repo Wiki, but generating Wiki pages may trigger repository data upload. After cloud generation is completed, the data is immediately destroyed and not retained, and the related issue has been fixed. The official team also promised to open-source the ZCode code soon, invite an independent third party to audit the system’s operation, and continue to publicly disclose progress, while providing all ZCode users with a one-time usage quota reset as compensation.
Conclusion
This incident is a wake-up call for the entire “open-source model + closed development tool” combination. Model weights can be downloaded as open source and run locally, but if the development tool wrapped around the model (the desktop harness) keeps sending data back to the cloud, so-called “local execution” is just an illusion. ferstar’s recommended last line of defense is to lock down ZCode’s checkpoints directory at the filesystem level (chflags on macOS, chattr on Linux), making it impossible to write snapshots at all. It is normal for AI coding tools to read code; the question is whether, the moment you log in, the tool is silently packaging up your entire development history—and only it can get the key.
Source: KOCPC Chinese