GLM-Based Coding Assistant ZCode Accused of Silently Uploading Users' Git History

A security concern surrounding the AI coding assistant ZCode recently sparked discussion on Hacker News. According to reports, this GLM-based programming agent silently uploads users' local Git history to remote servers without their knowledge or consent. The post quickly accumulated 87 upvotes and dozens of comments, reflecting the developer community's heightened sensitivity around data privacy in AI coding tools.

Incident Overview

ZCode is positioned as a coding agent powered by the GLM model, focused on using large language models to assist with code comprehension, generation, and refactoring. Its core selling point is the ability to read project context and deliver intelligent suggestions that are tailored to the actual codebase.

The problem lies precisely in this "reading context" mechanism. Reports indicate that while running, ZCode uploads users' local Git history to remote servers — and by default, this happens without any clear notification or user consent. This is what's being called "silent uploading."

For developers, Git history is far more than just code. It can contain internal discussions embedded in commit messages, sensitive configurations from rolled-back commits, credentials that were accidentally committed and later deleted, as well as a complete development timeline and contributor information. Once this data leaves the local environment, the potential for exposure grows significantly.

Why Git History Leaks Are Serious

The sensitivity of Git history is frequently underestimated. Many developers assume that removing a .env file or deleting a secret key from the latest commit is sufficient — but Git's version tracking means that historical commits may still contain that information in full.

Once a coding agent packages and uploads the complete history, several categories of risk emerge:

• Credential and secret key exposure: Residual API keys, database passwords, and private certificates from past commits may be uploaded along with everything else.
• Internal information disclosure: Commit messages often contain internal project codenames, issue descriptions, architectural decisions, and other non-public content.
• Intellectual property leakage: For closed-source commercial projects, a complete development history is essentially handing core IP over to a third-party server.
• Compliance violations: In contexts governed by regulations like GDPR, uploading data without consent may constitute a direct violation.

For enterprise developers, this kind of data leakage may also violate internal security policies and non-disclosure agreements.

From a technical perspective, the full history of a Git repository is often far larger than developers intuitively expect. A mid-sized project that has been evolving for several years may have tens of thousands of commits, hundreds of branches and tags, and complete content snapshots of every "deleted" file in its .git directory. Git's object storage mechanism stores every historical version as a blob object using content-addressed storage — meaning that even if a file no longer exists in the latest commit, its historical versions remain fully intact under .git/objects and can be recovered using commands like git log --all or git fsck. An attacker or data collector who gains access to the complete .git directory can reconstruct the entire history of the project, not just the current code snapshot. For this reason, the industry typically treats the .git directory with the same level of protection as source code itself — and in web server configuration audits, preventing exposure of the /.git/ path is a standard security check.

AI Coding Tools: "Context" vs. Privacy Boundaries

This incident highlights a structural tension that AI coding agents broadly face: the more capable the model, the more context it needs — and the richer the context, the greater the likelihood it will touch sensitive user data.

To provide intelligent suggestions that truly "understand your project," an agent needs to read code, directory structures, and even commit history. This is technically reasonable. But the critical issue is the right to be informed and the right to choose. Do users know which data is being collected? Is it being uploaded? Where does it go? Can it be turned off?

The word "silently" is what triggered widespread outrage — because it bypasses user informed consent. The ideal approach should be: minimize data collection by default, clearly notify users whenever data leaves the local environment, provide configurable privacy controls, and document the data handling process transparently.

Practical Advice for Developers

Until AI coding tools broadly adopt transparent data standards, developers should take proactive steps to protect themselves.

Audit a Tool's Data Behavior

Before installing any AI coding agent, read its privacy policy and data handling documentation. If possible, use a network packet analyzer (such as Wireshark or mitmproxy) to observe the tool's actual network requests and confirm whether any unexpected data uploads are occurring.

Network traffic analysis is the most direct method for verifying a tool's actual data behavior. mitmproxy is an open-source proxy tool that supports HTTPS man-in-the-middle decryption. By configuring it as a system proxy before launching the target AI tool, you can capture and decrypt all outbound HTTPS requests, clearly seeing destination domains, request body contents, and upload data volumes. For clients that use certificate pinning, interception is more difficult — but most desktop developer tools don't enable this mechanism. A lighter-weight alternative is to use an application-level firewall like Little Snitch on macOS or OpenSnitch on Linux. These tools let you observe which domains a tool connects to without decrypting the content, and you can set rules to block suspicious outbound connections. In enterprise environments, DNS logs or traffic analysis appliances at the network perimeter can be used to centrally monitor AI tools' network behavior.

Clean Sensitive Data from Git History

For repositories that genuinely need to be processed by third-party tools, use utilities like git filter-repo to scrub sensitive information from the history — or run AI tools on an isolated clone of the repository.

Prioritize Local Deployment Options

For high-security environments, consider model solutions that support local deployment, keeping context processing within the local environment and fundamentally eliminating the risk of data leaving your system.

Isolate Sensitive Projects

Projects involving trade secrets or regulated data should be carefully evaluated before connecting them to cloud-based AI tools. Where necessary, use network policies to restrict the tool's ability to make external connections.

Conclusion

The information available about the ZCode incident on Hacker News is limited, but the issues it raises are universal. As AI coding agents rapidly proliferate, data privacy and informed consent are becoming key benchmarks for determining whether a tool is trustworthy. Tool vendors need to recognize that transparent data handling isn't optional — it's the baseline for earning developer trust. And as users, while we embrace the productivity gains that AI brings, we should maintain a clear-eyed awareness of where the boundaries of our data lie.