The Zhipu ZCode Package Leak Controversy: The Unanswered Questions

Over the past two years, discussions on Agent security have mainly focused on model runaway, prompt poisoning and external attackers. In comparison, the data-related behaviors of Agent manufacturers themselves are rarely discussed as a first-level risk.

The Zhipu ZCode incident that broke out recently is shifting the discussion to a direction that has rarely been taken seriously before: whether the Agent manufacturer itself could also become a source of data leakage.

On September 18, tech blogger ferstar released a reverse analysis of Zhipu ZCode. He found that as long as users log in to their accounts, ZCode will package and encrypt the entire working project along with the full modification history in the background, and upload it to the cloud server.

There is no truly available off switch on the software interface, and the decryption key for the encrypted file is only stored on Zhipu's side. Zhipu soon issued an apology, stating that the problem stemmed from a feature enabled by default, that the data would be destroyed immediately after use, and promised to open-source the code repository and introduce third-party review in the near future.

The problem exposed by ZCode this time is by no means an isolated case in the industry.

Not long ago, independent security researcher cereblon proved through packet capture analysis that xAI's programming Agent tool Grok Build would package and upload the user's entire project to Google Cloud Storage, including files that the user explicitly told the AI not to read and passwords that had not been desensitized.

Earlier, Claude Code was found to transmit location and identity information back without the user's knowledge, and Anthropic engineers even confirmed afterwards that it was a deliberate experiment.

More critically, none of these problems were discovered due to supervision or security audits, but often by individuals in the community. Up to now, none of the security frameworks built for Agents in the industry has any rules to restrict the behaviors of manufacturers themselves.

I

The Starting Point is Abnormal Hard Disk Usage

On September 18, when checking the local directory of ZCode, tech blogger ferstar noticed abnormal hard disk space usage. He found an encrypted file of about 313MB, whose size far exceeded the normal daily level. The file could not be opened, but the attached file list showed that this package contained about 42,000 files, more than 80% of which were historical modification records of the project.

This record includes not only project files, but also caches of large files that have been downloaded before and local operation logs. What is packaged is not just the project itself, but also all its experiences since it was created.

Subsequent code analysis found that this historical record was exempted from all security filtering rules during the packaging process.

ZCode's file filtering logic is judged in sequence, and the release of the historical record directory comes before key filtering and size limit. This means that filtering for password files such as pem and key, as well as the 1MB size upper limit, do not take effect for any content in the historical record directory.

This means that a 100+MB packaged file can be taken away entirely, and any passwords and keys that were once submitted to the historical record and then deleted will also be uploaded as they are.

The more troublesome operation comes later: the decryption key is not stored on the user's computer.

ferstar disassembled and restored the upload path of the file: first, the client requests an upload credential and a public key for encryption from the Zhipu server, then completes compression and encryption locally, then bypasses Zhipu's own business server, uploads directly to Alibaba Cloud's object storage service, and then the cloud storage calls back to Zhipu's background.

Let me explain the encryption method briefly here.

The public key is equivalent to a lock that anyone can use to lock things into a box; the private key is equivalent to the key that only the holder can use to open the box. ZCode's approach is that the lock is temporarily issued by the server, and the key is only stored on the server side. The Agent generates an encrypted package on the user's computer, and even the user cannot view what is inside it.

ferstar found that this mechanism is triggered at two times: before the user sends a request to the AI, and after the task is completed. During an active usage process, he observed as many as 62 snapshot records.

After checking the code logic one by one, he confirmed that the two options on the interface that seem to be related to this: one is called "Optimize Experience", which actually only controls whether the data is used for model training; the other is called "Repository Snapshot Index", which actually only controls whether to create a retrieval directory after the server receives the data.

When both are turned off, local packaging and uploading still run as usual. The component responsible for snapshot and uploading will be loaded unconditionally when the software starts, and the only prerequisite is that the user is logged in.

In addition to project files, the snapshot will also package ZCode's own global configuration each time, and carry it across projects.

ferstar tried to manually delete the 313MB file waiting to be sent. Half an hour later, ZCode automatically regenerated a new packaged file. If the Agent fails to upload secretly, it will retry over and over again.

It will be recreated after deletion, which is probably not the level of persistence that an optional auxiliary function should have.

II

Issues That Have Not Been Clearly Responded To

