ZCode 默认开启的索引功能打包上传整个工作区：约 4.2 万个文件、313MB，用户无知情、无关闭路径ZCode's default-on indexing packed up and uploaded entire workspaces: about 42,000 files and 313 MB, with no user notice and no way to switch it off

ZCode desktop client's 'repository indexing / Repo Wiki' feature was on by default and could not be switched off. While the user was signed in, it packed the entire working directory, encrypted it, and uploaded it to Alibaba Cloud OSS. A single archive ran to about 42,000 files and 313 MB, including the full .git history, branch and large-file cache records, and sensitive environment configuration files.

Users had no way to know: the private key existed only in the cloud, so users could not inspect what a package contained; the privacy policy did not mention it; and after users turned off the privacy and indexing switches in the interface, the background upload attempts continued. The case surfaced because a user examined their own disk. Zhipu attributes it to the repository-indexing feature, saying the data was used to generate Repo Wiki pages in the cloud, destroyed immediately after generation, never stored and never used for model training.

China Academy of Information and Communications Technology testing confirmed the zcode-prod Alibaba Cloud OSS bucket held zero data in the cloud; NSFOCUS review confirmed all objects in the bucket, and the bucket itself, had been deleted.

The September 19 version removed the upload path, and later versions were audited as having cut local snapshot generation and upload; on the evening of September 20 the MaaS platform launched 'no data content retention'; on September 21 the client, backend and Agent CLI were fully open-sourced, with a standing vulnerability-reporting programme; on September 28 a compensation plan gave paying users quota-reset cards. In Zhipu's own words: 'Trust cannot be reset with one click.'

Taiyuan Chengming Technology sent a letter with 12 demands, including stopping the processing, deleting uploaded data, and disclosing processing and access records. It later hid the public letter, said it was in communication with Zhipu, and, per Caixin, acknowledged errors in its evidence. Both sides' actions are recorded here without adjudication.

Three properties deserve separating. On by default meant the exposed population was every user, not volunteers. No way to switch it off removed the exit. And the switches that did exist did not stop the background uploads, which removed trust in the user's own controls. Together, the data boundary was defined unilaterally by the vendor, with users absent from notice, consent and exit alike. The discovery route says the same: it was not the vendor's monitoring that found this, but a user examining their own disk; the client's outbound behaviour was not observable from the user's side.

The case is filed at Access Control: features that move local data out are off by default, consented item by item, and inspectable by the user. Those are floor settings, not bonuses. The later open-sourcing and third-party audit findings (the bucket held zero data; the objects were deleted) replaced 'please trust us' with 'verify it', the right direction, in the wrong order.

Outbound features off by default: any feature that packages and sends local data out is off by default; enabling it takes itemised, informed consent stating the upload scope.

Switches must actually cut: privacy and indexing switches must verifiably cut the background path from the user's side; interface state and background behaviour must match, and a mismatch is treated as an incident.

Uploads inspectable by the user: package contents come with a user-side manifest and a way to unpack; keys do not live only in the cloud, and outbound traffic is observable with user-side tools.