Coding assistants are often invited into the most sensitive parts of a developer’s work: local files, source code, repositories, notes, and command-line tools. That access can make them useful. It also means that any unexpected data movement can quickly become a test of trust. Z.ai is facing that test after developers reported that its ZCode assistant uploaded encrypted workspace-related data to external storage without explicit user consent.
The central account came from a South China Morning Post report. It said an independent Chinese technical blogger known as Ferstar found a 313-megabyte encrypted archive pending upload after 564 failed attempts, as well as a smaller 15-kilobyte file that had successfully been sent. The larger archive was described, based on visible file names, as a snapshot of a commercial project that included Git history.
The reporting does not establish that Z.ai stole code, used data for model training, or committed a legal violation. It does establish a serious reported gap between users’ expectations and the product behavior they observed. Z.ai apologized, said a repository-indexing and Repo Wiki feature caused the behavior, and said it had fixed the issue. Those are company statements, and the scope and effectiveness of the patch have not been independently verified.
The reported files were encrypted, which limits outside verification
The details that made the incident resonant are also the details that remain difficult to audit from the outside. SCMP reported that the files Ferstar identified were encrypted. He said the larger archive could not be opened either by him or by the ZCode client because the relevant private key was held on Z.ai’s back end. The Next Web highlighted the same limitation in its coverage.
According to SCMP, visible filenames led Ferstar to describe the larger archive as a snapshot of a commercial project, including its Git history. The News International reported that the archive represented 42,411 files. Those descriptions should remain attributed to the investigator and reporting. The archive was not publicly decrypted for independent examination in the sources reviewed.
That distinction is not a technicality. It means the public record supports a reported upload path and a reported file footprint, but not a complete independent inventory of what the company could read, retain, or use. It also means that claims about credentials, training data, commercial exploitation, or the full repository content would go beyond what the available evidence establishes.
The broader lesson is that privacy questions in coding tools are often about defaults as much as permissions. Developers may accept cloud processing when they understand what is being sent and why. They react differently when a background process appears to package repository material without a clear, prominent consent step. In this case, The News reported Ferstar’s account that the feature was enabled automatically and had no user-facing switch to turn it off. That remains a reported reverse-engineering finding, not a completed independent security audit.
The episode has particular relevance for a company also known as Zhipu AI. EastFrontier previously covered Zhipu AI’s open-sourcing of GLM-5.2 in response to U.S. model-export restrictions. Open-model strategy can build developer confidence, but trust in a coding tool also depends on practical questions about local data handling, consent, and the ability to verify a vendor’s claims.
Z.ai’s explanation centers on Repo Wiki and indexing
In a company response reproduced on the V2EX forum and reported by other outlets, Z.ai attributed the behavior to repository indexing and its Repo Wiki feature. The company said the process supported session checkpoint recovery, historical-version rollback, and the generation of a repository wiki. It said that creating a Repo Wiki through its cloud service could cause a copy of repository data to be sent outward.
Z.ai also said the relevant data was destroyed immediately after the wiki page was generated. That is a company claim, not a conclusion outsiders can independently confirm. The encryption issue makes that qualification particularly important: if a company controls the decryption key, users cannot easily verify either the full contents of the archive or the claimed deletion.
The company said the Repo Wiki path had been enabled by default during the period after launch. That explanation is different from an independent conclusion that all uploads were expected, properly disclosed, or acceptable to users. Product terms can provide context, but they do not settle the dispute. ZCode’s terms say the service collects material users actively provide, including code, file contents or summaries, attachments, logs, and tool results. The terms alone do not establish that a repository snapshot was authorized or that users understood the relevant feature’s behavior.
An official ZCode changelog offers a limited but important product record. Version 3.14.0, released September 19, lists a fix for abnormal uploads in the repository wiki. That confirms that the company issued a release-note fix concerning repository-wiki uploads. It does not independently demonstrate that the reported behavior was fully resolved, that all possible upload paths were eliminated, or that a security review had been completed.
The incident fits a wider discussion of how China’s AI developers manage cybersecurity and user confidence. EastFrontier has written about the country’s effort to close an AI cybersecurity gap. The ZCode episode makes that debate concrete: for an AI coding assistant, users need more than a generic assurance that data is handled responsibly. They need clear defaults, visible controls, understandable architecture, and credible verification.
Promises of openness will matter only when they are delivered
Z.ai’s response included commitments intended to restore confidence. The company said it would open-source ZCode’s codebase in the near term, invite third parties to assess system operation, and disclose review progress. It also said users would receive one additional weekly quota reset.
None of those commitments should be described as finished. At the time of research, no public ZCode source release or completed third-party audit had been established. An offer to open source a product can give security researchers a clearer view of how it works, but only once the code, build process, data paths, and relevant configuration are actually available for scrutiny.
The company’s apology and patch are meaningful first responses, but a trust repair process is longer. The questions now are whether Z.ai will identify the precise versions affected, explain the default behavior in technical detail, provide a setting that users can understand and control, publish the promised code, and allow independent assessors to test the fix.
For users of AI coding tools, the immediate conclusion should be disciplined rather than sensational. The available reports support the statement that developers found encrypted repository-related data being uploaded without explicit consent and that Z.ai said a default-on Repo Wiki and indexing feature was responsible. They do not support claims of code theft, malicious intent, training use, or confirmed deletion.
That uncertainty does not make the incident trivial. In developer software, unexpected data transfer can itself damage confidence, especially when the data is encrypted in a way users cannot inspect. Z.ai now has an opportunity to move from a reactive statement to a verifiable response. Its promised transparency measures will determine whether this becomes a short-lived product incident or a lasting warning about how AI coding assistants earn, and lose, developer trust.