Zhipu's ZCode “Silent Upload” Incident: A Review and Analysis

Zhipu's ZCode "Silent Upload" Incident: A Review and Analysis

Note: This article is compiled from public reporting between September 16 and 21, 2026 (SCMP, Wallstreetcn, ET Net, tech360, Tokenstead, Odaily/BlockBeats, among others), from the reverse-engineering analysis and reproduction work of technical blogger ferstar and independent open-source contributor Feng Ruohang (Vonng), from a legal letter sent by Taiyuan Chengming Technology Co., Ltd., and from official Zhipu statements. Some community rumors (such as "ordinary users routinely upload more than 50GB") lack independent evidence and are not accepted here. A "stock down 50%" figure that appeared in some financial media headlines is a mistranslation of "4.9%"; the figures in the body text are authoritative.

Background: Zhipu (full name Beijing Zhipu Huazhang Technology Co., Ltd.; international brand Z.ai; HKEX ticker 02513.HK) is one of China's leading large-model companies. Born out of technology transfer from Tsinghua University, it is known for open-sourcing and commercializing the GLM model series, listed in January 2026, and is called the Hong Kong stock market's "first large-model stock." ZCode is its AI coding workbench.

---

1. Timeline of Events

---

2. Technical Breakdown

2.1 The Discovery's Starting Point: A 313MB File That Would Not Be Deleted

While investigating ZCode's local directories, ferstar noticed abnormal disk usage and found a 313MB encrypted archive under ~/.zcode/v2/checkpoints, sitting in "pending upload" status after 564 failed attempts. A separate workspace snapshot from a public repository (538 files, about 15KB after compression and encryption) had already been received by the server. The archive originated from a commercial project workspace of 345MB and 42,411 files. After he deleted it manually, ZCode regenerated a fresh package within about half an hour, and the retry count kept climbing. Failure means retry; deletion means rebuild. Wallstreetcn's assessment was restrained: "It rebuilds even after you delete it. That is perhaps more persistence than a dispensable auxiliary feature deserves."

2.2 What the Upload Contains

The packaging manifest sits locally in plaintext, itemized in enough detail to verify entry by entry:

86.6% of it is Git history, not current code. The weight of that fact needs unpacking. A Git object store is not a snapshot of the working directory but the complete lineage of a repository since its creation. API keys removed in later commits are still inside. Unpushed branch names can expose unreleased product plans. .git/config holds internal hostnames and repository paths. An intercepted archive is years of engineering history, not the handful of files you happened to have open at the time. On top of that, each snapshot also packages ZCode's own global configuration, carrying it across projects.

2.3 The Upload Pipeline (reconstructed from app.asar)

During testing, the running client maintained persistent connections to zcode.z.ai and two Alibaba Cloud OSS nodes.

The key point: the private key exists only in Zhipu's cloud. ferstar tried unpacking with every private key on the machine and failed each time. The ciphertext on a user's disk cannot be opened by the user or by the ZCode client; only Zhipu's backend can decrypt it. A simple analogy: the public key is a lock that anyone can use to seal something into a box; the private key is the key that only its holder can use to open it. In ZCode's design, the lock is issued temporarily by the server, and the key stays on the server's side. ferstar's conclusion was a single line: "A key that only the server can use serves exactly one purpose: making sure the server can read your code whenever it wants."

2.4 When It Triggers, and Who Decides

Uploads fire at two moments: before the user sends a request to the AI, and after a task ends. Up to 62 snapshot records were observed in a single active session. Feng Ruohang's supplementary analysis showed further that the client unconditionally requests upload credentials from the server every time it sends a question; if the server issues credentials, collection happens, and if it does not, collection does not happen. The decision to collect therefore sits entirely in the cloud, and the client is merely the executor. This means that even if some version of the client "appears not to upload," a single switch on the server can turn it back on as long as the code path remains.

2.5 The Ordering Flaw in the Filter Rules

ZCode's file-filtering logic evaluates in sequence, and for the .git directory the pass-through rule is ordered before the secret filter and the size limit. As a result:

• Filters targeting sensitive files such as .pem and .key have no effect on content inside .git.
• The 1MB per-file size limit has no effect on content inside .git.
• Any password or key that was ever committed and later removed is uploaded as-is in the form of a Git object.

This is the point developers most easily overlook: a clean working directory does not equal a clean Git history. The database passwords and cloud service credentials listed in Chengming Technology's legal letter most likely went out through exactly this path.

2.6 The "Decorative" UI Toggles

Two seemingly relevant options in the interface were checked against the code one by one by ferstar:

• "Optimize experience" (optimizeAgentExperienceEnabled): controls only whether data is authorized for model training.
• "Repository snapshot indexing" (repoSnapshotIndexingEnabled): controls only whether the server builds a search index after receiving data.

With both switched off, local packaging and uploading run as usual. The sidecar component responsible for snapshots and uploads loads unconditionally when the software starts, gated by no user preference at all; the only prerequisite is a valid login JWT.

2.7 A Deeper Structural Finding: The Upload Is Not on the Agent's Tool List

The public prompt-collection repository OrcaPromptVault preserves a 131KB ZCode system prompt together with the complete definitions of 31 tools, providing a second, independent corroboration:

• The checkpoint/rollback feature is indeed wired into the system prompt: the template "Workspace rewind applied. rewindId, checkpointId, strategy, restoredFiles" appears five times. This is the user-facing end of the snapshot pipeline.
• But not one of the 31 tools is a snapshot, upload, or telemetry tool. Across the whole 131KB of instructions, none of the words Aliyun, OSS, upload, or privacy appears.

This explains why no permission setting can stop it: the outbound pipeline is not one of the Agent's tools but a host-level sidecar running outside the tool loop. The Agent itself does not know it exists, and when a user tells the AI in conversation to "not read a certain file," that instruction means nothing for this channel. There is also a ReadSessionContext tool that can read other persisted ZCode sessions by session ID: session content is persisted locally and captured by the cloud at the same time.

2.8 The Only Effective Local Defense

Deleting files waiting to be sent does not work (they are rebuilt within half an hour). The workable approach ferstar verified is to make the checkpoint directory non-writable at the filesystem level:

# Linux
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

# macOS
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints

The cost is that the checkpoint rollback UI stops working, and that is precisely the feature that needs to upload your code before it can work. Conversation, completion, and tool calls are unaffected. To restore, use chattr -i or chflags nouchg.

---

3. Analysis of the Issues

3.1 The Contradiction Between the Official Explanation and the Technical Evidence

The core passage of Zhipu's first statement: "The feature is designed to help users generate repository indexes locally... Repo Wiki may trigger repository data uploads when generating Wiki pages... Because the feature was enabled by default early after launch, some users were affected." That passage conflicts with the evidence in at least five places:

1. "Generated locally" and "uploaded to the cloud" are merged into a single sentence. If the index is meant to be generated locally, why send the entire project to the cloud? Local indexing, local snapshots, and local rollback are technically feasible; tools on the market do exactly this. The statement frames the latter as a straightforward extension of the former, leaving the most critical link in the explanation missing.
2. Scope mismatch. ZCode's official documentation states that Repo Wiki generation "does not read the project's historical change records, only filtered code context as needed." For a feature that technically does not need Git history, why is 86.6% of the upload package history? Whether this is by design or a software defect, the statement does not answer.
3. Timing mismatch. Repo Wiki is a low-frequency operation, yet snapshots fire before and after every question, 62 times in a single session.
4. Controls mismatch. If this were merely "a feature that was on by default," some switch to turn it off should exist. In fact, no client-side switch prevents the packaging and uploading. The community's core objection is that "the controls users can see cannot control what is actually happening," which is not on the same scale as "a feature was opened by default."
5. Traces of iteration. The September 16 changelog entry, "optimized memory usage of repository snapshot uploads," shows a feature under continuous maintenance: an engineering team does not optimize memory for an "accidental behavior." Deleting that public entry after the fact then constitutes a new problem in its own right, independent of the original behavior.

3.2 The Double Meaning of the Encryption Design

"Encrypted upload" is often used in PR language as proof of "security," but here it needs to be taken apart:

• What it proves is that a third party cannot intercept the data in transit.
• It does not imply that Zhipu itself cannot read the contents. Quite the opposite: the design goal of this envelope encryption is precisely that "only Zhipu can decrypt."

Further, precisely because only Zhipu can decrypt, the promise "destroyed after use, never retained" cannot structurally be verified or falsified from outside. All users can see is that data left their computer; what happens next depends entirely on the vendor's self-restraint. A TNW commentary cut to the point: "Zhipu encrypted the package so that only Zhipu can open it, and now only Zhipu can say it has been deleted."

"Destroyed immediately" answers "how long is data retained," but what users actually need to know also includes: whether the data has already left the computer (Feng Ruohang confirmed it had on at least one machine), who had access during server-side processing, who holds the decryption capability, and what deletion policy was applied to previously uploaded data. Neither statement answered any of these head-on.

3.3 The Coverage Gap in the Privacy Policy

The English version of ZCode's privacy policy describes the collection scope as text, files, and code that users submit "through conversation," the standard inference-context disclosure that every AI coding tool makes. Background automatic packaging of whole workspaces clearly falls outside this scope: "submitted to us in conversation" and "automatically packaged in the background as an entire project" are two different things.

ferstar searched the policy, the FAQ, and the changelogs and found no explanation of packaging and uploading entire workspaces and Git history.

More awkward still, the policy itself states that when a new feature involves information collection without a direct or reasonable connection to the original purpose, the company should provide separate notice and obtain user consent through page prompts, interactive flows, or similar means. That clause was effectively violated by its own product. Add the executive's public promise that the company "would not implement anything beyond the features listed on the website": workspace snapshots do not appear on the ZCode website's feature list.

3.4 Crisis Response: Wins and Misses

Wins: The apology, commitments, and compensation all landed within hours as the controversy escalated; the speed does not look like that of a company preparing to hide things long-term. Open-sourcing the client, bringing in CAICT and NSFOCUS for audits, and establishing a vulnerability bounty all point in the right direction. NSFOCUS's confirmation of "zero data in the bucket, upload chain severed" was the first third-party evidence anyone could point to in this affair. Getting through apology, remediation, audit, and open-sourcing within three days is on the faster side among comparable incidents.

Misses:

• The first statement rendered a "mechanism-level data transfer" as "a feature's toggle setting," which the community read as downplaying.
• It did not explain from which version the problem existed, nor the deletion policy and evidence for historical uploads.
• One extra weekly quota reset for all users as compensation sits on a different order of magnitude from what was uploaded, especially for enterprise customers.
• Compared with xAI's verifiable loop on Grok Build (server-side upload turned off, then researchers re-test and confirm, then a zero-retention policy announced), Zhipu's early handling lacked a step that third parties could re-test.

The limits of both the audit and the open-sourcing need to be spelled out: what CAICT and NSFOCUS confirm is "zero data now" in the bucket, which does not amount to proving that data from the incident period was never accessed, exported, or used for other purposes. Open-sourcing has not crossed that boundary either.

On September 21, the ZCode codebase went public on GitHub (zai-org/ZCode, Apache-2.0): 6,973 files and about 1.03 million lines of code committed in one go, in a repository with only two commits, an empty initial commit and one "feat: open source"; no tags, no releases, the development history flattened wholesale; pull requests closed and Issues disabled. In his September 21 update, ferstar checked that code item by item: the upload-path implementation (the upload credential endpoint, direct-to-OSS upload, AES-256-CTR encryption and public key distribution) had been stripped out completely, with zero hits repository-wide; the checkpoint rollback code is a purely local tool that calls the local Git to run diffs and stores metadata in a local directory, with no relation to the cloud at all. Zhipu had placed the upload inside the narrative of the "codebase indexing" feature, mentioned together with session checkpoint recovery, historical version rollback, and Repo Wiki. Now checkpoints and rollback have been confirmed by Zhipu's own code to be purely local, and Repo Wiki by official documentation does not read historical change records; why the upload package needed to carry off 86.6% Git history still has no answer.

