ZCode Packed 42,411 Files Into an Archive Only Zhipu Could Open

On 18 September 2026, a developer who writes under the name ferstar published a teardown of ZCode, the desktop AI coding agent made by Chinese model developer Zhipu AI, after noticing that a hidden folder in his home directory had grown past 700 MB. Inside it he found a 313 MB encrypted archive holding 42,411 files drawn from a 345 MB workspace, 86.6% of it Git history, packaged by the client and staged for upload to Alibaba Cloud object storage. The archive was sealed with a key that only Zhipu's servers could unwrap, and the client offered no switch that stopped it being built. Zhipu apologised the same evening. The full record, with the archive's own confidence grade and harm status, sits in the Orca AI Incident Archive, which logs each documented AI incident against its cited sources.

ZCode is Zhipu's desktop coding agent: it reads a project, runs shell commands and writes code. The company trades in Hong Kong under the ticker 2513.HK and brands its international arm as Z.ai, the name that appears on the ZCode servers ferstar inspected. The Paper, the Shanghai news outlet that interviewed him and several other developers afterwards, reports that his post was titled, roughly, "Pulling back the curtain on ZCode's silent upload of full Git history," and that it spread through Chinese developer groups within hours of publication.

What was inside the hidden folder

Ferstar's own numbers are the spine of the case, and they have been reproduced consistently by The Next Web, InfoQ and China National Radio's financial desk. The archive in his ZCode checkpoints directory was 313 MB. The status file beside it recorded a workspace of about 345 MB and 42,411 files. The .git directory accounted for 86.6% of the payload: 196.1 MB of Git large-file-storage cache, 102.2 MB of Git objects carrying the full commit history, and a thin slice of reflog. Actual source code and documentation came to roughly 13.4%.

The distinction matters because Git history is where material that has been removed from the current tree tends to survive. The Paper's account makes the point directly: an archive of this kind can carry a project's edit history from its first commit, deleted content, uncommitted drafts and older configuration files, including credentials that were stripped from the code long ago but remain in earlier commits and in the large-file cache.

Ferstar's own 313 MB archive never left his machine. Its status log showed 564 failed upload attempts, and it had stalled in a pending state, over the size limit. To test whether the pipeline worked at all, he tried a small public repository of 538 files; that snapshot compressed and encrypted to roughly 15 KB and was accepted by the server. That transfer is the one in the record confirmed to have completed end to end, and it is what turns the finding from a code-reading exercise into an exfiltration with a demonstrated receiving end.

Capture was not tied to any action a user would recognise as "upload my repository." According to ferstar's reconstruction, one trigger fired before each prompt submitted to the model, and another ran as a Repo Wiki update task. Deleting the pending archive did not stop it: a write-up on Tencent Cloud's developer community records that the package was rebuilt within 30 minutes and the failure counter advanced from 564 to 565. The only reliable stop that author found was making the checkpoint directory non-writable so the capture failed at the disk write, at the cost of losing checkpoint rollback and the timeline interface.

A key that only the vendor could use

The encryption was textbook envelope encryption, and that is the part users could not work around. InfoQ's reconstruction, drawn from ferstar's reverse engineering, describes the client fetching a snapshot ID, an RSA public key and Alibaba Cloud OSS upload credentials from zcode.z.ai, packaging and encrypting the workspace locally, then sending the ciphertext directly to OSS. Content was encrypted with AES-256-CTR; the symmetric key was wrapped with RSA-OAEP-SHA256 under the server's public key, whose private half stayed in Zhipu's cloud.

The routing is as significant as the cryptography. Because the client uploaded straight to Alibaba Cloud rather than through Zhipu's own application servers, the traffic did not pass a Zhipu service that could log or filter it, so no Zhipu service sat in the path to log or filter what left. And because the private key was never on the device, ferstar could not open his own archive: The Next Web reports that he tried every private key on his machine and failed. He described the arrangement in his post as a key only the server can use, which has one purpose.

