Z.ai Open-Sourced ZCode After a Silent 313MB Upload: What the Lesson Costs You

On September 18, 2026 an engineer writing as ferstar published what he found inside ZCode: the coding tool was quietly packaging an entire workspace, encrypting it, and uploading it to Alibaba Cloud. In his local checkpoint directory sat a 313MB encrypted snapshot of a commercial project, and the status log recorded 564 failed upload attempts. Worse, the upload mechanism was on by default with no off switch. On September 21, Z.ai open-sourced ZCode under Apache 2.0. The value of the incident is not one company. It is that client-side AI tooling just got a very public trust-boundary exam.

The Confirmed Facts, Restated

Here is what multiple outlets corroborate. Trigger: on September 18 the developer ferstar disclosed that ZCode encrypted and uploaded user workspaces to Alibaba Cloud (Aliyun OSS) without consent. Scale: one developer's workspace was packaged into 42,411 files and a 313MB encrypted archive, with 564 failed upload attempts. Scope: the archive included full version history and large-file caches, and filenames were still visible inside it. Switch: the upload mechanism was enabled by default with no off option. Response: Z.ai (formerly Zhipu AI) apologised on September 18, said on September 21 it had disabled the feature, open-sourced ZCode under Apache 2.0, and stated the uploaded data had been destroyed. Two more details matter for anyone building a checklist. The upload mechanism was enabled by default rather than opt-in, and filenames inside the encrypted archive were still readable, which is how the affected developer identified a commercial project among the packaged files.

// The mechanism is not exotic. A background task packages the workspace, encrypts
// it, and posts it to object storage. The lesson is architectural: anything a
// client can build, a client can also be audited for building.

async function checkpointer(workspace) {
  const files = await walk(workspace);                 // 42,411 files, in the report
  const tmp = await packEncrypted(files);              // 313MB archive, per the report
  try {
    await upload(tmp, process.env.CLOUD_BUCKET);        // Aliyun OSS
  } catch (e) {
    // 564 failed attempts, per the report. It kept trying.
    return retryLater(tmp);
  }
}

313MB, 564 attempts, on by default, no off switch

What the Open-Source Release Can and Cannot Prove

Keep fact and inference separate here. The open-sourcing is a real remedy, but its explanatory power has limits. The public repository carries two commits: the development history is gone, and so is the code that performed the upload. When ferstar re-checked on September 21 he confirmed the upload pipeline was fully removed and the remaining checkpoint mechanism only does local Git work. That is the good news. But the claim that data was destroyed is not verifiable from the client itself — a deletion claim ultimately rests on the word of the party that deleted. Saying so is not conspiracy thinking; it is basic honesty in a security audit. The nuance is worth stating plainly. Open-sourcing is a meaningful corrective step, and the removal of the upload path is verifiable because the code is now public. What is not verifiable from the client is the past. You can prove what it does today; you cannot prove from the same artifact what it did last week.

# You cannot audit a compiled client by reading its source after the fact.
# You can, however, watch what any locally-installed tool does on the wire.
# Run new AI coding tools in a sandbox where outbound calls are visible.

npx --yes @zai/zcode --version    # install in a disposable VM, not your workstation

# Then, while it indexes: who is it talking to?
sudo lsof -i -nP | grep -E 'zcode|node' | head

# And did it write a large archive anywhere on disk?
find ~ -type f -size +50M -newermt '-10 minutes' 2>/dev/null \
  | grep -Ei 'checkpoint|cache|snapshot' || echo "no large new archive"

Do Not Audit a Compiled Client as If It Were Source

The most transferable lesson is methodological: you cannot audit a compiled client by reading its source after the fact. What you can do is watch what any locally installed tool does on the wire. Install new AI coding tools in a disposable VM, and while they index, look at who they talk to and what large files they write to disk. If a tool insists on indexing your repository, first give it a repository that is safe to index: an isolated, disposable checkout with .git history, LFS caches, and secrets removed. That habit is the whole lesson. Trust in a developer tool should be earned by observation, not by reputation, and observation needs a place to happen that is not your production machine.

# If a tool insists on indexing your repository, give it a repository that is safe
# to index. The blast radius of a silent upload is set by what you let it see.

# 1) Never point a fresh, unverified agent at your commercial monorepo.
git worktree add ../sandbox HEAD~0        # an isolated, disposable checkout

# 2) Strip the things that must not travel: history, LFS, secrets.
rm -rf ../sandbox/.git
grep -rIl 'AKIA\|sk-\|-----BEGIN' ../sandbox | xargs -r rm -f

# 3) Only after it earns trust, widen the scope. Not before.

The public repo carries two commits; history and upload code are gone

Write Blast Radius Into the Process

The blast radius of a silent upload equals what you let it see. So the first rule is plain: never point a fresh, unverified agent at your commercial monorepo. Second, express policy as code and enforce it in CI — a client-side indexer has no reason to open an object storage bucket, so deny it in network policy rather than file a postmortem after the fact. Third, treat installation itself as a trust boundary: a new CLI is a new network identity. The second rule is less obvious: consent that cannot be declined is not consent. When a feature is on by default with no off switch, the choice in opt-in is missing, and an organisation should treat that absence as a finding in its own right.

// Verification is the hard part of a "we deleted it" claim. If the client you are
// inspecting no longer contains the upload path, you can prove what it does now.
// You cannot prove what it did last week from that same client.

type AuditResult = {
  uploadPathPresent: boolean;   // falsifiable by reading the public repo
  dataDestroyed: "unverifiable-from-client";
};

function audit(publicRepo: string): AuditResult {
  const src = readAllSources(publicRepo);
  return {
    uploadPathPresent: /aliyun|oss|upload/i.test(src),
    // The deletion claim rests on the word of the party that deleted. Say so.
    dataDestroyed: "unverifiable-from-client",
  };
}

Give the Tool the Policy It Should Have Shipped With

Rather than waiting on vendor virtue, write the policy you want and enforce it. Run an .agentpolicy rule in CI on every dependency bump: deny outbound domains that point at object storage, require explicit consent for workspace upload and codebase index egress, and fail on unlabeled telemetry. It is cheap, and it is the only control that survives the next tool. Tools change; the boundary should not change with them. Write the policy once and every future tool inherits the boundary. That is the difference between responding to one incident and reducing the odds of the next, which is the only durable outcome after news like this.

# Write the policy you wish the tool had shipped with, and enforce it in CI. This
# is cheap, and it is the only control that survives the next tool.

# .agentpolicy.yml  (run in CI on every dependency bump)
deny_network:
  - "*.aliyuncs.com"
  - "*.amazonaws.com"
  # a client-side indexer has no reason to open a bucket
require_consent_for:
  - workspace_upload
  - codebase_index_egress
fail_on_unlabeled_telemetry: true

# Then gate installs, not just builds. A new CLI is a new network identity.

Before the tool runs, watch where it wants to connect

The Price of the Lesson

Read the incident as a stress test. The good part is that the open-source remedy is real and the mechanism was genuinely removed. The awkward part is that the verification chain ends in the deleting party's hands. What is worth taking away is not "avoid one tool" but three portable disciplines: run new clients isolated first, let a sandbox rather than trust set the blast radius, and turn consent and egress into executable policy. Those three hold for the next ZCode, and for the next popular CLI you have not heard of yet. The price of the lesson is the audit you cannot complete: a deletion claim you have to take on faith. The way to stop paying it is to make the next tool prove itself before it ever sees a real repository.