The other half of the problem lost its entry point for verification. A repository with two commits and zero tags leaves no track of "when introduced, when removed": when Repo Wiki and snapshot uploading were written into the client, what changed around September 16, and exactly which code the fix removed cannot be traced. The question people pressed for days (is the open-sourced version the fixed build or the build from the incident?) got a third answer: a code slice with its history flattened and not fully consistent with the live product. The independent blogger Silent Star's line-by-line comparison found that the App build leads the open-source repository by one minor version, that several feature blocks such as bot integration and remote control were not released with the open-sourcing, and that build records point to an internal commit not present in the repository. The open-sourcing delivered on "inspectable," but the inspectable scope ends at the present: the flattened history, and the batch of data that already left people's computers, cannot be checked.

3.5 Deliberate or Negligent?

Two camps formed in the community.

The "deliberate" camp points to: encryption only the server can decrypt, decorative toggles, rebuild-after-delete, no mention in the privacy policy, and a deleted changelog entry. ferstar's own wording leans toward this camp.

The "negligence" camp argues: if the goal were systematic collection of training data, the precise approach would be to extract only prompts and code changes, and there would be no need to package hundreds of megabytes of LFS cache and operation logs. Cloud storage costs money, and the training value of the many personal practice projects is limited. Going after paying enterprise customers' data makes for a terrible risk-reward trade. This pattern of over-collection looks more like an engineering team developing the snapshot feature while reusing a generic packaging routine and sweeping every file related to indexing and rollback into the archive.

But a key perspective from Wallstreetcn must be added here: why the community never accepted "it is only generating documentation." If a vendor really wanted to collect user data, what it wants most may not be the code itself: public code-hosting platforms already provide enough corpus, and the marginal training value of private code text is not high. What is genuinely scarce are three things:

1. The causal chain of changes. Git history stores not snapshots but the full process of "what it looked like before, why it changed, what it became," the ideal material for training coding models.
2. Usage traces with outcome labels. ZCode takes a full snapshot before each question and can also roll back. The combination naturally records the complete loop of "question + state before + state after + whether the user was satisfied (did they undo it?)," data that is extremely expensive in AI training and usually requires hiring annotators.
3. Real projects no model has seen. Public benchmarks have almost all been "done once" by models in training; real private projects are the most valuable raw material for internal capability evaluation.

These three match the composition of ZCode's upload package closely. This is why the "Repo Wiki" explanation persuaded almost no one in the technical community: not because everyone is certain Zhipu is doing this deliberately, but because the mechanism happens to deliver the most valuable training data, in its most complete form, to a place only Zhipu can decrypt, while the reason offered is a feature that does not need this data at all.

My judgment: an aggressive product decision compounded by engineering laziness fits the available evidence better than "Zhipu was deliberately up to something." It must be stressed, though, that absence of malice does not lighten the consequences. To an enterprise customer whose database passwords and employees' personal information were uploaded, the vendor's "we intended to build a Wiki" means nothing; and the fact that "the motive to improve models with this data exists and the path was ready-made" is by itself enough for any corporate security leader to order a ban.

3.6 Potential Legal Risks

• The Personal Information Protection Law (PIPL): employees' and end users' personal information was packaged and uploaded without notice or consent, and the privacy policy's own "separate notice" clause went unfulfilled.
• The Data Security Law / Cybersecurity Law: enterprise source code, system architecture, and cloud credentials are important commercial data collected without authorization.
• Cross-border data transfer: Chengming Technology pressed on whether the uploading entity is domestic or offshore, and whether the OSS node locations and access entities constitute a transfer out of the country. This is the question Zhipu has yet to answer clearly, and the most damaging item in the legal letter.
• Contractual: paying enterprise users can pursue breach of contract under their service agreements; Chengming Technology's demands for "access logs, export logs, and deletion certificates" are laying the groundwork for exactly that.

---

4. Not an Isolated Case: The 2026 Wave of Agent Vendor Overreach

The common thread across all three is sobering: not one was discovered by vendor self-review, industry audit, or regulatory inspection: one came from a configuration lapse that leaked source code, one from a researcher's proactive packet capture, one from a blogger's alarm at disk space that did not look right.

