AI coding tool data privacy: ZCode uploaded a whole Git history

A developer clearing disk space found a 313MB encrypted file in the data folder of ZCode, the desktop coding agent from Chinese AI company Z.ai. It turned out to be most of a commercial project — including its full Git history — packaged for upload to cloud storage, encrypted to a key only the vendor holds. The report is a sharp reminder that AI coding tool data privacy is decided by what the software actually does on the developer's machine, not by what the privacy page says.

What the researcher found

In a detailed reverse-engineering write-up published on 18 September, the developer, who goes by ferstar, describes finding a 313MB archive in ZCode's local data directory, with metadata recording 564 failed upload attempts. By unpacking the application, they reconstructed the flow:

• While the user is logged in, the client packages the workspace — excluding folders such as node_modules but including the complete .git history, Git LFS cache and app configuration.
• It requests upload credentials from Z.ai's server, which returns storage form credentials and an RSA public key.
• It encrypts the archive with AES-256, wraps that key with the server's RSA key, and posts the file directly to Alibaba Cloud object storage.

Because the private key is held on the server, neither the user nor the ZCode client can decrypt the archive sitting on the user's own disk. The researcher reports that the "Optimize Experience" setting governs whether data is used for model training, not whether the upload happens, and that they found no mention of whole-workspace uploads in the privacy policy, FAQ or changelog.

RuntimeWire's account adds the payload breakdown: 42,411 files in a 345.5MB workspace, with the .git directory making up 86.6% of the archive. It also makes the important caveat: the test establishes the behaviour of one installation, not how widely the mechanism was deployed across versions, accounts or regions.

Why the Git history matters most

A working directory shows today's code. A Git object store holds everything the repository has ever contained. As RuntimeWire notes, that can include deleted credentials, old configuration files, unpushed branches, internal hostnames and unreleased work. A secret removed from the code two years ago is still in the history unless someone rewrote it. So a snapshot of .git is not a copy of the product; it is a copy of its whole lineage.

Is it safe to use AI coding tools on proprietary code?

It can be, but only with tools whose data handling you have verified. Coding agents need broad access to a repository to be useful — that is exactly why they are powerful — and it is also why the desktop client, and who holds its keys, sit at the centre of the trust question. This is not a question about one vendor or one country. Any tool with repository access and a network connection can send more than it needs to.

For companies that write their own software, the practical questions are:

1. Which AI tools are installed? Developers adopt tools quickly. An inventory of what runs on machines with access to your repositories is the starting point.
2. What leaves the machine? Prompts and context snippets are expected. Whole-workspace or history uploads are not, and should be ruled out contractually and checked technically.
3. Where does it go, and who can read it? Region, storage provider, encryption, and whether the vendor holds the keys.
4. What is the retention and training policy? And does a setting actually control the behaviour, or only the use of the data after it arrives?
5. Can you see it? Egress monitoring on developer machines and build agents turns a policy into something you can verify.

Questions to ask a software vendor about AI tools

If an agency or outsourcing partner builds software for you, their tools touch your code too. Add these to your vendor due diligence, alongside the usual questions in our guide to choosing a software development partner:

• Which AI coding tools do your developers use on our code, and under which account type — consumer or business?
• Do those tools retain our code, use it for training, or upload repository history?
• How do you prevent secrets from reaching AI tools, and do you scan history for secrets before granting access?
• Can you provide the vendors' data processing terms?
• Will you tell us before adopting a new tool that touches our repositories?

A good partner will answer quickly, because they will have had to answer the same questions for themselves. We covered what else to ask in what CTOs should look for in a development partner.

AI coding tool data privacy controls that work

• Clean the history before exposure. Run secret scanning across full Git history, rotate anything found, and rewrite history where necessary.
• Use business tiers with contractual limits. Most major vendors offer data-retention and training commitments on business plans that consumer accounts lack.
• Restrict network egress. Allowlist the endpoints each approved tool needs on developer machines and CI runners; the same allowlist principle we recommend for agent sandboxes.
• Watch local data folders. Large, unexplained files in a tool's data directory are how this case was found.
• Keep credentials out of repositories. The best defence against a leaked history is a history with nothing worth stealing. The GitHub Actions secrets case showed the same lesson from another angle.

AI coding tools are now part of how software gets built, including by us. The answer is not to ban them but to treat them like any other supplier with access to your most valuable asset. If you want an independent review of how AI tools touch your codebase — yours or your vendor's — our custom software development team can help set the policy and the controls.