This story arrived in an evening cybersecurity digest: in the coding agent ZCode from Chinese lab Z.ai, researchers discovered a background process that silently packages the entire working directory โ along with full git history โ encrypts it, and uploads it to Alibaba cloud storage. Hacker News voted 322 points, 107 comments, but almost all discussion revolves around "yet another Chinese app scandal."
What hooked me was a detail lost in the retelling: the archive on the researcher's disk was encrypted with a key he did not have. The public key is sent by the server, the private key lives in the cloud โ and neither the user nor the ZCode client itself can decrypt the three-hundred-megabyte snapshot of someone else's... that is, their own intellectual property. This is not "broken privacy," this is an architectural decision with a name. And around it โ an entire economy of free tokens, adjacent scandals with Grok Build and Nx, the legal branch of Copilot, and GitGuardian figures about how many secret ghosts live in the git history of every project.
It all started with a routine operation. A developer publishing under the pseudonym ferstar was freeing up space on a MacBook Air with a 256-gigabyte SSD โ a disk, as he jokes, "bought at the price of gold" โ and noticed that the ~/.zcode directory had swollen to 700+ megabytes. Inside, in the v2/checkpoints subdirectory, lay an encrypted file of 313 megabytes and beside it โ a state file with disconcerting contents: workspacePath pointed to an active commercial project, snapshot type โ "baseline," and the failed upload attempt counter stopped at 564.
The packaging manifest, which ZCode thoughtfully saves in the open, gave a complete inventory of the haul: a 345.5 MB workspace turned into a 313-megabyte encrypted archive of 42,411 files. But the juiciest part is not the number, but the content breakdown. The entire payload โ 86.6% โ is the .git directory: Git LFS cache at 196.1 MB (56.8%), .git/objects object storage at 102.2 MB (29.6%), and reflogs for another half megabyte. The actual source code and documentation accounted for a measly 13.4%.
This distinction is central to the entire story, and it must be chewed over. The working tree of a project is what you see in the editor. The git repository is the genealogy of the project from day one: API keys deleted in later commits, old configs, names of unpublished branches (meaning, essentially, unannounced product plans), internal GitLab hostnames and repository paths in .git/config. None of this exists in the current code anymore โ but all of it lives forever in the git object database until a history rewrite purges it. The ZCode snapshot flew to the cloud not as "context for the model," but as a snapshot of the entire engineering life of the repository.
The final touch: ferstar separately found the repo_snapshot_extra_manifest, which hashes and packages global client settings โ ZCode collected not only projects but also user configs across all workspaces.
The fate of the most famous exhibit is ironic: the 10 GB commercial repository (minus dependencies โ 345 MB of "almost pure intellectual core," in the author's phrasing) never made it โ 564 attempts hit the size limit and got stuck in pending. But a small public repository of 538 files the server accepted normally. So the triggering is not selective: other users independently reproduced the finding โ on Windows the same directories and state files, small workspaces with "accepted" status and not a single rejection record; in the zai-org/feedback bug report โ a manifest of 2000+ git paths and an encrypted archive approaching a gigabyte.
Next, ferstar cracked open app.asar โ the packaged JavaScript container of the Electron application โ and reconstructed the entire pipeline. The scheme works like this: the client hits the endpoint /api/v1/snapshot/upload-credential on zcode.z.ai, the server returns a snapshot identifier, form upload signatures, size limits, and an RSA public key specifically for this encryption round. Locally the workspace is packed into tar.gz, encrypted with AES-256-CTR, the symmetric key is wrapped with RSA-OAEP-SHA256 โ and the archive POST-forms directly to Aliyun OSS, bypassing ZCode's own servers; Alibaba storage after acceptance callbacks to the Zhipu backend.
Sounds like exemplary security, right? AES-256, RSA-OAEP, envelope encryption, like in a textbook. Encrypted traffic can't be sniffed in a cafรฉ, nobody in the middle will read anything. A ZCode engineer could probably proudly defend a thesis on this scheme.
But here you need to stop and reread the last paragraph slowly. The user's machine has no private key. ferstar ran decryption against all local private keys โ as expected, nothing opened. The symmetric key is wrapped with the server's public key, and only the owner of the corresponding private can unwrap it โ and that is exclusively the Zhipu backend. The three-hundred-megabyte encrypted blob sits on the developer's disk, and neither he nor his ZCode client can open it. Only the company.
If the feature were an honest user backup or device-to-device sync โ the keys would live with the user, exactly like in git or Time Machine. Envelope encryption with a server-exclusive key serves exactly one function, and ferstar formulated it in a phrase that became the quote of the week: "a key that only the server can use exists for exactly one purpose โ so the server can read your code whenever it wants". Hard not to recall the old lesson of protocols: encryption is not "made it secure," it's "defined WHO can read." ZCode defined. Just not in the user's favor.
The irony is that the source of this story is not a hostile insider, but a long-time paid subscriber to GLM Coding Max, who on the evening of September 17 enthusiastically promoted ZCode to colleagues in chat. Less than half a day later, reality slapped him in the face โ he caught the silent packaging of his own commercial project. By his own admission, he is not a "reverse-engineering guru," just an engineer with a curious eye โ and with an honest joke at the end: "with modern AI, anyone with a coding agent is already a reverse engineer โ feed it this post and the sources, and it will dissect the entire architecture."
The next act is the most cynical. The natural reaction of any adult user: open settings and turn it off. Ferstar cross-checked the UI toggles with the client code, and the result deserves a textbook entry under "privacy theater."
The "Optimize Experience" toggle (optimizeAgentExperienceEnabled) looks like disabling telemetry and data collection. In reality it controls only authorization of data for model training. Packaging and uploading snapshots continue. The "Repo Snapshot Indexing" toggle (repoSnapshotIndexingEnabled) looks like a snapshot kill switch. In reality it controls only indexing of already-uploaded snapshots on the server. Packaging and uploading continue. In the host build code the capture/upload sidecar is instantiated unconditionally at startup โ no if checks on user settings, the only condition: tokenProvider can issue a valid JWT. Logged in โ pipeline works. Period.
The activation moment โ two triggers: captureBeforePrompt before every prompt and repo-wiki-update upon task completion. In one active session the log recorded up to 62 capture events. Speaking of prompts: tokenstead, cross-referencing with the OrcaPromptVault archive (131 KB of ZCode system prompt and 31 tools), added a killer detail โ the agent's tool list includes not a single snapshot, upload, or telemetry instrument. The pipeline lives outside the tools circuit, at the host level. The agent itself doesn't see it and can't report on it, and in 131 KB of instructions there's not a word about Aliyun, OSS, or upload. The sidecar is literally wrapped around the agent like shackles around hands โ the hands don't feel they're bound.
And the cherry on top: when ferstar deleted the pending archive, half an hour later a new one grew in its place โ fresh 313 MB, the attempt counter crawled from 564 to 565. Manual cleaning against a client that repackages data is classic whack-a-mole: hit one mole โ the next one pops up. The data, however, speaks for itself: ZCode's privacy policy contains not a word about packaging and uploading entire workspaces and git histories.
The policy talks about collecting "text, files, and code sent in conversations" โ the standard inference-context formula. The policy page, archived by ferstar on September 18, is dated June 15, 2026 and has not been updated. The closest-to-truth paragraph is a template phrase that "the optimization program is disabled by default, and input will not be used for training without consent." From a corporate lawyer's point of view โ almost true. From a user's point of view โ a constitution under which reality simply was not inscribed.
On September 18 at 17:44, when the story had already spread through tech media, Z.ai issued an official statement. Translating from corporate: the culprit is the "codebase indexing" feature, which supposedly is needed for local indexes, checkpoint restoration, and Repo Wiki generation; Wiki page generation in the cloud "may" trigger repository data upload; after generation uploaded data is destroyed immediately and not stored; the feature was enabled by default in the early launch period, some users were affected, "issue resolved." As compensation โ a promise to open-source ZCode, invite external assessors, and give all users one additional weekly quota reset. Today.
The timing smells of context: on apology day Zhipu synchronously released a new GLM-5.3-FlashX model at 200 tokens per second. One of the developers then sarcastically remarked in a blog: "the entire internet is asking where its codebase went, and Zhipu is busy releasing a new model." Timing is the deciding argument.
Ferstar dissected the statement line by line, and three questions remained open. First: how to prove "destroyed immediately" from outside? Are already-uploaded cloud snapshots physically erased, and who has decryption rights for those that managed to leave? Second: the stated purpose of "checkpoint restoration" contradicts "destroyed immediately" โ if snapshots are needed for restore, what exactly was stored in the cloud and for how long? Third, the most ironic: will the promised open-source include precisely that upload sidecar that was caught โ or only "a fresh sanitized commit"? Ferstar promised to write a follow-up directly against the source code if the repo actually comes out.
The technical picture of the post-fix from reverse engineering version 3.14.0: the upload pipeline code is physically cut out, the sidecar is dismantled, the cloud endpoint upload-credential now responds with 404. This is more honest than words: the "fixed" checkmark is confirmed by the binary. But the three questions above are not closed by this โ there is no externally verifiable "deleted" from an outside audit. Note the asymmetry: to prove guilt, one snapshot on disk is enough; to prove innocence after "we deleted everything," access to their cloud is needed. This is how the cryptography of trust works, and this is how it will always work against opaque promises.
The promise made on the 18th lasted exactly three days. On September 21, Zhipu posted ZCode on GitHub โ github.com/zai-org/ZCode โ and not as a stub, but as a full-fledged monorepo: Electron desktop, browser workbench, terminal agent, Agent CLI with runtime, client, backend services, and shared UI in one package (Node 24.14.0, pnpm, mise.toml). The third "impossible question" from the previous section changed status: from an unverifiable promise it turned into a git clone task. What exactly the snapshot module packages and what the switches really connect to โ now anyone can see, and Ferstar promised his follow-up already against the sources.
Along with the code, the company published what was missing for the first "impossible question": audit results. The China Academy of Information and Communications Technology (CAICT) confirmed that the zcode-prod bucket on Aliyun OSS is in a "zero data" state, and NPS Security โ that all objects along with the bucket itself were deleted from the bucket, and in client 3.14.0 not a single functional path was found that launches snapshot generation or file transmission. Repo Wiki โ the feature on which the entire incident was validated โ is cut out entirely, the snapshot-to-cloud chain is broken. In parallel, on the MaaS platform they announced no-retention: upon user request, inputs and outputs of standard calls are not stored statically and live exactly one request; honest caveats โ Batch API, File API, and legal/anti-abuse storage remain.
If you read this as answers to three questions, the score is 2.5 out of 3 โ with an honest caveat. The audit is external, but the auditors are Chinese and state-affiliated, and it verifies the current state, not history: what managed to leave through the window while snapshots were flying โ there's nobody and nothing to check. The asymmetry from the previous section hasn't gone anywhere: access to someone else's cloud for independent verification is still needed โ it's just that now two inspectors chosen by the defendant himself received it. But the reputational mechanics worked both ways: SCMP records a crisis of trust (a major robotics company internally banned Z.ai tools), and developer Tuxi formulates it harshly: "this is essentially theft, the malicious intent is frightening." But the blow landed on reputation, not models โ GLM can still be run through Codex. Ironic outcome: the way to prove innocence retroactively still doesn't exist, but the way to prove good faith forward has appeared โ and this is more than any participant from the next section offers. Trust remains a property of architecture โ it's just that the architecture now has a public address where it can be checked.
The first reaction to the ZCode story โ "well, who does that?!". The unpleasant answer: many do this, and not only in China โ the question is only whether openly or covertly. Over 2025โ2026, a whole family of such cases has accumulated, and ZCode is not an anomaly but a point on a curve.
Let's start with Grok Build โ xAI's CLI agent. In July 2026, independent researcher @cereblab conducted wire-level analysis (mitmproxy on his own machine, canary credentials, reproducible repository) and caught full git repository uploads to a Google Cloud Storage bucket with the telling name grok-code-session-traces. Key figures: on a test 12-GB repository the model context received 192 KB, and the upload channel sent 5.10 GiB โ a ratio of ~27,800 to one.
The prompt "Answer exactly: OK. Don't read or open any files" the agent honestly executed (the model answered OK), but the git bundle with all contents still flew to storage; the canary file src/_probe/never_read_canary.txt was recovered from the intercepted bundle verbatim. Canaries from .env (API_KEY, DB_PASSWORD) passed through two independent channels โ through model context and through session archive. And yes: the "Improve the model" toggle did not affect uploads; after opt-out the endpoint /v1/settings continued to return trace_upload_enabled: true.
The difference from ZCode is subtle but important, and tokenstead directly spells it out: the Grok case is open carelessness. Uploads were written to the tool's own unified.json, events are tied to context sync phases, logs were kept on the user's disk. After publicity, xAI server-side disabled uploads (disable_codebase_upload: true flag), Musk publicly promised to delete what was uploaded (no independent confirmation of deletion), on July 14 open-sourced Grok Build. The precedent of open-sourcing is reactive: the researcher's Gist and press (IBTimes UK, July 13) came out before the announcement. Chronology doesn't prove intent, but shows that external verification preceded the offer of audit, rather than flowing from it. Like it or not โ this is already the standard price list of modern indulgence.
A parallel story โ Nx, an innocent npm build package used as a weapon. On August 26, 2025, attackers through an injected line in a GitHub Actions workflow (added five days earlier) stole a publish token and posted eight malicious releases. The post-install script of these releases searched the victim's machine for installed AI CLI โ Claude Code, Gemini CLI, Amazon Q โ and ran them with permission-disabling flags (--dangerously-skip-permissions, --yolo, --trust-all-tools) with a prompt ordering recursive search for crypto wallets, SSH keys, .env and credential stores. Result: 2,349 unique secrets leaked into public GitHub repositories s1ngularity-repository-*.
The common denominator between Nx and ZCode is one: AI agent is the new universal reconnaissance tool โ a legitimate instrument with rights to read the file system, trusted by default. The difference in positioning: Nx is malware that appropriated someone else's trusted agent; ZCode is a legitimate agent that was silent about itself.
Next โ no longer exotic, but background. The cluster of npm packages found by codelake in September 2026 (codebuff-cli, orbitron-tui all 84 versions, orbitron-cli, agent-free, prime-coding-agent from one publisher imjustbetterxd) retransmitted authenticated user traffic โ LLM API key, code, prompts โ to attacker backends on Replit/Vercel, simultaneously disabling TLS certificate verification. Claude Code itself has a vector through OpenTelemetry: a malicious .claude/settings.json in the repository reconfigures OTEL export to a foreign HTTPS endpoint, and already five seconds after session start, before first interaction, the attacker receives plaintext email, account UUID, MCP server inventory, prompts and tool inputs; with the otelHeadersHelper option โ shell command execution with output exfiltration in HTTP headers every 5โ15 seconds.
Anthropic responded that the boundary is workspace trust; researchers countered that trust is inherited recursively (trusted ~/projects approves all future repositories inside it) and the dialog doesn't enumerate specific risks. Even the open open-source OpenCode project stepped on similar rakes: the default free Grok tier, chat headers generated by an external model even when the entire chat went through local llama.cpp โ HN commenters caught this precisely by the absence of external calls in local logs.
Now let's put the scandal on the financial table โ and it will become clear why it's not a "glitch" but a systemic growth point.
ZCode is not a hobby project, but a key element of a public company's strategy. Zhipu (brand Z.ai), grown from a Tsinghua University lab, went public on the Hong Kong Stock Exchange January 7โ8, 2026, raising $558โ715 million โ the world's first major IPO of a purely generative AI lab, post-money valuation $31.3 billion. H1 2026 half-year report: revenue RMB 954 million ($142 million), +~400% YoY; API platform share โ 86.5%; ARR by end of August $1.6 billion; the coding plan โ the company's primary revenue driver ("Programming is now the company's primary revenue driver"). Meanwhile, net loss โ RMB 2.07 billion for the half-year, R&D โ $317 million, and API gross margin only just climbed out of the red at +24.6% (was -0.4% a year earlier).
Now add the promo: in August 2026 Z.ai announced Build Week โ 50,000 new users ร 100 million GLM-5.3 tokens = 5 trillion free tokens, against the backdrop of "ZCode already has 1 million users."
In late 2025, Zhipu's coding plan made headlines with its price point โ $3 per month for an almost-frontier model (GLM-5.1 led in SWE-bench Pro with 58.4 vs. 57.3 for Claude Opus 4.6, according to Z.ai's table; independent tests generally confirmed). The inference wave choked the infrastructure โ applications were paused, then came price reset: for foreign users Lite rose to $10, then to $18, Pro to $72, Max to $160; inside China โ $7/$21/$68 unchanged. The phenomenon got a name "passport tax" โ passport tax: the same product at different prices depending on what you pay with.
What does this combination give? A subsidy of 5 trillion tokens with API gross margin at 24.6% and R&D at $317 million is classic customer acquisition cost, and the HKEX investor pays for it. The open question remains what exactly the company intended to close the gap with โ and here it's important to separate facts from hypotheses.
Fact one: the official version says uploaded data "was destroyed immediately" โ and this is the only explanation of goals we have; verifying it from outside is impossible, so the question "why does the server need decryptable snapshots of others' git histories" remains without a clear answer. Fact two: if such archives were ever read, it would be industrial-scale reconnaissance โ which APIs live where, how code is structured in specific industries, how internal services and unannounced features are named. There is no evidence this happened; there is also no architecture that excludes it.
And the third fact โ about the company itself, already from third parties: Anthropic in its September Threat Intelligence report documented how Zhipu ran a CoT-extraction pipeline against Claude Opus 4.8 through 273 fraud accounts โ 770,609 exchanges over ten days in June, and its market neighbors โ Alibaba, Moonshot, DeepSeek, Xiaomi, SenseTime, MiniMax โ built entire industries around bypassing limits, buying user transcripts from proxy services, and silently retransmitting others' prompts to their own models. This is not a verdict on the ZCode case โ but very telling context: the same lab, the same season, the same genre of behavior.
By the way, about a legal option almost nobody knows about: The Stack v2 from BigCode/Hugging Face. A dataset of permissively-licensed code with a public opt-out mechanism โ any developer can find their repositories through "Am I in the Stack" and request their exclusion from future versions. This is expensive (manual license verification, removal by request), but ethical and transparent. ZCode didn't go this route not because it didn't know โ but because going that way would take years. Agreement with the user is cheaper than signatures. Always.
An important caveat before conclusions: the legal framework around AI coding is still blurry, and the ZCode case legally falls outside it. Recently, the Ninth Circuit U.S. Court in Doe v GitHub (September 2026) dismissed DMCA claims by programmers against GitHub Copilot: Judge Miller on behalf of a unanimous panel wrote that "removal" of CMI requires an existing work from which it's removed โ Copilot predicts probable completion from statistical patterns, not issuing a copy of someone else's code without attribution. Two breach-of-contract claims survived, but the main signal: statutes written before generative AI map poorly onto its reality.
But here's the focus: the ZCode case is not about training and not about copyright. It's about data leaving the user's machine without consent, without mention in the policy, and with a key unavailable to the user. This is the territory not of DMCA but of privacy legislation: GDPR in the EU, PIPL in China, state privacy acts in the U.S., breach-of-contract where a promise was made. Given the scale (minimum one million users by Z.ai's self-report, each with years-accumulated git history), a class action even in the modest formulation "we promised in policy not what we did" could cost more than the $1.5 billion Anthropic paid book authors (largest copyright settlement in history, September 2025) โ with the difference that here it's not pirated books but live keys and unfinished products of other people's companies.
GitGuardian figures frame the scale: 29 million leaked secrets on public GitHub in 2025, commits with co-authored-by Claude Code leak secrets 2 times more often than baseline, and median time to revoke a leaked key โ 13 days (Truffle Security). ZCode snapshots lay not 13 days but unknown how long; "destroyed immediately" is a promise that cannot be verified, and only one thing can be verified: on the researcher's disk remained an encrypted archive that he cannot open, but which the server could open.
So what to do? ZCode in version 3.14.0 cut the pipeline, Grok Build open-sourced after scandal, Cursor is under legal investigation on "explicit consent" for training, OpenCode quickly closed the default Grok channel. But each next turn tightens the spiral, and the position "I only use big vendors" no longer works: Claude Code has its own OTEL vector from Bloom Security investigation, xAI has a history with non-working "Improve the model," and Chinese jurisdictions have behind them the "National Intelligence Law," where Article 7 leaves no right to refuse.
Hence three practical conclusions, each with instrumental verifiability, not "believe-don't believe." First: what exactly your harness sends when you're logged in and doing nothing โ verifiable with mitmproxy in one evening; if traffic goes to unexpected hosts โ that's already a finding. Second: who can decrypt what is stored โ if it's the server's key, not yours, that's an architectural verdict: "encryption against third parties but not against the vendor" is not user protection, it's a vendor data delivery circuit. Third: readable policy โ reality โ ferstar archived the policy page on September 18 and compared with actual code; the discrepancy was complete.
Figure for dessert: 91% of surveyed developers (Safeguard AI Trust Report, 1412 respondents, April-May 2026) use an AI assistant at least once a week, but only 34% trust the security of its code, and 47% of security leaders believe their company has already merged at least one non-existent "hallucinated" package. This is not a trust problem. This is a market without a trust meter โ and each new ZCode simply adds metrics to it.
Actually, the entire ZCode story fits into one engineering moral: trust is not a character trait of a company and not a clause in policy, but a verifiable property of architecture. If the keys are with you โ trust exists. If the keys are with the server and the switches don't work โ there is no trust, whatever beautiful words stand in the README. ZCode inadvertently gave the industry the most visual teaching example in a couple of years: three hundred-plus megabytes of someone else's labor, packaged in an encrypted blob that the owner himself cannot open. The engineers who designed this knew exactly what they were doing. That's the frightening part โ not stupidity, but precision.