There is another layer of irony. When ZCode launched in July, its marketing pitched directly against Claude Code, just weeks after the Claude Code telemetry controversy, positioning itself as the alternative that could escape being remotely controlled by a vendor. Grok Build's upload incident broke in roughly the same month ZCode launched. Three months later, a problem of the same nature surfaced on ZCode itself, with an even larger data scope. The one who played the trust card crashed first, perhaps the most cautionary scene in this year's AI tool competition.

---

5. Editorial: Data Security for Public-Facing Large Models Cannot Rest on "Promises"

1. "Open weights" does not equal "open behavior"

Zhipu won the trust of the global developer community with open-source GLM weights, and what the ZCode incident exposed is exactly how misplaced that trust can become. Many people in the discussion assumed ZCode was open source because GLM is. It is not. The weights are open; the harness is closed, and ZCode is the first-party harness Zhipu built for its own models, sold on "deep integration unmatched by third-party editors."

What model open-sourcing solves is "can you run it locally," not "what is the vendor's client doing on your machine." A Tokenstead commentary spelled this out: a locally running model wrapped in a harness that phones home is not local. The layer around the model (the desktop app, the update pipeline, the telemetry) is part of the trust surface too. Open weights are where trust starts; a closed client is where it leaks. When a company sells "escape vendor remote control" while embedding an outbound collection channel in its own client that the server can operate remotely, that contrast is itself the biggest loss of trust.

2. The mismatch between consenter and victim is structural

In the ZCode and Grok Build scenarios, the person clicking "agree" is an individual developer, while the fallout of a leak lands on employers, clients, and even end users, who never appear in any consent flow and have no channel to learn that their data was packaged and uploaded. Chengming Technology's case makes this mismatch concrete: one employee installed a tool, and the company's database passwords and end users' personal information ended up in someone else's bucket.

The bearer of the risk and the giver of consent are not the same person, so individual-level informed consent structurally cannot solve this problem, no matter how clear the popup or how prominent the toggle. This means enterprises must govern AI coding tools as part of their supply chain rather than treating them as an employee's personal productivity choice.

3. "Encryption" and "destruction" cannot be labels that waive inspection

The industry needs to converge on one understanding: when the decryption key is held only by the vendor, "encryption" protects against third parties, not against the vendor; when only the vendor can read the data, "deleted" is a statement, not evidence. Only two forms of assurance actually hold: either the data never leaves the user's device (a local-first architecture), or every step after it leaves can be re-tested by an independent third party (verifiable zero retention). xAI later allowed researchers to re-test and confirm that uploads were off, a minimum standard worth borrowing; Zhipu inviting NSFOCUS to confirm the bucket was cleared is a step in that direction, but it proves "not there now," not "nothing was done then."

4. The blind spot in existing security rules: outward only, never inward

The permissions Agents acquired over the past year exceed those of any previous category of software installed on personal computers: reading every file in project directories, executing commands autonomously, maintaining a constant connection to vendor servers, and receiving remote configuration updates in the background. Almost no consumer software used to meet all four conditions at once.

Rules around these new permissions are indeed updating quickly: OWASP published the first top-ten risk list for autonomous Agents in late 2025. In January 2026, Singapore issued the first Agent governance framework, requiring every Agent to carry a verifiable digital identity; in February, the U.S. NIST launched an AI Agent standards initiative; on August 2, the EU AI Act's high-risk obligations took effect; industry-level certification standards for coding Agents have appeared as well.

But all these rules guard against tools being exploited by outside attackers: hijacked by malicious instructions, induced to invoke other systems beyond their authority. The design assumption of the entire defense line is that "the vendor stands with the user and threats come from outside." The outbound channels in ZCode and Grok Build land precisely in the blind spot of that assumption: they are not on the Agent's capability list, not subject to permission approval, running outside the entire tool loop, and even the AI assistant itself cannot perceive them. Audit these behaviors line by line against any existing security framework, and no alarm fires.

5. Audits and open source both have limits, but both beat "nothing"

