ZCode Uploaded Whole Workspaces, Git History Included, to Z.ai's Cloud. Z.ai Says It's Fixed. Rotate Your Secrets Anyway

If you ran ZCode on a repository before the fix, assume that repository's full Git history left your machine. That includes secrets you committed once and deleted later. Update ZCode, then rotate those secrets. Z.ai says the upload is gone, and the researcher who found it agrees. What was already uploaded is out of your hands.

Our verdict: ZCode stays conditional. The condition is now concrete. Run 3.14.0 or later, and don't count a vendor's word as proof that your old commits were never read.

What happened

On 18 September, researcher ferstar published a reverse engineering of ZCode 3.12.3, Z.ai's agentic desktop IDE. The findings:

• The flow. While you were logged in, ZCode packed the workspace into an archive, encrypted it with AES-256-CTR and wrapped the key with RSA-OAEP-SHA256. The RSA public key came from Z.ai's server, so only Z.ai could decrypt the archive. ZCode then posted the archive straight to Aliyun OSS using upload credentials issued by zcode.z.ai.
• The scope. In ferstar's commercial test project, one snapshot held 42,411 files and was 345MB before compression. The .git directory made up 86.6% of it, with LFS at 56.8% and objects at 29.6%. A separate manifest also bundled your global ZCode config files into every snapshot, across workspaces.
• The triggers. Capture ran before every prompt and on completion of tasks tagged repo-wiki-update. One session produced up to 62 capture events.
• The toggles. "Optimize Experience" only governed training use. "Repo Snapshot Indexing" only governed server-side indexing. The capture and upload sidecar started unconditionally at launch. When ferstar deleted a pending package, ZCode captured it again within half an hour.
• The policy. Per ferstar, Z.ai's privacy policy covers text, files and code submitted in conversations. It never mentions packaging whole workspaces or Git histories.

What Z.ai did

Z.ai responded quickly, though not on the channels most users watch. According to ferstar's later updates to the post:

• 18 September, 17:44. Z.ai posted an official statement in its user community. It said the feature "was on by default in its early launch period", that "some users were affected" and that the issue "has been fixed". It promised to open-source ZCode with third-party review and gave all users one extra weekly quota reset.
• 21 September. Z.ai published zai-org/ZCode(abre num novo separador) on GitHub. ferstar found the repoSnapshot pipeline stripped from the code. The statement also cited NSFOCUS, which it said "confirmed that the bucket and all internal objects have been deleted, with no outbound transmission paths detected." The full NSFOCUS and CAICT reports were promised but had not appeared in the statement ferstar summarised.
• 23 September. ferstar unpacked ZCode 3.14.3 and found "zero occurrences of repoSnapshot logic". Process logs and the checkpoint folder showed no workspace packaging and no new .enc archives. ferstar's audit of 3.14.0 had already found the upload sidecar dismantled.

Tokenstead separately reports a reply from someone affiliated with the ZCode team: "hey I am sorry to let you find it". A user's issue on Z.ai's zcode-plugins repository, opened 18 September, still had no Z.ai reply when we checked on 1 October.

Why it matters

Z.ai fixed the client fast. That doesn't undo what happened. Workspaces were uploaded without disclosure, the in-app privacy toggles didn't stop it, and users couldn't decrypt their own archives to see what was taken. ferstar puts the remaining gap plainly: proving a bucket was emptied after 20 September "cannot retroactively reconstruct what happened to data uploaded prior to Sep 18."

We rate Grok Build CLI caution for undisclosed full-repo uploads. ZCode stays a notch higher because Z.ai admitted the behaviour within hours, shipped a client without it, and opened the code so people can check. That is the standard we expect when a vendor gets caught. It doesn't make the original design acceptable.

What changes for you

1. Update to 3.14.0 or later. That is the first build ferstar audited without the upload sidecar. 3.14.3 is also clean.
2. Rotate secrets. Do it for every repo you opened in ZCode before the fix, including keys removed in later commits. Git history keeps them.
3. If you can't update yet, use ferstar's workaround and make the checkpoint folder immutable:
   • macOS: chflags uchg ~/.zcode/v2/checkpoints
   • Linux: sudo chattr +i ~/.zcode/v2/checkpoints
   
   You lose ZCode's checkpoint rollback. Everything else keeps working, per ferstar.

FAQ

Is my code still on Z.ai's servers? Z.ai's statement cites NSFOCUS as confirming the bucket and its contents were deleted. No one outside Z.ai can verify what happened to that data before deletion, so treat committed secrets as exposed.

Was every ZCode version affected? ferstar's analysis covers 3.12.3. Z.ai says the feature was on by default "in its early launch period" but hasn't published a version range.

Do I still need the immutable-folder workaround? Not on 3.14.0 or later. In those builds, ferstar found no snapshot code to block.