Two settings in the client looked like they should have stopped this, and neither did. The "optimise experience" toggle governed whether data could be used for model training; the "repository snapshot indexing" toggle governed whether the server built an index over snapshots that had already arrived. Both act downstream of capture. Ferstar found the capture running unconditionally, and The Next Web reports that his reading of the privacy policy found it described collecting conversation text and files but said nothing about automatic workspace snapshots carrying full Git history.

The explanation Zhipu gave, and the four days after it

Zhipu responded the same day, through ZCode's official user group rather than a press release. As reported by Global Times and reprinted by Security Inside, the company attributed the behaviour to a feature called codebase indexing, which supports local indexing, session checkpoint restore, version rollback and Repo Wiki generation, and said the Repo Wiki step was what triggered repository uploads to the cloud. The feature had been on by default since launch. Zhipu said uploaded data was used only to generate the Repo Wiki page and was destroyed immediately afterwards, that it was not stored and not used for training, and apologised to affected users. It promised to open-source the ZCode codebase, invite third-party review and publish the results, and offered every ZCode user one extra weekly quota reset as compensation.

The fix arrived the next day. The Paper reports that ZCode 3.14.0 shipped on 19 September with a changelog entry reading "fix the abnormal upload issue of the repository wiki," and that ferstar confirmed the same day that the upload chain and its endpoint were gone. On 20 September, Zhipu's MaaS platform announced an upcoming zero-retention option under which inputs and outputs would not be statically stored; The Paper notes it is opt-in by application, excludes Batch API and File API, and still permits retention of 30 days or more where law or abuse investigation requires it. On 21 September the client source went public on GitHub under the Apache 2.0 licence, covering the desktop app, web client, backend, agent CLI and agent runtime.

Two audits were commissioned and their conclusions published as summaries. The China Academy of Information and Communications Technology found the zcode-prod Alibaba Cloud OSS bucket in what Zhipu calls a zero-data state. The security firm NSFOCUS reported that every data object and the bucket itself had been deleted, and that it found no remaining path in ZCode 3.14.0 that could trigger a local repository snapshot or send files out. The full assessment report has not appeared, and The Next Web reports Zhipu has given no date for it.

The customer that alleged more, then withdrew it

The most serious claim of actual loss did not come from ferstar. On 19 September, according to China National Radio, Taiyuan Chengming Technology sent Zhipu a legal letter numbered Chengming [2026] Legal Letter No. 1, reproduced in detail by ChainCatcher. The company said six of its coding workspaces had been uploaded without consent — 34,500 files and roughly 425 MB in plaintext — and listed complete source code, system architecture, version history, database passwords, cloud credentials and employee personal information. It said a seventh workspace of 1,947 files and about 144 MB had been packaged and encrypted but failed 32 upload retries. It also noted that its client had updated to version 3.12.3 on 16 September, yet uploads were still detected at 00:28 on 18 September, the morning Zhipu apologised.

The letter asked a question the audits do not answer: whether data left the country. Chengming said ZCode's network requests pointed at a Singapore entity while its service agreement was signed with Beijing Zhipu Huazhang, and it asked Zhipu to identify which party was responsible and whether any transfer or storage had occurred outside mainland China. The letter set out twelve demands, including deleting all uploaded data and its derivatives, caches and backups with a written certificate, explaining where the data went and whether it was shared with third parties or used for training, describing how the private key is held and producing access logs, defining the exact scope of the "destroyed" claim, and committing in writing never to upload again. It gave Zhipu until 10 October to answer in writing and reserved the right to claim damages and complain to regulators. Caixin Global reports that Zhipu called the allegations untrue.

Two days later, Chengming withdrew them. China National Radio's financial desk reports that on 21 September the company issued a retraction saying its earlier statements rested on erroneous evidence, imprecise description and overstated wording, that they had damaged Zhipu's reputation, and that it would stop speaking to media. Reuters also reported the withdrawal, according to The Next Web. The archive entry for this incident is dated 18 September, the day of the discovery; the letter, its 10 October deadline and the retraction all came after that date. On the public record as of late October, no named company stands behind a claim that its secrets were exposed.

