GoKawiilOn September 18, 2026, a developer going by ferstar published a reverse-engineering walkthrough of ZCode, the AI coding desktop app from Z.ai, the Beijing-headquartered company behind the GLM family of open-weight models - the same models running on local rigs all over the local-AI community, including GLM-5.3-Flash, tracked on this site. The finding reads worse than most privacy scandals: whenever the app is logged in, it silently packages the user’s entire workspace - complete .git history, LFS asset cache, reflogs, and global app configs - encrypts it, and uploads the archive to Aliyun OSS, Alibaba Cloud’s object storage. The researcher’s own capture: a 313MB encrypted archive built from a 345MB commercial workspace, 42,411 files, with 564 failed upload attempts logged while the researcher investigated.
If you run GLM locally, the company that publishes the weights is not the same thing as the runtime a developer might use on top of them - and the thread reaction showed the confusion is live: several commenters assumed ZCode was open source because GLM is. It is not. The weights are open; the harness is closed, and it is Z.ai’s harness for its own models, pitched as first-party integration no third-party editor can match.
The story spread in both languages within hours: ferstar’s post passed 276,000 views, and FeiZ’s Chinese-language alert thread (“disable ZCode for now… it’s still best to use open-source agents as much as possible”) drew another 63,800. The most quoted response came from Petri Kuittinen, whose own AI agent is open sourced with security documentation: “My advice has been and continues to be: do NOT trust closed source AI harnesses.”
The detail that turned a suspicious directory into a story: the encryption key. ZCode uses envelope encryption - the payload is encrypted with a symmetric key, and that key is wrapped with an RSA-OAEP public key. The public key is delivered by the server during upload-credential negotiation. The corresponding private key lives only in Z.ai’s cloud. ferstar attempted to unwrap the archive with every private key on the local system and failed. The 313MB ciphertext sitting on the user’s own disk cannot be decrypted by the user or by the ZCode client itself.
ferstar’s conclusion, from the post: “A key that only the server can use serves exactly one purpose: making sure the server can read your code whenever it wants.”
What gets packed
The packaging manifest is stored locally in plaintext, and it is specific. For a 42,411-file snapshot:
Content Size Share .git/lfs/ 196.1 MB 56.8% .git/objects/ 102.2 MB 29.6% .git/logs/ 0.6 MB 0.2% Source code and docs 46.2 MB 13.4%
The .git directory alone is 86.6 percent of the payload.
Payload breakdown of one 42,411-file snapshot: the .git directory is 86.6 percent of the encrypted archive. ::: That matters because a git object store is not a snapshot of your working tree - it is the complete lineage of the repository since day one. Deleted-in-a-later-commit API keys are in there. Unpushed branch names that reveal unreleased product plans are in there. Internal hostnames and repo paths from .git/config are in there. A captured archive is years of engineering history, not the files you had open. The upload pipeline, reconstructed from the client’s app.asar : the client requests credentials from zcode.z.ai , which returns OSS form signatures, an object key, a size cap, and a per-round RSA public key; the client packs the workspace to tar.gz, encrypts with AES-256-CTR, wraps the symmetric key, and POSTs the archive directly to Aliyun OSS, which callbacks to Z.ai’s backend to register the snapshot. The running client maintained persistent connections to zcode.z.ai and two Aliyun OSS nodes during the test. :::figure /images/articles/zcode-git-upload/upload-flow.svg The reconstructed ZCode snapshot upload flow: credentials from the coordinator, local packing and encryption, direct form POST to Aliyun OSS, callback registration. Reconstructed from the client app.asar by ferstar.
... continue reading