A coding app uploaded your files, then opened its source

A timeline of confirmed events:

• 2026-07: ZCode launched (~July) as Z.ai's agentic coding workbench (devops.com coverage of debut; GitHub repo context).
• 2026-09-17: Developers began reporting on X and RedNote that ZCode was uploading local workspace data to external servers without explicit consent (Tech in Asia).
• 2026-09-18 (Friday): Researcher Ferstar published a teardown (blog.ferstar.org) showing: while signed in, ZCode silently packaged the entire working directory into an encrypted snapshot; one 313MB archive covering 42,411 files of a commercial project, 86.6% of it .git data (196.1MB LFS objects, 102.2MB commit-history objects, 0.6MB logs), had failed 564 upload attempts; a smaller 15KB snapshot (538 files of a public repo) had uploaded successfully. The archive was encrypted with AES-256-CTR wrapped via RSA-OAEP-SHA256 using a server-supplied public key — the private key exists only in Z.ai's cloud, so neither the user nor the client could decrypt it. Z.ai apologized in its official Feishu community the same day, blamed the default-on "Codebase Indexing" feature (used for session-checkpoint recovery, version rollback, Repo Wiki), said it had patched the issue, pledged to open-source ZCode, and offered compensation as a weekly quota reset.
• 2026-09-19/20: SCMP (Chang Minxiao, Chen Wency) reported the account; TNW published "Z.ai encrypted the workspace it uploaded so that only Z.ai could open it. Now only Z.ai can say it was deleted." Chinese tech media covered a corporate escalation (Chengming Technology sent a legal-demand letter claiming six workspaces, source code, DB passwords and employee data had been uploaded) and reported that a leading Chinese robotics company banned Z.ai's tools internally.
• 2026-09-21 (Monday) — EVENT DATE: Z.ai announced on the official ZCode X account: remediation completed, sincere apology, Repo Wiki removed, the local-repository-snapshot upload workflow disabled and removed in ZCode v3.14.0, the codebase open-sourced on GitHub (Apache-2.0), a zero-data-retention feature enabled on the coding assistant, standing security-vulnerability reporting process with severity-based rewards, and CAICT + NSFOCUS assessments finding the OSS bucket emptied ("zero-data state"). Zhipu's HK-listed stock fell >4% intraday (Chinese media reports). Chengming Technology withdrew its earlier claim the same day, saying it had relied on wrong evidence (Reuters).
• 2026-09-22/23: Ferstar re-audited the now-public code: the upload pipeline is gone and the remaining checkpoint mechanism does only local Git work — but the published repository carries only three commits (two at first), with the development history and the pre-patch uploader code erased, so prior behavior cannot be independently inspected. The full security-assessment report had not been released as of 2026-09-23. Chinese media reported Zhipu additionally planning "no-retention" controls on its Model-as-a-Service (MaaS) platform. Related context: xAI's Grok Build was caught doing the same thing in July 2026 (uploading entire Git repositories) and responded with deletion + documented zero-retention policy + privacy endpoint — the template Z.ai is now following.

• ZCode went from closed-source to open-source (Apache-2.0) — the entire workbench client (Electron desktop, Web client, backend server, shared UI, Agent CLI/runtime) published under https://github.com/zai-org/ZCode.
• The exfiltrating behavior was removed: Repo Wiki feature deleted; the workflow that generated and uploaded local repository snapshots disabled, with the fix shipped in ZCode v3.14.0 (now v3.14.3).
• A zero-data-retention feature was enabled on the ZCode coding assistant (Reuters: "Z.ai said it had enabled a zero-data retention feature on the coding assistant used by developers and tech enterprises"); Z.ai said previously uploaded data was destroyed and never used in model training, backed (per company) by CAICT/NSFOCUS assessments showing the zcode-prod OSS bucket empty.
• A standing vulnerability-disclosure process was established — a bug bounty in everything but name, with rewards based on severity.
• Trust posture changed material: Z.ai, an open-weights-first company, exposed that its client was closed and un-auditable; the open-sourcing converts the client into a community-audited artifact.
• Planned (not yet live at event date): optional no-retention ("non-retention of content") controls on the MaaS platform — inputs and outputs of standard model calls not statically stored, used only for the current request (Pandaily, DIGITIMES).

