Key details

  1. The incident concerns Z.ai’s ZCode AI coding environment and its Codebase Indexing/Repo Wiki workflow.
  2. Researcher ferstar documented a local snapshot containing 42,411 files and roughly 313MB after encryption/compression preparation, with 564 attempted uploads on that machine.
  3. The analysed snapshot included `.git` history, Git LFS cache and reflog data in addition to current source files.
  4. The 564 attempts in ferstar’s large-workspace test failed, but separate researcher evidence reported server-confirmed uploads for other workspaces.
  5. Z.ai apologised and says the Repo Wiki feature and associated repository-snapshot upload workflow were removed.
  6. Z.ai says CAICT and NSFOCUS assessments found previously uploaded data deleted; full assessment material was not yet publicly available in the sources inspected.
  7. ZCode is now publicly available at GitHub under `zai-org/ZCode`, exposing the client, backend, UI and Agent CLI/runtime.
  8. The public repository does not preserve a full historical commit trail for the removed upload implementation, limiting retrospective independent auditability.

What builders should take away

  1. Treat repository indexing, wiki generation, semantic search and agent-memory features as potential data-export paths until their documentation proves otherwise.
  2. Check whether a coding tool uploads `.git`, ignored files, LFS objects, reflogs or deleted history rather than assuming only visible source files leave the machine.
  3. For proprietary repositories, prefer tools with explicit per-project indexing controls, documented retention and a local-only option where practical.
  4. Rotate or revoke credentials that may have existed anywhere in Git history if an affected repository was processed by an older ZCode build and your risk model requires it.
  5. Open-source publication is useful, but verify that the public history actually covers the versions whose behaviour you are assessing.

What changed

Developers investigating Z.ai’s ZCode coding assistant found that its Codebase Indexing/Repo Wiki workflow could package local workspaces for cloud processing, including repository history and other `.git` data. Researcher ferstar documented a 313MB encrypted archive containing 42,411 files and 564 attempted uploads on one machine; other researchers reported successful server receipts on separate workspaces. Z.ai apologised, attributed the behaviour to Repo Wiki, removed that feature and the repository-snapshot upload workflow, shipped remediation in the 3.14 line, and said previously uploaded data had been deleted. It subsequently published ZCode’s client, backend, UI, Agent CLI and runtime under an open-source licence for outside inspection.

Why it matters

AI coding tools increasingly index entire repositories to build context, documentation and persistent memory. That makes apparently local convenience features a potential source-code export mechanism, and Git history can contain deleted credentials, old configuration, proprietary code and data that is no longer visible in the working tree. ZCode shows why a privacy toggle or high-level product description is not enough: developers need a precise data-flow boundary for indexing features, including what is collected, where it is sent, how long it is retained and whether `.git` metadata is included.

The upload was tied to repository indexing, not an explicit share action

The reported path was triggered by ZCode’s Codebase Indexing and Repo Wiki functionality. The client assembled workspace snapshots for cloud-side processing rather than asking the user to select files for an explicit upload. Independent analysis found archives could include the full `.git` directory, Git LFS caches, commit objects and reflogs as well as current source and documents.

Git history makes the privacy boundary much larger than the visible codebase

In ferstar’s analysed workspace, Git-related data made up most of the snapshot bytes. That matters operationally because Git history can preserve code, secrets and configuration that developers believe they deleted long ago. A coding assistant that sends repository metadata off-device therefore exposes a materially different data set from one that sends only files selected into the current prompt.

Z.ai removed the path and opened the product to inspection

Z.ai says the affected Repo Wiki feature and snapshot-upload workflow were removed and that third-party checks by CAICT and NSFOCUS found the relevant cloud data deleted. ZCode’s public repository now exposes the desktop client, web/backend components, shared UI and Agent CLI/runtime. The company says it is establishing an ongoing vulnerability-reporting process and intends to publish a fuller security assessment.

Open source improves the future audit trail, but not the past one

The newly published repository lets developers inspect current behaviour, and the original researcher says the offending Repo Wiki upload code is absent. However, independent reporting notes that the repository arrived with a very short commit history rather than the historical code that implemented the upload path. That limits outsiders’ ability to reconstruct the old behaviour directly from Git and means claims about prior retention and access still depend partly on company statements and external forensic evidence.

What to watch next

  • Publication of Z.ai’s promised full security assessment and whether it establishes the scope and retention history of successful uploads.
  • Whether Z.ai publishes older source history or other artifacts that allow independent reconstruction of the removed Repo Wiki workflow.
  • Further disclosures identifying how many users or repositories had snapshots successfully accepted by the cloud service.
  • Whether other coding-agent vendors document `.git` and repository-indexing data flows more explicitly after the incident.

Still unclear

  • The total number of affected users and successfully uploaded private repositories has not been established publicly.
  • Z.ai says uploaded data was deleted and not retained for training; the cited external checks establish current deletion state more clearly than historical access or processing.
  • The large 313MB archive documented by ferstar did not successfully leave that researcher’s machine, so it should not be described as a confirmed 313MB exfiltration.
  • The public ZCode repository reflects remediated code and does not provide a complete historical source trail for the removed implementation.

Sources

Direct reading behind this dossier.

5 sources
ZCode Releases & Updates
Z.ai primary

Current official ZCode release surface and post-remediation 3.14-series state.

ZCode source repository
Z.ai / GitHub primary

Public source for the remediated ZCode client, backend, UI and agent runtime.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment