ZCode uploaded repositories while its related settings controlled other behavior

ferstar says he found the archive while clearing disk space: a 313,070,842 byte encrypted file in ~/.zcode/v2/checkpoints, beside a state file recording a 345,549,173 byte workspace and 564 failed upload attempts. The packing manifest is written locally in plaintext even though the archive is not, and it breaks the snapshot down to 42,411 files, of which .git accounts for 86.6 percent: LFS cache at 56.8 percent, the object store at 29.6 percent, reflogs at 0.2 percent. Content is encrypted with AES-256-CTR under a key wrapped by an RSA public key the server supplies at upload time, so the private key never reaches the machine and the file cannot be opened by the user or by the client. He reports that the two settings that look like they govern this, labelled Optimize Experience and Repo Snapshot Indexing, control training authorization and server-side indexing instead, that the upload process starts unconditionally at launch and needs only a valid login token, and that one active session logged up to 62 capture events, with a capture triggered before every prompt. His reading of the design: it "looks less like backup and far more like collection."

Zhipu apologised on September 18 in a statement issued through its official user group and reported by IT Home, saying it had completed a self-inspection and that the problem is fixed. Its description of the mechanism differs. Zhipu attributes the uploads to the repository indexing feature, says the Repo Wiki function can trigger a repository data upload, says uploaded data is destroyed once the wiki page has been generated in the cloud, and says the feature was on by default when it launched. The company also said it will open source the ZCode codebase and invite third-party reviewers, and gave every user an extra weekly quota reset. The GitHub issue demanding answers was still open with no reply from the company when this edition was written.

Why it matters: The two accounts disagree about the scope and trigger of the uploads. Publishing the client code would let outside reviewers test both accounts. Until then, the checkable evidence comes from the client's state files and the contents of its bundle. The app's settings did not give the user a reliable way to tell whether repository data would leave the machine.