ZCode Can Send Your Git History to Z.AI. Only Z.AI Can Prove It’s Gone

ByMax Dvornik
Editorial illustration of an encrypted source-code archive moving from a developer project toward a cloud server controlled by the service provider.

ZCode, Z.ai’s desktop coding assistant, packaged a developer’s commercial project — its working code and its Git history — into a 313MB encrypted archive and queued it for Alibaba cloud storage. The developer, who writes as Ferstar, found it sitting on his own machine on September 18, 2026. He could not open it. The key was held on Z.ai’s backend.

Z.ai said that day that it had fixed the feature, and that uploaded data is destroyed as soon as a Wiki is generated. But public reports from the same day recorded snapshots still being accepted while the setting showed as off, and no independent retest has shown the affected client stopped creating or sending them.

ZCode’s Repo Wiki documentation says a user can generate an AI-written guide to a codebase by clicking “Generate wiki.” Z.ai’s September 18 explanation said repository indexing supported Wiki generation, version rollback, and session recovery, and that the feature had been enabled by default after launch.

That makes this more than an accidentally exposed checkbox. A commercial project was prepared for cloud upload in a form its owner could not inspect, while the company receiving it controlled the means of inspection.

The 313MB encrypted repository archive

Developer Ferstar found a 313MB encrypted archive queued for Alibaba cloud storage on September 18. It was a snapshot of a commercial project, including Git history. The archive had failed to upload 564 times, while a smaller file had already been transmitted.

Git history is not just a backup of the current folder. A .git directory can retain prior commits, deleted code, abandoned branches, commit messages, local paths, and credentials that were once committed and later revoked. A current working tree tells an assistant what a project is; its history can tell it what the project used to contain. That is why historic credentials can still create security costs, even after a team believes it has removed them.

Conceptual illustration showing a clean current codebase in front of older Git commits, branches, deleted files, and credentials retained in repository history.

Ferstar said he could not decrypt the archive himself, and neither could the ZCode client. The private key sat on Z.ai’s backend. Encryption protected the archive from casual access on disk, but it also left its owner unable to determine exactly what had been packed or what happened after transmission.

Z.ai apologized in its Feishu community and said the issue had been resolved. Its account described cloud Repo Wiki generation as a route by which a repository could be uploaded, and said the data was destroyed immediately once Wiki generation finished. That is the company’s account; the source record contains no independent forensic audit of Z.ai’s storage or an independent repeat of Ferstar’s test against the fixed client.

“.git directories never reach the Wiki model context.”

, ZCode Repo Wiki documentation

That statement is narrower than it first sounds. It addresses what the Wiki model reads, not what ZCode packages into a repository snapshot or transmits before the model sees anything. The June 15 privacy policy describes text, files, and code users submit in conversations; it does not explicitly describe default uploads of packaged repository history.

Z.ai’s statement calls the episode a fixed indexing problem. The evidence makes the more important question harder to avoid: why was a feature capable of uploading a project’s past turned on by default at all?

Snapshot evidence after the claimed fix

The Ferstar case was not the only local observation. A September 18 issue in Z.ai’s public feedback repository reported that ordinary prompts and completed tasks created snapshots containing the full .git directory, including objects and reflog data. The reporter said Alibaba OSS, Alibaba’s cloud-object-storage service, had accepted uploads even though repoSnapshotIndexingEnabled was set to false.

That issue is a user report, not a completed third-party audit of Z.ai’s servers. It nevertheless conflicts with a clean story in which the switch reliably prevented uploads.

A separate record from the maintainer of community project ZCode WebUI found snapshot artifacts across 12 workspaces running ZCode renderer 3.12.3 and server runtime 3.11.2. The maintainer recorded:

  • 10 uploads confirmed by the server.
  • Two unacknowledged encrypted files totaling 177MiB.
  • Three plaintext manifests listing Git pack files of 57.6MiB, 63.9MiB, and 21.5MiB.

The reports also put this incident in a pattern that developers should recognize. GitLost’s private-repository exposure through public GitHub issues and the VS Code extension incident that exposed 3,800 repositories involved different systems and mechanisms, but the same practical failure: development tools are trusted with source trees before users have a clear picture of where those trees travel.



What Z.ai alone can verify about deletion

The core problem is not whether Z.ai said it destroyed uploaded archives. It is that the system described by Ferstar meant the user could not check.

Z.ai’s backend held the private key needed to decrypt the archive. Z.ai also made the claim that uploaded data was immediately destroyed after Wiki generation. Only Z.ai could inspect the contents of the archive and only Z.ai could substantiate its deletion.

That is an accountability design problem, not merely a privacy-policy wording dispute. A company can make a legitimate case for encrypting cloud-bound developer data. But if its implementation prevents the developer from reading the archive, retrieving it, auditing it, or verifying its removal, then “we deleted it” becomes a statement the customer must accept on faith.

The record does not establish that Z.ai retained Ferstar’s archive. It establishes something more concrete: the archive was made unreadable to its owner, and Z.ai alone possessed the key and the server-side record that could settle what happened to it.

The fix worth measuring is therefore not a community post or a setting label. It is whether a clean client installation can still create a repository-history snapshot, whether it can transmit one without an explicit user action, and whether the person whose code was packaged can independently see what left their machine.

Key Takeaways

  • Z.ai said on September 18, 2026 that it had resolved ZCode’s repository-indexing upload issue.
  • Ferstar found a 313MB encrypted archive of a commercial project and its Git history queued for Alibaba cloud storage.
  • The archive had failed to upload 564 times, while a smaller file had already been sent.
  • Public reports recorded accepted repository snapshots even when repoSnapshotIndexingEnabled appeared set to false.
  • Z.ai’s backend held the private key needed to inspect Ferstar’s archive, leaving Z.ai alone able to verify its deletion claim.

Further Reading