Z.ai's ZCode agent silently ships your entire git history to Alibaba's cloud

A reverse-engineering writeup by a developer known as ferstar alleges that ZCode, the closed-source coding desktop app from Beijing-based Z.ai (maker of the open-weight GLM models), quietly captures a user’s full workspace whenever the app is logged in. The bundle isn’t just open files: it includes the complete .git object store, reflogs, LFS cache, and global configs — meaning deleted API keys, unpushed branch names, and internal hostnames buried in repository lineage all get swept up. In ferstar’s test, a 345MB commercial project became a 313MB encrypted archive of 42,411 files, packed to tar.gz, encrypted with AES-256-CTR, and POSTed straight to Aliyun OSS. The .git directory alone accounted for roughly 87 percent of the payload.

The damning technical detail is the key handling. ZCode uses envelope encryption where the symmetric key is wrapped with an RSA-OAEP public key handed out by Z.ai’s server per upload, and the matching private key never leaves Z.ai’s cloud. The result is ciphertext sitting on the user’s own disk that neither the user nor the client can decrypt — only the vendor can. The capture runs as a host-level sidecar instantiated unconditionally at startup, outside the agent’s tool loop, so it appears in none of the 31 agent tools and no permission setting touches it. The two settings toggles users might reach for only govern training-data authorization and server-side indexing; local packaging and upload continue regardless, firing before every prompt and on task completion (62 capture events in one session). ZCode’s privacy policy discloses only the standard “files and code submitted during conversations,” never whole-repo exfiltration.

The context makes it sharper: ZCode launched in July 2026 pitched explicitly against Anthropic’s Claude Code in the wake of a telemetry controversy, with a Z.ai executive publicly promising nothing “beyond what’s listed” on the site — and workspace snapshotting is not listed. Commenters conflated the open GLM weights with the closed harness running on top of them, which is the real lesson here. Deleting the pending archive is futile (the client repacks within half an hour); the only durable fix is making ~/.zcode/v2/checkpoints immutable at the kernel level via chattr +i or chflags uchg, which kills the checkpoint-rollback feature but leaves chat and completions intact. The episode reframes the local-AI trust boundary: open weights don’t help if the surrounding runtime, app, and update pipeline are closed and phoning home.