This article quickly sparked heated discussion in the community that night, and Zhipu responded and apologized quickly.

This problem stems from ZCode's "code repository index" feature. This feature is designed to help users generate repository indexes locally to support functions such as session checkpoint recovery including historical versions, historical version rollback, and Repo Wiki.

The Repo Wiki feature may trigger repository data upload when generating Wiki pages. After the Wiki page is generated in the cloud, the relevant uploaded data will be destroyed immediately and will not be saved. Since this feature was enabled by default in the early stage of launch, some users were affected. We are deeply sorry for this, and the relevant problem has been fixed now.

Zhipu also promised to open-source the ZCode code repository in the near future, invite third-party evaluators to review the system operation, and give all users an additional one-time weekly quota reset as compensation, which will be issued on the same day.

The "code repository index" here refers to creating a directory and retrieval system for project files; "Repo Wiki" is a feature that automatically generates a description document for the project; "session checkpoint recovery" and "historical version rollback" are features that allow users to go back to a previous step during conversations with the AI.

These features themselves are reasonable, and the response was timely, but the key point is: what it explained is not the same thing that the community is questioning.

Zhipu said that this index is "designed to help users generate locally". If it is generated locally, why does the entire project need to be sent to the cloud? It is completely technically feasible to do indexing, snapshotting and rollback locally, and there are tools on the market that work in this way.

The statement combines "local index" and "upload to the cloud" into one sentence, as if the latter is a natural extension of the former, but the explanation for this key link is missing.

The response attributed the problem to Repo Wiki "may trigger repository data upload when generating Wiki pages". But ferstar's reverse records show that one of the timings to trigger upload is before the user sends each question, which has nothing to do with generating description documents.

ZCode's current official document clearly states that when generating description documents, it will not read the historical modification records of the project, and only read the filtered code context on demand, which shows that this feature does not require historical records technically.

Then why 86.6% of the previously uploaded packages are historical records? The statement did not answer why the upload range was so large in the first place, whether it was designed that way or caused by a program error, nor did it explain from which version the problem was fixed.

The wording used in the statement that this feature "was enabled by default in the early stage of launch" is more like describing a mechanism-level data leakage as a switch setting of a feature.

ferstar's code analysis shows that the two related options on the interface, one controls training and the other controls indexing, neither of which can restrict the packaging and uploading behavior itself.

The core of the community's doubt is that the control items visible to users cannot control what is really happening, which is a problem of a different level from "a certain feature is enabled by default".

Soon another more sensitive evidence was unearthed by the community: the update log of ZCode v3.12.2, dated September 16, 2026, two days before ferstar published his article.

One record says "Optimize memory usage for repository snapshot uploads". It is almost impossible for an engineering team to optimize memory for an accidental behavior, which shows that "repository snapshot upload" is a normal feature that has been continuously iterated internally.

This update log has been deleted after the incident became public. Deleting public records itself is a new problem independent of the original behavior.

The phrase "relevant uploaded data will be destroyed immediately and will not be saved" only answers how long the data will be retained, but there are many other questions that users really need to know, such as whether the data has left their computers, who has the permission to access it during server processing, who holds the decryption ability of the encrypted package, and what deletion strategy has been implemented for the data that has been uploaded before.

From the perspective of encryption method, the key is on the server side, so "encrypted upload" only proves that the data will not be intercepted by third parties during transmission, and cannot prove that Zhipu itself cannot interpret the content.

The English version of ZCode's privacy policy states that the collection scope includes text, files and code submitted by users "through conversation". But background snapshots are not submitted by users through conversation, and this behavior is not covered in the privacy policy. "Submitting to us during conversation" and "automatically packaging the entire project in the background" are two different things.

This privacy policy also states that when new features involve information collection that is not directly or reasonably related to the original purpose, users will be notified separately through page prompts, interactive processes and other methods, and their consent will be obtained.

Code analysis by another developer Feng Ruohang found that every time the client sends a question, it will unconditionally apply for an upload credential from the server. The server will collect data if it issues the credential, and will not collect data if it does not issue the credential.

The 313MB file found by ferstar was in a pending state at that time, and had failed to be sent 564 times. Feng Ruohang independently reproduced ferstar's forensics process on his own Mac, and confirmed in the snapshot records of 4 workspaces that at least one status file of the snapshot had been written with the mark of acceptance confirmation from the server.

