Before You Give an AI Tool the Keys to Your Repo

Key takeaways

• Deleting a committed file does not necessarily remove its contents from Git history.
• A “repository snapshot” does not automatically include past commits.
• Uploading code, retaining it, and using it for model training are separate questions.
• An opt-out setting does not establish what users understood before the first upload.

The file you deleted last month may still be sitting in your repository’s history. Allegations that Zhipu’s ZCode uploaded Git history put that distinction under scrutiny, though whether those uploads occurred, what they contained, and how users were informed remain unresolved. For anyone connecting an AI coding tool to a project, the practical question is straightforward: how much of the project are you sharing?

Deleted from the folder, preserved in Git

Git records changes in commits so developers can inspect earlier versions or restore them. Remembering old code is part of the job.

Suppose your team committed an experimental feature last month, then scrapped it. You delete the files and commit that change. The feature disappears from your working folder, but an earlier commit can still contain the whole thing.

That includes any internal architecture notes or confidential customer names embedded in the code. Cleaning up the current version does not necessarily clean up the record.

Deleting a file and removing it from Git history are different operations. An AI tool that reads only current files has access to a different set of information than one that also reads past commits.

The editor window is not a complete inventory of what the repository remembers.

“Snapshot” leaves a lot unsaid

A repository snapshot sounds like a copy taken at a particular moment. It does not tell you exactly what went into the package.

It could contain the current working files. It could contain the file contents from a single commit. If it also includes Git’s internal data, it may contain material from earlier commits still present locally.

Those possibilities have different privacy implications. A snapshot upload alone does not prove that deleted code—or the repository’s entire history—was transmitted.

The ZCode allegations require the same distinctions. Evidence that an upload happened would not, by itself, establish that it included Git history. Evidence that history was included would not establish what users were told beforehand.

Each claim needs its own support. “Repository snapshot” cannot do all that evidentiary work.

An off switch answers only one question

An opt-out lets users disable something that is enabled by default. Its existence does not establish whether users knew about the collection before the first transfer.

Useful disclosure should explain what gets sent, when transfers begin, and where the data is retained. If past commits are included, that deserves an explicit explanation: historical code can contain information absent from the current project.

Three questions need separate answers:

• Transfer: What code leaves the machine?
• Retention: What does the server keep, and for how long?
• Training: Is the code used to train models?

An upload does not prove training use. A promise to exclude code from training does not mean the server never stores it.

The same distinction applies after opting out. Stopping future uploads and deleting previously uploaded material are separate actions. A claim that users have control becomes meaningful only when the boundaries of that control are clear.

Check what “project access” actually covers

Before connecting a tool, establish whether it handles selected snippets, the current project files, or Git history as well. Those are materially different permissions, even if the interface presents them under one friendly button.

Do not assume .gitignore settles the issue. It tells Git which untracked files to ignore; it is not a universal rule that every AI tool follows when sending data elsewhere. Adding a rule also does not erase content from earlier commits.

For work repositories, compare the tool’s documented behavior and actual operation with your organization’s rules for sending code outside its systems. A setting called “Privacy” tells you less than a concrete explanation of how it treats files and commit history.

Answer quality matters. So does knowing what you are sharing before you connect a project.

Git’s memory is useful precisely because it preserves what today’s files no longer show. Giving an AI tool access to that memory should be a choice you understand before the data leaves your machine.