An open-source release with its history erased

Open-sourcing the client was the remedy Zhipu leaned on hardest, and it came with a hole. The Paper reports that the published repository contains two commits: an empty initial commit and a single commit adding about 6,973 files and 1.03 million lines, with pull requests locked and issues closed. Whatever the upload pipeline looked like when it shipped, and whichever releases contained it, is not in the history anyone can now read.

Ferstar's own follow-up makes the limit explicit. He confirmed the upload pipeline had gone and that the remaining checkpoint mechanism does local Git work only, then pointed out what an audit of the bucket could and could not show: clearing and deleting the bucket is the right stop-loss action, but a third-party check performed after 20 September can establish only that the bucket was empty at that point. It cannot reconstruct what passed through before 18 September, whether anything was decrypted, copied or backed up, or how long the pipeline had been running. A deletion claim still rests substantially on the word of the party that deleted.

InfoQ's analysis lists the questions that remain open in the same terms: how many repository snapshots were successfully uploaded and by how many users, how long objects were retained, which server-side systems or staff could decrypt them, whether a complete access log exists, and whether the deletion covered backups and other copies. It also notes what ZCode still is after the fix. The project's own NOTICE warns that the shared agent runtime does not provide an operating-system-level sandbox by default, and the client retains shell, terminal, Git, MCP, plugin and embedded-browser surfaces that can read files, start processes and reach the network within the user's account permissions.

What is established, and what no source answers

The mechanism is not in dispute. Zhipu's own statements concede that repository data was uploaded, that the feature was default-on, and that the data went to a cloud bucket the company controlled. Ferstar's measurements, the vendor's apology, two commissioned audits and the open-source release all describe the same chain. Nothing in the record disputes that workspaces left machines without a workable opt-out. The harm the record logs is realised rather than hypothetical: the transfers happened, and the people whose code was inside them could neither prevent nor inspect them.

What is in dispute, or simply unknown, is scale and consequence. No source states how many users ran the affected defaults, how long the pipeline operated before 18 September, or whether any uploaded object was ever decrypted. Zhipu's assurance that data was destroyed after wiki generation and never used for training is the company's own statement; the CAICT and NSFOCUS findings describe the state of the bucket after the fix, not what passed through it. The archive grades the record A on documentation, and the documentation is strong on mechanism and thin on scope.

What changed, and what did not

The commercial cost was immediate. China National Radio reports that Zhipu's Hong Kong-listed shares fell 1.79% on 21 September, 6.55% on 22 September and 12.4% on 23 September, a cumulative decline of more than 16% over three trading sessions, and that Zhipu did not address how many users were affected or whether historical data had been decrypted or backed up.

What a ZCode user actually received in the four days after the discovery:

• 18 September: a public apology naming codebase indexing as the cause, a promise to open-source the client and commission third-party review, and one extra weekly quota reset per user.

• 19 September: ZCode 3.14.0, with Repo Wiki removed and the local snapshot generation and upload path cut. Ferstar confirmed the upload chain was gone the following day.

• 20 September: an announced zero-retention option for Zhipu's MaaS platform, opt-in, excluding Batch API and File API, and still subject to legal retention of 30 days or more.

• 21 September: ZCode published under Apache 2.0 without its pre-incident commit history; CAICT and NSFOCUS summaries reporting the storage bucket empty and the egress path absent.

None of that reaches backward. The specific questions Chengming raised — where the data went, who could decrypt it, whether it left the country, and what "destroyed" covered — were put in writing with a 10 October deadline, and were then withdrawn along with the company that asked them. Zhipu has promised a full third-party assessment report without a date. Until one appears, the only public account of what the pipeline did with the data it received is the account of the company that built it, and the only independently measurable artefact is a 313 MB file that failed 564 times to leave one developer's laptop.