According to the code logic, this mark will only be generated after the upload is confirmed to be received by the server. This means that the data on at least one machine has indeed left the local device. Zhipu's apology, promises and compensation were all issued within a few hours after the controversy broke out, and the reaction speed did not look like it was going to hide the issue for a long time.

However, no matter it is "destroyed immediately" or "will not be saved", such promises cannot be verified or falsified from the outside. All users can see is that the data has left their own computers, and what happens next depends entirely on the self-discipline of the manufacturer.

Whether Zhipu's promises of open source and third-party review can change this situation depends on which version is open-sourced, and whether the review covers the client or the server. There is no answer to these questions at present.

III

What is More Sensitive Than Code Data

If some manufacturers are intentionally collecting user data, what they want may not be the user's code itself.

Because public projects on major code hosting platforms provide sufficient corpus for model training. Private code certainly contains trade secrets, but from the perspective of model improvement, the marginal value of just getting a batch of additional code text is not high.

What is really scarce is three things.

The first is the causal chain of modifications.

What is stored in the historical modification records of a project is not just snapshots, but the complete process of "it looked like this before, for what reason, it was changed to that". This sequence with antecedents and consequences is the ideal learning material for training programming models: given a project status and a modification intention, what modifications should the model make.

The second is usage trajectories with result labels.

ZCode's trigger mechanism takes a "panoramic photo" before each user sends a question, and it also has a rollback function, so users can undo the modifications made by AI. The combination of these two actions naturally records the complete cycle of "question + pre-operation status + post-operation status + whether the user is satisfied (whether it is undone)". This kind of data is extremely expensive in AI training, and usually requires hiring people to label it specially. ZCode's snapshot mechanism is equivalent to allowing users to generate these labels for free during normal usage.

The third is real projects that have never been seen by any model.

At present, almost all public programming evaluation questions have been "done once" by various models during training, leading to inflated scores. Real private projects that have never entered the training set are the most valuable materials for internal capability evaluation.

These three things are highly consistent with the composition of ZCode's upload package, which is why the community has never accepted the explanation that "it is only for generating description documents".

But on the other hand, if the goal is to systematically collect training data, a more precise approach is to only extract the question content and code modifications, and there is really no need to package even hundreds of megabytes of large file caches and complete operation logs together.

This form of over-collection is more like the engineering team reused a general packaging logic when developing the snapshot feature, putting all files related to indexing and rollback into the package all at once. In addition, cloud storage itself has costs, and a large number of small projects and practice codes of individual users have limited actual value for model training. The risk-reward ratio of collecting data from paying customers, especially enterprise customers, is very uneconomical.

It must be admitted that the motivation to use this data to improve models and tools is valid, and the path is ready; but from the rough degree of the upload package, the radical product decision superimposed with engineering laziness is more consistent with the existing evidence than "Zhipu deliberately wants to do something".

Of course, we cannot ignore the severity of this problem just because Zhipu has no subjective intention, which does bring security risks to users.

IV

Batch Transgression of Agent Manufacturers

Controversies similar to the ZCode incident have broken out more than once this year.

In July this year, independent security researcher cereblab conducted a complete network packet capture analysis on xAI's Grok Build, and made all the evidence and reproduction steps public.

The phenomenon he found is more exaggerated than ZCode: Grok Build will package the user's entire project into a code package and upload it to Google Cloud Storage. The upload scope covers all files, including files that the user explicitly told the AI "do not read" in the conversation. In a 12GB test project, the confirmed file size had exceeded 5GB by the time the packet capture was interrupted.

The test also found that password and key files in the project were even uploaded as they are, without any desensitization treatment. After users turn off the "Improve Model" option in the settings, the upload still proceeds as usual, only the training authorization is turned off, and it does not affect whether the code leaves the computer.

Elon Musk publicly promised to delete all uploaded data after the incident was exposed, and xAI turned off the upload function on the server side.

Earlier on March 31, due to the negligence of a configuration file in a version release of Claude Code, about 60MB of source code mapping files were mistakenly packaged into the publicly released installation package, allowing external developers to see the architecture of this tool.

The community found that Claude Code polls the Anthropic server for remote configurations every hour, and the configuration items include multiple control switches that can force the program to