Some argue for auditing Agent data behavior the way listed companies' financial reports are audited. The analogy partly holds: periodic, standardized, independent third-party reports that buyers can understand are the right form. But the differences are sharp: financial audits examine ledgers that law requires companies to keep, while no regulation requires vendors to record "what data left users' computers," so the evidence itself is inadequate; Agent clients update weekly, or even poll remote configuration hourly to change their own behavior, so an annual audit is stale the moment it is issued; and public-company audits carry securities law and joint liability for audit firms, while Agent audits currently carry nothing at all.

Open source is the other path. Zhipu open-sourced ZCode after the fact; OpenAI's Codex CLI and Gemini CLI were open source long before. Open source lets the community check whether a client contains any outbound transfer mechanism, and transparency itself is a constraint; this time it delivered the part that could be delivered: the community checked and confirmed that the upload mechanism in the client has indeed been removed. But open source has several inherent limits, and the ZCode case confirmed each in turn: it illuminates the client but not the server; the repository arrived as two commits with no development history, leaving "when introduced, when removed" untraceable; the live App build comes from an internal commit outside the repository and contains feature code not released with the open-sourcing, so compiled artifacts do not equal the public source; and reproducible-build verification is still missing. The blogger who did the line-by-line comparison, Silent Star, summed up this open-sourcing in a line worth quoting: "Publishing a scrubbed slice that lags the shipped product proves good faith, not the security of the live version."

Beyond those two main roads, three more pragmatic paths deserve industry support:

• Egress declarations: require vendors to publish which server addresses an Agent connects to and which categories of data it transmits. cereblab's analysis of Grok Build used standard packet-capture tools; with an egress declaration as a baseline, anyone can compare traffic for anomalies at low cost.
• Locally readable transfer logs: keep an exportable record on the user's own computer stating the volume, destination, and data category of each transmission, directly resolving the most glaring design issue: the encrypted package is generated on your machine while you cannot see what is inside it.
• Liability insurance: let underwriters, not certification bodies, assess vendors' data behavior. Underwriters lose money when they misjudge, which is currently the only mechanism that turns "careful scrutiny" into an economic interest.

None of these is technically difficult; the difficulty is incentives. Only two forces currently push them into reality: procurement review by enterprise customers, and the occasional community exposé. The former covers enterprise editions only; the latter depends entirely on luck.

6. What to expect from regulation: from "defending against external attacks" to "constraining the vendor itself"

The ZCode incident should push regulators to cover the missing half: vendors' own data collection behavior needs to be added to compliance checklists, including mandatory disclosure of all outbound data channels in clients, non-essential collection off by default, verifiable deletion mechanisms, and technical options that let enterprise customers keep data from crossing borders and from leaving their devices. The episode lands just before a meeting of the Chinese and U.S. heads of state, with AI privacy and cybersecurity listed by several foreign media outlets as possible agenda items; whether regulators use the occasion to issue dedicated requirements for AI coding assistants is worth watching.

7. The knock-on effects for Chinese large models going global

One point cannot be dodged: this incident happened at a critical moment when Chinese AI companies are going global together and working to offset "data security" accusations. SCMP quoted Shanghai developer Tuxi with a representative judgment: the damage to community trust will outweigh the damage to the model itself, and "this is basically like stealing from users"; overseas GLM users can switch to Codex or other tools to keep calling the model, but trust in the Zhipu brand will not migrate with them. A Longbridge market analysis noted that the incident created a "trust premium" for competitors such as Cursor and GitHub Copilot that can demonstrate local-first processing, and significantly raised the execution risk of Zhipu's enterprise expansion.

This is not just a trust crisis for Zhipu alone but a credibility loss for the whole Chinese large-model camp in front of overseas enterprise customers. Repairing it will not come from PR but from data practices that are more transparent and more verifiable than those of competitors.

8. The most likely trajectory: stratification

The realistic trajectory is most likely stratification. Large enterprises will add data-behavior clauses and audit rights to procurement contracts, and the costs they pay will ultimately show up in prices. The consumer editions used by individual developers will remain in a state where nobody audits and nobody is accountable.

The problem is that consumer editions are exactly where most people keep writing code after work hours, and exactly where they are most likely to open company projects under a personal account. Chengming Technology's 32,932 files most likely flowed out this way. Stratification solves enterprise compliance; it does not solve the problem of the paths along which data actually flows.

---

6. Practical Recommendations for Developers and Enterprises

Individual developers

• Review the outbound traffic of every AI coding tool: monitor with a proxy or tools such as Little Snitch / OpenSnitch, watching for high-volume POSTs to non-API domains, especially object-storage domains.
• Check local directories such as ~/.zcode, ~/.cursor, and ~/.claude regularly for caches or pending-upload files of anomalous size; ferstar's discovery began with disk space that looked wrong.
• If you still use ZCode, you can make the checkpoint directory non-writable as described in section 2.8: this open-source release has been community-verified and the upload path confirmed removed (see section 3.4), but since the client supports hot updates, an extra safeguard does no harm.
• Scrub sensitive information from Git history (git filter-repo, BFG), and change key management from "delete after committing" to "never commit"; secrets in history are more dangerous than those in the working directory.
• For commercial projects, prefer local models or enterprise options that offer zero-retention commitments and permit network audits; ask any harness two questions: what does it send once you log in, and who can decrypt what it stores.

Enterprises

• Bring AI coding tools into software supply chain governance, establish an approved whitelist, and explicitly prohibit using unapproved tools on company projects with personal accounts.
• Deploy DLP and egress controls at the network layer, blocking unapproved object-storage domains (OSS, S3, GCS) by default; the destinations in all three incidents were cloud object storage.
• Require vendors to provide data-flow diagrams, lists of egress endpoints, and re-testable deletion mechanisms, write these into contracts, and retain audit rights.
• For teams already using ZCode, assess risk along the path Chengming Technology took: inventory the affected workspaces, rotate every credential that could appear in Git history (not only those in current configs), assess statutory reporting obligations for personal data exposure, and where necessary demand access and deletion certificates from Zhipu.

---

Conclusion

What is most worth remembering about the ZCode incident is not the 313MB file but how it was found—a blogger thought the disk space looked off. In an age when AI Agents hold full permissions to read and write files, execute commands, and access the network, users' trust in vendors is more fragile than ever, while the means to verify that trust are close to zero. Three similar incidents this year, three accidental discoveries, zero from institutional oversight.

Zhipu cannot buy back the Git history that left in those packages with a weekly quota reset and two apology statements. But if the industry can genuinely build standards for data practice that are verifiable rather than merely promised: egress declarations, local transfer logs, re-testable deletion, and vendors' own behavior brought into security frameworks, then the cost of this accident will not have been paid for nothing. Otherwise, the next discovery will again depend on someone, late at night, feeling that the disk does not look quite right.

---

Primary Sources

• ferstar, "Inside ZCode: Silently Uploading Your Entire Git History to the Cloud," with updates on September 19 and 21; 2026-09-18/21
• Silent Star, "I Found Git History in ZCode's Local Snapshots" and "ZCode's Open-Source Day One: Taking the Installer Apart and Comparing It Line by Line Against the GitHub Source"; 2026-09-18/21
• Zhipu official statements (2026-09-18/21) and the ZCode open-source repository (github.com/zai-org/ZCode); 2026-09-20/21
• Wallstreetcn (Lin Ke, Zheng Hao), "Tracking the Zhipu ZCode Secret-Upload Scandal: Who Audits an Agent's Data Behavior?"; 2026-09-19
• Tokenstead, "ZCode uploads your entire git history, and only Z.ai holds the key," 2026-09-18
• South China Morning Post, "Chinese AI firm Z.ai faces reputation hit after users spot unauthorised uploads," 2026-09-20
• Odaily / BlockBeats (republished via KuCoin), coverage of the Taiyuan Chengming Technology legal letter; 2026-09-20
• ET Net (republished via Longbridge), coverage of Zhipu's share price and remediation statement; 2026-09-21
• tech360.tv, "Z.ai's ZCode Secretly Uploaded User Data, Trust Declines," 2026-09-21
• Longbridge AI incident analysis (citing Huxiu); 2026-09-20