There is a 313 MB file on your disk. A program you installed wrote it, out of your own data, inside your own home directory. And you cannot open it: half the key that seals it never came down to your machine.
The encryption didn't protect you.
It separated you from your own work.
Seven hundred megabytes, unexplained
On September 18, 2026, a developer signing as ferstar — one person with a blog, not a security firm — noticed a directory growing for no reason. His words: "~/.zcode was taking up over 700MB."
ZCode is Z.ai's — Zhipu's — AI coding desktop client, built on GLM-5.3 and shipped as an Electron app: its app.asar comes apart in an afternoon.
Inside sat an encrypted 313 MB file stuck in the pending queue, carrying the name of one of the author's own commercial projects and a counter: "failureCount": 564. The repository was no toy: "The repository totaled 10GB; minus dependencies, the remaining 345MB was almost entirely core intellectual property."
It is the same scene as cli.js.map: one person staring at a file that weighed too much. There the vendor leaked itself; here the vendor takes yours.
ferstar's blog states that its posts are AI-drafted, and on Hacker News someone asked for proof beyond a website written by Claude. It didn't survive the replications.
The shortcut
UpXuu reconstructed the call chain from the decompiled bundle, and the first link says everything: sendPrompt → captureBeforePrompt → … → uploadObject. It fires when you ask: one active session produced up to 62 capture events.
On every prompt, unconditionally, the client requests upload credentials from zcode.z.ai; if the server issues them, it collects. The response carries the Object Key and the RSA public key for that upload. The bundle then goes straight to Alibaba Cloud, never touching Zhipu's business servers.
And the piece nobody writes by accident: "只要命中根 .git 或内部目录，直接返回 include: true，后续的敏感文件名、文件大小、二进制检查全部跳过". The filter drops ordinary files over 1 MiB; if the path falls inside .git, it's included and every later check is skipped.
That is why 86.6%.
Of the 345 MB bundle, source and documentation — all a coding assistant needs to assist you — come to 46.2 MB. That is 13.4%.
It doesn't just take your code. It takes your history: every commit's objects, the LFS cache, the reflogs, the branches you never pushed. Cleaning a history strips the credential from the current tree, not from the old object. And the old object travels.
The client tried to upload those 313 MB and failed 564 times; nobody says why. What did get out is measured: "A separate, tiny public-repo workspace did: 538 files, about 15KB after compression and encryption, status accepted by the server."
Fifteen kilobytes, acknowledged. The pipeline worked.
The two switches
The interface offered two. Neither switched anything off.
"Optimize Experience": "Only controls whether data is authorized for model training. Snapshot capture and upload still run". "Repo Snapshot Indexing": "Only controls whether the server indexes uploaded snapshots. Local packaging and upload continue uninterrupted".
One decides whether they train on it. The other, whether the server files what it received. Which of them said anything about not sending it?
ferstar didn't infer this. He tested it. "Disabling 'Optimize Experience' and 'Repo Snapshot Indexing' still packaged and attempted direct OSS uploads".
That same day, 冯若航 (Vonng) repeated the forensics on his own macOS with "仓库快照索引" off the whole time, and found four snapshots: in one, .git was 93.9% of the workspace. In another's state file sat lastAcceptedManifestHash, the field the client only writes once an upload returns OK. He presents it as an inference.
It isn't that the switch controlled something else. It was off, and it happened anyway.
"Bottom line: as long as you are logged in, this background pipeline is permanently active, and no UI setting can turn it off."
The privacy policy says ZCode collects text, files and code "submitted during conversations". Submitted. An act of the user. As for the rest: "there is not a single mention of silently packaging and uploading entire workspaces and full Git histories."
The one who ends up PAILA isn't the one who ignored the warning. It's the one who read the policy, found both switches, and turned them off.
July, another company, the same script
None of this was new. In July 2026, cereblab intercepted Grok Build CLI's traffic and found xAI's client uploading "a complete v2 git bundle". xAI shut it off with two server-side flags, no advisory, no changelog entry. It later published the full source under Apache 2.0, and the result is on record: "the exfiltration code is still present. It's disabled by the server-side disable_codebase_upload flag, not removed."
In April we wrote about the walled garden and the lesson developers drew was to use open clients. On Hacker News the sentence returns with a different edge — "Never use a Harness if it is not opensourced." — and Grok already showed it isn't enough. The code was open. The flag was on the server.
Which is where it was here. Z.ai said on the 18th it was already fixed; ZCode 3.14.0 shipped on the 19th, a day later. If the fix landed before the new client, it wasn't in the client.
On the affected version, after the apology, UpXuu recorded the pipeline still fully present — captureBeforePrompt, RepoWikiGenerator, the envelope encryption — "理论上可经服务端配置重新启用": in theory, it could be switched back on through server configuration. A third-party team ran that version with canary markers and reproduced nothing. Both are true, and together they say one thing: they didn't dismantle it, they switched it off from outside.
The envelope
The content is sealed with an ephemeral symmetric key, AES-256-CTR, wrapped with RSA-OAEP-SHA256 using a public key the server hands over. Then the line: "the corresponding private key never touches your machine."
"Only Zhipu's backend holds the key to unlock it."
Your file. Your disk. Your commercial project inside it. And on the other side of the envelope, nobody with your surname. A key that only works one way serves one purpose, as ferstar wrote: making sure the server can read your code whenever it wants.
The official response came that same September 18 — at 17:44, per ferstar — in the official user chat group. This desk found no English-language channel of Z.ai's own carrying it. The problem, Z.ai said, came from "codebase indexing", which exists "to support session checkpoint recovery, historical version rollback, and Repo Wiki." It admitted the feature had been on by default, promised to open-source the code, compensated everyone with an extra weekly quota reset, and guaranteed the uploaded data "会立即销毁，不会保存": destroyed immediately.
ferstar put his finger on the seam: "The claimed 'checkpoint restore' contradicts 'destroyed immediately' — what exactly was retained in the cloud?" If it is destroyed instantly, what does the restore restore?
全天候科技 added another: Repo Wiki's official documentation says generating the wiki doesn't read the project's history. Why, then, was 86.6% of the package history?
The only trace of the case in the changelog heads the fourteen "Bug Fixes" in 3.14.0: "Fixed an issue with abnormal uploads in the repository wiki". In the same list: occasional login failures and the width of the model menu. Not one word about .git, snapshots, or the two switches. Leading the list doesn't explain it. It normalizes it.
Attribution
Perpetrator: Z.ai / Zhipu. The company admitted it: on by default. The apology went out through a chat group. The compensation was a quota reset.
Accomplices: two switches that switched nothing, and a privacy policy built around the verb submitted — sent, volunteered — for a product that packaged on its own. And the quiet consensus of the category: an agent reading your entire workspace is normal, and nobody unpacks the .asar to see what it does with it.
Systemic failure: the control plane lives on the server. A client can be "fixed" the same day without shipping a version, and can be switched back on just as fast. On September 8, the NSA, CISA and the FBI had named Z.AI among six Chinese companies distilling U.S. models at industrial scale. No source connects it to this.
What's missing is what isn't there: no victim with demonstrated harm, no stolen credential, no leaked repository. There is demonstrated capability, artifacts on other people's disks — on V2EX some found their snapshots and some didn't — and at least one upload the client recorded as accepted: to anyone logged in with a repository that fit.
Two days after the disclosure, 太原澄明科技 sent Zhipu a legal letter over source code, database passwords and cloud credentials, demanding provable deletion from servers, caches and backups. ferstar had asked how you prove deletion from the outside. Somebody sent the question back with a lawyer.
Z.ai promised to open the code. ferstar already asked the only thing that matters: whether they'll publish the upload pipeline that got caught, or only the latest sanitized commit.
What nobody will be able to read is what is already on the other side. It sits there in a flawless envelope, sealed with a key that works in one direction only. When did we agree that "encrypted" would say who owns the information, rather than who can read it?