BEFORE (until ~2026-09-17/18): ZCode closed-source client; "Codebase Indexing" enabled by default; while signed in, the client packages the whole workspace (working tree + .git history + LFS + reflogs + global config) into an encrypted snapshot and attempts to post it to Alibaba Cloud OSS; settings labeled "Optimize Experience" / "Repo Snapshot Indexing" did not stop capture; deletion of a pending snapshot caused a fresh repack within ~30 minutes; the privacy policy (effective 2026-06-15) described collecting conversation text/files but said nothing about workspace snapshots; the decryption key lived only in Z.ai's cloud.

CHANGE (2026-09-18 → 2026-09-21): Users detect and publicize the behavior (Ferstar, Feng Ruohang, J.F. Zhang); Z.ai apologizes Friday; Monday it patches (v3.14.0), removes Repo Wiki and the upload workflow, enables zero-data retention, claims deletion of uploaded data verified by CAICT/NSFOCUS, and publishes the full source under Apache-2.0.

AFTER (2026-09-22 →): Upload pipeline gone (Ferstar re-audit confirmed); remaining checkpoint mechanism does local Git work only; source is publicly inspectable, but the erased commit history means the pre-patch snapshot/upload code cannot be audited; zero-retention claim rests on Z.ai's word plus company-commissioned assessments; full CAICT/NSFOCUS report unpublished; MaaS no-retention option announced as coming; developer and enterprise trust in Chinese AI coding clients under stress; parallel with July 2026 Grok Build incident widely noted.

Technical mechanism (INDEPENDENTLY VERIFIED via reverse-engineering by Ferstar and J.F. Zhang; details corroborated in runtimewire, dev.to, SamCodeMan write-ups):

