The Pulse
ZCode Reportedly Uploads Full Git Histories Without Notice
A reverse-engineering report says ZCode packages entire workspaces, including Git histories and LFS caches, and uploads encrypted snapshots to Aliyun OSS. A public ZCode feedback issue describes similar behavior on macOS and Linux, includin
AI.info Team ·
A reverse-engineering report published on September 18 says ZCode, Zhipu’s desktop coding agent, packages and uploads far more than the files a developer actively sends to an AI session. The investigation describes encrypted snapshots containing complete Git metadata, Git LFS caches, reflogs and selected global ZCode configuration files, sent directly to Aliyun Object Storage while the user remains signed in.
The report comes from ferstar’s technical investigation, which traces the behavior through local files, application logs and the client’s packaged JavaScript. It documents one detailed macOS test rather than establishing how many users or workspaces were affected. A separate public issue in ZCode’s official feedback repository, opened the same day, describes similar evidence from macOS and Linux systems.
A 313MB Snapshot Waiting to Upload
The investigation began when the author found that ZCode’s local data directory had grown beyond 700MB. Inside the application’s v2/checkpoints directory was a 313,070,842-byte encrypted archive and a state file identifying a 345,549,173-byte workspace snapshot. The workspace belonged to what the author describes as a commercial project, and the archive was marked as a full “baseline” snapshot.
The local state file recorded 564 failed upload attempts. The report says ZCode had scanned the workspace, excluded directories such as node_modules, compressed the remaining data and left the archive in a pending directory for another attempt. The author says the original repository was about 10GB, while the material selected for the snapshot was 345MB and consisted largely of project assets.
The public feedback issue describes a similar mechanism. Its author says that, on ZCode Desktop version 3.12.3 for macOS and version 3.10.0 on a Linux remote system, local state files contained lastAcceptedManifestHash values alongside manifests listing large numbers of .git paths. The issue remains open and has no assignee listed.
The Upload Path Runs Through Aliyun OSS
According to the primary investigation, ZCode first requests upload credentials from zcode.z.ai through /api/v1/snapshot/upload-credential. The response supplies a snapshot identifier, an RSA public key, size limits, form credentials and a callback. ZCode then creates a tar.gz archive locally, encrypts it with AES-256-CTR and uploads the resulting file directly to Aliyun OSS rather than sending the archive through the main ZCode application server.
The report says the OSS service calls back to Zhipu’s backend after accepting the object. The author also describes persistent connections from the running client to ZCode endpoints and Aliyun storage nodes during testing. Those findings show a cloud upload pipeline, but they do not by themselves establish how long data is retained, which personnel can access it or whether every accepted snapshot is later indexed.
The encryption design creates a separate concern. The client generates an ephemeral symmetric key for the archive and wraps it with an RSA public key delivered by the server. The corresponding private key was not found on the test machine. The report therefore concludes that the local client and user cannot decrypt the stored archive without the cloud-held key.
Git Metadata Makes Up Most of the Tested Archive
The locally saved manifest listed 42,411 files. In the breakdown published by the investigator, .git/lfs accounted for 196.1MB, or 56.8% of the snapshot; .git/objects accounted for 102.2MB, or 29.6%; and .git/logs added 0.6MB. Source code and documentation made up approximately 46.2MB, or 13.4%.
On those figures, Git data represented 86.6% of the payload. That includes the object store containing historical commits, trees and blobs, as well as LFS files and reflog records. The report warns that such material can preserve deleted credentials, old configuration files, unpushed branch names, internal repository paths and other information that is absent from the current working tree.
The investigator also found a separate manifest named repo_snapshot_extra_manifest. It hashes global ZCode configuration files such as settings.behavior.json and associates them with snapshots across workspaces. The public issue similarly alleges that user-level MCP, hooks, skills and agent configuration data may be included, although those broader claims come from the issue author’s local inspection rather than from a published ZCode specification.
The Visible Settings Do Not Stop the Reported Capture
The report compares two settings with the behavior found in the client. optimizeAgentExperienceEnabled controls whether collected data may be used for model training, according to the investigation, while repoSnapshotIndexingEnabled controls server-side indexing. Neither setting stopped local packaging and upload in the tested build.
By reading the application’s host assembly code, the author says the capture and upload component is created unconditionally at startup. The reported requirement for the pipeline is a valid login token. Capture events occur before prompts and when tasks finish with a repo-wiki-update tag; one session log contained as many as 62 capture events.
The public issue reports the same apparent mismatch: repoSnapshotIndexingEnabled was set to false, yet the machine still produced an accepted snapshot marker. Its author asks ZCode to make full repository capture opt-in, disclose whether Git metadata and global configuration are included, provide a one-click shutdown and explain how users can delete previously uploaded data.
No Public Company Explanation Has Been Found
ZCode’s public feedback documentation directs users to GitHub issues, Discord and in-app support, while the company’s release page lists version 3.12.3 as released on September 17. Neither the public issue nor the release notes reviewed for this report contains a response from ZCode explaining the snapshot behavior or its retention policy.
The primary investigation says ZCode’s privacy policy refers to collecting “text, files, and code submitted during conversations,” but does not explicitly describe silent packaging of complete workspaces or Git histories. That distinction is central to the dispute: sending files a user deliberately attaches is different from creating repeated background snapshots of a repository’s historical state.
The report’s immediate workaround is operating-system-level rather than an in-app control. It recommends deleting the local checkpoints directory, recreating it and marking it immutable with macOS’s chflags uchg or Linux’s chattr +i. That blocks the local write step, but it also disables ZCode’s checkpoint rollback and timeline features. The public evidence currently establishes a documented test case and multiple user reports—not the total number of affected accounts, the final disposition of uploaded archives or whether Z.ai has fixed the behavior.