Open Source as Damage Control: Z.ai Publishes ZCode After the Silent Git History Upload Scandal

On September 21, 2026, Z.ai pushed the entire ZCode codebase to GitHub under an Apache-2.0 license. The release — covering the Electron desktop app, the browser interface, the terminal agent, backend services, shared UI components, and the agent runtime — was framed as the completion of a remediation promise. Three days earlier, a developer publishing under the name ferstar had released a reverse-engineering report showing that ZCode, the official coding client of the Beijing-based company behind the GLM model family, was silently packaging users’ entire workspaces — including complete Git histories — into encrypted archives and uploading them to Alibaba Cloud.

The speed of the reversal is unusual. So is the gap between what the open-source release can prove and what it cannot.

What ferstar found

The report, published September 18 on ferstar’s blog and dissected across Hacker News (335 points), technical newsletters, and the South China Morning Post, reconstructed ZCode’s behavior from the packaged Electron application and from live traffic captures. The picture that emerged was not one of ordinary telemetry.

Whenever an authenticated session was active, the client coordinated with Z.ai’s backend to obtain pre-signed upload credentials for Aliyun OSS — Alibaba Cloud’s object storage — along with a per-round RSA public key. A background worker then packaged the entire active workspace into a tar.gz archive, encrypted it with AES-256-CTR, encrypted the symmetric key with the server-supplied RSA public key, and POSTed the result directly to Aliyun storage endpoints. A webhook callback told Z.ai’s backend the snapshot had landed.

The numbers from one examined installation were stark: a 345 MB commercial workspace of 42,411 files became a 313 MB encrypted archive queued for upload. The composition mattered more than the size. The .git directory accounted for 86.6% of the payload — 196.1 MB of Git LFS data, 102.2 MB of the core object store, plus reflogs. The actual working tree, the files a developer could see and had chosen to open, made up just 46.2 MB, or 13.4%.

That ratio is the heart of the incident. A Git object store is not a snapshot of the working tree; it is the complete lineage of the repository. Secrets committed months ago and purged in later commits, unpushed local branches, discarded prototypes, and reflog debris all remain recoverable inside .git until someone runs a destructive purge across every branch. A tool that sweeps the whole database harvests every historical credential the repository has ever contained — including ones the developer believes were deleted. And in ferstar’s analysis, Z.ai held the only RSA private key, meaning the user could not even decrypt the archive sitting on their own machine. Local metadata recorded 564 failed upload attempts for a single snapshot, evidence of a persistent retry state machine that kept trying until it succeeded.

The toggles that didn’t work

ZCode’s settings contained two switches that looked relevant. “Optimize Experience” governed whether user content could be used for training. “Repo Snapshot Indexing” controlled whether the server indexed a snapshot after upload. Ferstar found that with both disabled, the client still packaged the workspace and attempted the upload — the toggles governed downstream use, not the capture pipeline itself. Separate reports filed in Z.ai’s public feedback repository described the same behavior in ZCode 3.12.3, including snapshots created while repository indexing was set to false.

Z.ai’s September 18 statement attributed the behavior to the “codebase indexing” feature, enabled by default in the product’s early period, which supports session checkpoint restoration, version rollback, and a Repo Wiki capability. When Wiki pages are generated, the company said, repository data may be uploaded — and “destroyed immediately” after cloud-side generation, not stored. The company apologized, promised to open-source the codebase, said it would invite third-party evaluators to review how the system operates, and, in a gesture that drew its share of gallows humor on Hacker News, granted all ZCode users one extra weekly quota reset.

The trust problem with the “destroyed immediately” claim is structural, as The Next Web’s coverage put it plainly: because Z.ai encrypted the uploads with a key only it holds, only Z.ai can say the data was deleted. Users have no way to verify it.

What open source proves — and what it doesn’t

Today’s release is more substantial than a token gesture. The repository ships the desktop host, web server, provider integrations, remote-workspace components, and terminal agent, with local build instructions for all three distributions — not a thin UI shell around a closed binary. Its README is also unusually candid about the trust boundary: the shared execution adapter has no default operating-system sandbox, enabled plugins can introduce hooks and external processes, remote environments may receive prompts, files, tool results, and credentials, and logs may contain prompts, code, context, and tool parameters. Some credentials are stored in encrypted local files rather than the OS keychain.

Developers can now audit whether the client still requests upload credentials, whether workspace capture remains in any execution path, and whether distributed binaries actually match the public source. What the release cannot do is prove anything about the server side. Client code shows what was sent; it cannot show what was retained, who accessed it, or whether Z.ai’s deletion claims hold. ZCode’s own notice concedes that internal processing behind its gateway is outside the scope the repository can verify. Notably, the repository launched with only two commits — a consolidated code drop, not the development history — and without a SECURITY.md or published security advisories, leaving GitHub’s Security tab without standard private reporting instructions on launch day, despite community scrutiny being the stated rationale for the release.

The pattern

This is not the first such incident. As Hacker News commenters recalled, xAI open-sourced Grok Build roughly two months ago after a similar controversy over wholesale repository uploading — though ZCode’s case was worse in one respect: there was no working opt-out at all. The episode also lands at an awkward moment for Z.ai, which has built its brand on open weights — the GLM series it delayed in August for an unprecedented safety review — and which was named in the September 8 NSA/CISA/FBI joint advisory alleging coordinated distillation of US frontier models. A company whose value proposition is “you can run our models yourself” was caught running a client whose data practices its users could not inspect.

The deeper lesson generalizes beyond one vendor. Every agentic coding tool — Claude Code, Codex, Copilot, Gemini CLI, ZCode — operates with sweeping filesystem access by design, and the past week alone saw Plugin4Shell, a zero-click RCE affecting the plugin systems of four major agents. The unit of trust is no longer the model’s weights; it is the harness around it: what it reads, what it logs, what it sends, and whether the switches it shows you actually gate the pipeline. Z.ai has now made that layer inspectable for its own client. Whether third-party auditors and reproducible build comparisons confirm the remediation — and whether other vendors follow suit unprompted rather than after being caught — will determine whether this becomes an industry standard or a cautionary tale with a quota reset attached.