• Capture: When a user is signed in, ZCode periodically packages the current workspace directory (the "working directory" plus .git — objects, LFS cache, reflogs — plus global application config) into a compressed snapshot. Trigger sources included a pre-prompt capture and a Repo Wiki update task.
• Encryption: Snapshot contents encrypted with a random symmetric key (AES-256-CTR); the symmetric key is wrapped with RSA-OAEP-SHA256 using a public key fetched from Z.ai's server (endpoint /api/v1/snapshot/upload-credential). The RPC returns a snapshot ID, storage credentials, size limits and the RSA public key. The private key exists only on Z.ai's backend, so the local ciphertext cannot be decrypted by the user or by the client — an architecture that protects transfer from third parties while guaranteeing Z.ai's backend can read everything.
• Upload: The client POSTs the encrypted archive directly to Alibaba Cloud OSS (bucket zcode-prod); Alibaba's storage then calls back to Z.ai's backend to register the snapshot. Ferstar's observed archive had failed 564 times (network/credential churn) and sat in a pending local queue; one 15KB snapshot of a public repo had succeeded.
• No effective off-switch: two UI settings ("Optimize Experience", "Repo Snapshot Indexing") governed downstream data use, not the capture itself; capture ran unconditionally while signed in; deleting a pending snapshot triggered a fresh repack (~30 min later).
• Fix (v3.14.0): Repo Wiki removed; upload path deleted; the retainable checkpoint mechanism was refactored to local Git operations only with no cloud path (confirmed by Ferstar's post-publication re-audit).
• Zero retention (claimed): Z.ai says the zcode-prod bucket was emptied/deleted (CAICT: "zero-data state"; NSFOCUS: bucket and objects gone) and that uploaded data was never used to train models; ZCode has an enabled zero-data-retention feature; MaaS no-retention controls are planned for standard model calls.

• A first-of-kind accountability play by a Chinese AI lab: a front-rank Chinese lab publicly disclosed a security incident, apologized, open-sourced the product and enabled zero retention — "a rare public disclosure of a security breach by a Chinese AI lab" (Reuters), coming days after China's cyberspace regulator updated its AI safety framework (warning about shutdown resistance, evaluator deception, sandbox escape).
• It defines the "agent silently uploads private files" failure class: coding agents have near-unlimited read access; this incident is the clearest demonstration that capabilities granted to the agent (files, Git history) are also granted to its vendor by default. Git history is where deleted credentials, internal hostnames and abandoned branches live — "a full repository snapshot is quite sensitive" (developer commentary via SCMP).
• It exposes a verification asymmetry: encrypted-at-rest data held with a vendor-controlled key means the vendor is the only party able to prove deletion. Open-sourcing the client answers a different question than the one users asked.
• Template for incident-to-transparency conversion: the response sequence (patch → disclose → independent assessment → open source → zero retention → bounty) is a replicable playbook — but the erased commit history shows how open-washing can blunt it (TNW: "The verification problem moved rather than closed").
• Direct precedent symmetry: xAI's Grok Build in July 2026 uploaded entire Git repos; xAI responded with deletion, a documented zero-retention policy and a privacy endpoint. Z.ai's response mirrors it — a nascent industry norm ("snap-delete solidarity") for agent-vendor data handling.

• Independent security auditing of an AI coding client by anyone — the GitHub repo now lets researchers inspect default-enabled behaviors, network calls and encryption before adoption.
• A community-verifiable baseline for "does this agent exfiltrate?" — Ferstar's re-audit already confirmed the upload pipeline's removal, the first third-party verification of a fix.
• Enterprise security teams can now do source-level due diligence on ZCode (threat-model, build from source, block telemetry) instead of trusting a binary.
• Regulatory/precedent setting: a Chinese AI lab has committed to a published security-assessment report, a severity-based bounty, and zero/no-retention features — measurable commitments that can be audited over time.
• Comparison tooling: customers can weigh Z.ai's open client against closed rivals (Cursor, Copilot, Claude Code) with actual evidence about data flows.

1. How long was the default-on capture active before 2026-09-17, and across what versions?
2. How many user workspaces were actually uploaded (successfully) versus queued-and-failed?
3. What happened to every successfully uploaded object — true deletion across backups and logs, or bucket-only clearance? Who outside Z.ai can attest?
4. When will the full CAICT/NSFOCUS assessment report be published, and will it cover pre-fix data flows?
5. Was any uploaded data used for model training or product improvement despite the denial?
6. Why was the commit history wiped, and will the pre-patch snapshot/upload code ever be released for forensics?
7. Will the pending MaaS no-retention controls be default-on or opt-in, and will they also cover ZCode conversations?
8. Will ZCode adopt user-held encryption keys or source-level transparency that makes "no retention" technically provable?
9. What will the erosion of trust cost Zhipu commercially (MaaS/enterprise deals, IPO-era investor confidence)?
10. Does the Chinese regulator's updated AI-safety framework translate this incident into concrete obligations (e.g., mandatory disclosure windows, retention limits) for Chinese AI tool vendors?

• Short term (days/weeks): full CAICT/NSFOCUS report expected; community auditing of the released code will surface findings (the newly announced bounty makes this likely); watch whether the erased commit history becomes a sustained controversy; MaaS no-retention controls rollout announced as "soon".
• Medium term (quarters): zero/no-retention becomes a standard expectation for AI coding tools; rivals respond (pre-emptive open-sourcing or retention guarantees); enterprises codify agent-egress audits; Chinese regulator follow-up on AI-tool data handling likely.
• Wildcards: discovery that uploaded data survived somewhere (breaking the deletion claim); a second, related vulnerability in the open code; regulatory fine/action in China; US/geopolitical restriction headlines citing this incident.

This is the strongest story of the week on the agent-security beat, and it has two legs. The first is the failure class: a default-on feature shipped a developer's entire Git history — the part of a repo that keeps all its old secrets — to a vendor's cloud, encrypted in a way the owner couldn't even open. That is the clearest possible illustration that when you give an agent your folder, you may be giving the vendor your folder. The second leg is the response: open-sourcing the client, enabling zero retention and commissioning CAICT/NSFOCUS assessments is a genuine, rare accountability play by a Chinese lab — the first since the Grok Build case to follow the "delete, document, disclose" template. But the release shipped with its history scrubbed, the deletion claim rests on the word of the only party that could have been checked, and the full report hasn't landed. The fix is half-favorable: the upload pipeline is provably gone; whether the data ever really went away remains a matter of trust. That asymmetry — transparency at the code level, opacity at the data level — is the lesson, and it applies to every AI coding tool on the market, not just Z.ai's.

Evidence sources: see sources/S12.md. Research window per RESEARCH_CONFIG.json: 2026-09-18 → 2026-09-22. Event date 2026-09-21 is inside the window.