- Sources: primary, discussion, second thread
- Summary: A researcher writing at blog.ferstar.org reports that the ZCode client, from Zhipu, runs a snapshot sidecar instantiated at startup, which packages the repository's full Git history and, in the post's phrasing, encrypts it under a key only Z.ai holds for upload to Aliyun OSS through a zcode.z.ai endpoint, with neither the Optimize Experience toggle nor the Repo Snapshot Indexing toggle gating it and a filesystem immutability flag on the checkpoints directory named as the only working defence. The post does not show a completed upload: the state file it quotes records a 313MB archive sitting in the local pending directory with a failure count of 564, and the upload and encryption path is reconstructed from the client's decompiled app.asar plus observed socket endpoints. This is one researcher's reverse engineering with no vendor statement, the blog states its posts are AI-drafted and author-approved, and one commenter on the second thread reports no checkpoints directory and no capture logs on a long-running install.
- Comments: HN commenters on the second thread identify the tokenstead.ai page submitted there as an AI paraphrase of the original post, and redirect readers to the thread on the author's own blog, which is the primary and the first discussion link here.
- Why it matters: The payload described is the whole repository lineage rather than the working tree, which carries API keys deleted in later commits, unpushed branch names and internal host names in .git/config.
- Follow-up: Track a Z.ai response and any independent reproduction of the sidecar behaviour on a clean install.
send feedback on this story