An AI coding assistant can be useful precisely because it can see more than a chatbot. It can inspect files, understand a repository, follow Git history, run tools and keep enough context to make changes across a project. That access is also the dangerous part. This week, Z.ai's ZCode became a useful example of what happens when the boundary between local context and cloud processing is not obvious enough.
Developers reported that ZCode had created encrypted snapshots of local repositories and attempted to send them to Alibaba Cloud infrastructure. Reuters reported on September 22 that Z.ai disabled affected features and apologised after the behaviour came to light. Z.ai's own release notes for version 3.14.0, released September 19, say it fixed an issue involving abnormal uploads in the repository wiki. The company subsequently opened ZCode's source code for public inspection.
The repository is not just another attachment
Sending a source file to an AI model is easy to reason about. A developer selects a file, asks a question, and can reasonably expect that file to be part of the request. A repository-level agent is different. To build an index or architecture map, it may inspect thousands of files, metadata, configuration and version history. The useful context can quickly become a surprisingly complete copy of the project.
Reporting from The Next Web described one local snapshot discovered by a developer as roughly 313 MB and containing more than 42,000 files. Most of that snapshot was Git-related data. The archive reportedly failed to upload after hundreds of attempts, while a smaller public repository snapshot did reach the server. Those details matter because Git history can contain much more than the current state of a project. Deleted configuration, old credentials, internal URLs and code that no longer appears in the working tree can remain in history.
ZCode's current documentation describes a much narrower design for its Repo Wiki. It says the feature excludes the .git directory, dependency directories, caches and files suspected of containing secrets. It also says generated wiki output is stored locally, while selected code context is sent on demand to the configured model service. That is a substantially easier boundary for a developer to understand.
Encryption does not answer the permission question
One interesting part of this incident is that the snapshots were encrypted. Encryption is good engineering, but it does not settle the main issue. If an application copies data that a user did not knowingly authorize it to copy, encrypting the transfer protects the data in transit while leaving the consent problem untouched.
This distinction becomes increasingly important as coding assistants become agents. A normal editor mostly waits for instructions. An agent may scan, index, execute, search, create checkpoints and call remote services in the background. Each capability can be individually reasonable while the combined behaviour becomes difficult for the user to predict. A privacy toggle that sounds like it controls collection is not enough if another subsystem can still package the workspace.
The practical design requirement is therefore less glamorous than model intelligence. Agents need visible data boundaries. Developers should be able to tell what is local, what leaves the machine, which service receives it, why it is needed and how to stop it. For sensitive repositories, those controls should probably be conservative by default rather than something discovered after reading documentation.
Open source helps, but history matters too
Z.ai responded by removing the upload workflow, open-sourcing ZCode and commissioning external security assessments. The Next Web reported that the researcher who originally investigated the behaviour later confirmed the upload path was gone from the published code. That is meaningful remediation. Z.ai's current release page lists newer builds, and its documentation now describes clearer limits around what Repo Wiki reads.
There is still an awkward verification problem. The public repository reportedly arrived with very little commit history, so researchers can inspect what the application does now but have less visibility into the code that produced the earlier behaviour. This is a useful reminder that open source is not automatically the same thing as an audit trail. Publishing current code improves transparency, but preserving relevant history makes claims about past behaviour easier to verify independently.
Useful agents need boring, inspectable boundaries
The broader lesson is not that coding agents should never read repositories or use cloud services. Those capabilities are why the tools can understand large projects in the first place. The lesson is that an assistant becomes more useful by gaining access, and every new layer of access creates another trust decision that product design has to make explicit.
I find that more important than another benchmark showing that an agent can solve a larger percentage of coding tasks. A coding assistant that writes excellent code but has ambiguous rules about where the repository goes is difficult to trust with serious work. The same problem will appear in personal assistants that can read email, operate browsers, access financial accounts or control devices.
The path from chatbot to useful assistant is partly a model problem, but increasingly it is a permissions problem. The impressive part is getting an agent to understand an entire project. The harder part is making sure everyone can understand what the agent is allowed to do with it.