Z.ai Open-Sources ZCode Days After a Git-History Upload Apology

Z.ai, the Beijing-based startup led by chief executive Zhang Peng, open-sourced its ZCode coding agent under the Apache 2.0 license on Monday, three days after apologizing for an undisclosed feature that uploaded users' encrypted workspaces, Git history included, to Alibaba Cloud.

What ferstar found on Sept. 18

A ZCode subscriber who uses the pseudonym ferstar published a reverse-engineering writeup on Friday showing that the app's desktop client requested a one-time RSA key and signed upload credentials from zcode.z.ai, packaged the current project into an encrypted archive, and posted it directly to Alibaba's OSS object storage, without a prompt or a visible transfer indicator.

Ferstar, who describes running the app on a base-spec MacBook Air and noticing unexplained disk activity, traced the behavior through several methods: inspecting the app's local ~/.zcode directory, capturing network traffic through a home OpenWrt router, reverse-engineering the packaged app.asar file that Electron applications bundle their code into, and reading the plaintext manifest files the upload process generated before encryption. That combination of filesystem, network and binary analysis is what let the writeup describe the upload pipeline in the detail it did, rather than only observing that outbound traffic existed.

One captured archive ran 313 megabytes for a 345-megabyte workspace holding 42,411 files. Ferstar's breakdown put 56.8% of that archive in the Git LFS cache, 29.6% in Git commit objects and 0.2% in Git reflogs, for a combined 86.6% of the upload coming from the .git directory rather than from source files a developer might expect an indexing feature to need.

Share of uploaded archive	Source
56.8%	Git LFS cache
29.6%	Git commit objects
0.2%	Git reflogs

The encryption Z.ai controls, not the user

The archive was encrypted with AES-256-CTR, with the symmetric key itself wrapped using RSA-OAEP-SHA256 and a public key supplied by Z.ai's server at upload time. Ferstar's writeup says the matching private key exists only on Z.ai's infrastructure, meaning a user who found the archive sitting on their own disk had no way to open it themselves.

Ferstar tested two ZCode releases: version 3.12.3, where uploads fired repeatedly, 62 times in a single logged session, and version 3.14.0, where the upload code had been removed. Two settings that looked like they should have stopped it, labeled Optimize Experience and Repo Snapshot Indexing in the app, did not: the first governed only whether Z.ai could use a user's code for model training, the second only server-side search indexing. The upload process itself started automatically whenever the app held a valid login token.

ZCode is now a public GitHub repository built as a TypeScript monorepo covering a desktop app, a browser-based interface and a terminal agent, distributed under the Apache 2.0 license Z.ai chose for Monday's release. The project's own build instructions call for Node.js 24.14.0 and the pnpm 10.33.2 package manager, and the command-line installer defaults to a runtime directory at ~/.zcode, the same path ferstar's writeup traced the disputed uploads through.

What that means for the developers who use it

ZCode markets itself as the official harness for Z.ai's GLM-5.3 model, aimed at developers who want an agent that can read and modify a full codebase rather than a single file at a time. That is precisely the class of tool the incident calls into question: a coding agent needs broad filesystem access to do its job, which is what made an unannounced upload of that same filesystem hard for users to notice until someone went looking for it in network traffic.

Z.ai's response and what's still open

Z.ai posted a statement at 17:44 China time on Sept. 18 attributing the uploads to a codebase-indexing feature built for session recovery, version rollback and an automated Repo Wiki, saying Wiki generation specifically could trigger the upload, and that it had fixed the behavior. The company did not say how much previously uploaded data it retains or for how long.

RuntimeWire's follow-up on Monday's open-sourcing lists what the release still leaves unresolved: whether the binaries Z.ai distributes actually match the Apache-licensed source now on GitHub, why the repository shipped without a SECURITY.md file or an advisory, and what became of a reported 564 failed upload attempts logged by users during the affected period. The GitHub repository had drawn 5.4 thousand stars and 1.5 thousand forks within its first day.

What would change the read

Open-sourcing the client answers the question of what the code does going forward; it does not answer what happened to data already uploaded under the old behavior; that requires either a published retention policy or independent access to Z.ai's server logs, neither of which has surfaced. Until one does, the apology and the source release are a company's account of its own conduct, not a verified one. The episode sits alongside a wider pattern of AI coding tools drawing scrutiny over what they send home by default: Sarah Jamie Lewis built an entire Firefox fork to strip out AI features rather than trust a vendor's opt-out toggles, and researchers have separately shown browser-based AI assistants can be hijacked through channels a user never sees either.

There is also a narrower technical question the open-sourcing does not settle: whether the compiled binaries Z.ai distributes through its own installer actually match the source now published on GitHub. Without a reproducible build process or a signed hash a user can check against the published code, publishing source under Apache 2.0 demonstrates intent rather than proof that the shipped application matches it line for line.