The Assistant Read the File You Told It Never to Open

When you invite a coding assistant into your project, it uploads more than the code you're working on. A wire-level capture of xAI's Grok Build CLI shows the tool shipping a developer's entire repository and its full git history to xAI's cloud — including a file explicitly marked never-to-read, and including secrets long since deleted but still preserved in commit history. The opt-out toggle governs only whether your code trains the model, not whether it leaves your machine. That gap between what "opt out" sounds like and what it actually does is the whole story.

A git repository is not a folder. It's a diary.

Everyone who has worked in one for long enough knows this in their bones, even if they've never said it out loud. The repo holds the feature you shipped, yes — but it also holds the three ways you tried to build it before the fourth one worked. It holds the variable you named something crude at 2 a.m. and renamed the next morning. It holds the commit where you pasted an API key straight into the config because you were in a hurry, and the commit an hour later where you took it out again, heart pounding, telling yourself you'd caught it in time. All of it is still there. Git doesn't forget. That's the point of git. The history is the whole value proposition — a perfect, unbroken memory of every decision, including the ones you'd take back.

Which is why a detail from a recent researcher's capture of xAI's Grok Build CLI lands the way it does. According to the wire-level trace, the tool doesn't just read the files it needs to help you. It uploads the entire repository, plus the full git history, to xAI's cloud — a separate act from whatever the assistant actually reasons over. A file the researcher had explicitly marked as never-to-read was recovered from the upload anyway. The deny rules that are supposed to protect a file block the assistant from *reading* it. They do nothing to stop the whole repo from being copied off the machine in the first place.

What does it actually cost when your git history leaves your machine?

Sit with the git-history part, because that's where the abstract becomes personal.

Every working developer has committed something they shouldn't have and then quietly removed it. A password. A token. A client's real name in a test fixture. The removal feels like an eraser. It is not. The secret lives on in the earlier commit, in the history, permanently, and the standard advice — rotate the key, rewrite history, hope — exists precisely because deletion doesn't delete. So when a tool exfiltrates full git history by default, it is not reaching for your current code. It is reaching for the exact mistakes you tried hardest to make disappear. The most private thing in the repository is not the code you're proud of. It's the code you're ashamed of, sitting in a commit from 2023 that you assumed no one would ever look at again. The [step-by-step account of what the packet capture actually recovered](/posts/researchers-grok-build-cli-ships-your-entire-repo-and-git-history-to-xai-cloud-d/) spells out how far past the current working tree the upload reaches.

I want to be fair about what we know, because the temperature on this kind of story runs hot. This is one researcher's capture of one version — v0.2.93, from July 2026. xAI has not responded. I'm not going to tell you what anyone at the company intended, because I don't know, and intent is the wrong thing to chase anyway. A default is not a motive. But a default is a message. It tells you, more honestly than any privacy policy, how a company pictures the person on the other end of the software — what it assumes you'll notice, what it assumes you'll accept, how much of you it treats as fair to take before it bothers to ask.

Is this really a betrayal — or just the usual privacy-for-convenience trade?

Here's where I have to argue with myself, because there are three true things and they don't fully agree.

The first true thing: this is a serious breach of trust, and it should be named as one. The relationship between a developer and their tools has always rested on a quiet assumption — my machine is mine. The editor doesn't phone home with my drafts. The compiler doesn't keep a copy. That assumption is load-bearing. It's what lets you experiment, fail, be sloppy in private, keep a junk drawer of half-ideas. A tool that silently ships all of it to someone else's cloud doesn't just leak data. It repossesses the private workshop and turns it into a room with a window you can't see.

The second true thing, and it complicates the first: we have been making this trade for twenty years and mostly enjoying it. Your email lives on someone's server. Your photos sync to a cloud you'll never audit. Your phone knows where you slept. We traded privacy for convenience so many times that outrage over any single instance starts to feel selective, even a little precious. Grok Build isn't inventing the bargain. It's applying the same bargain we already accepted everywhere else to the one place — the codebase — that a certain kind of person still thought of as sacred. Maybe the honest discomfort here is just watching the last room get colonized, and realizing we never actually defended the others.

The third true thing is the one I keep landing on. The deepest failure isn't the upload. It's that "opt out" has quietly come to mean almost nothing, and we let it. The toggle in Grok Build governs training consent — whether your code teaches the model — and a reasonable person clicks it and exhales, believing they've kept their code home. They haven't. The code still leaves. Two entirely different questions — *will you learn from my work* and *will my work leave my computer* — have been folded into a single switch that answers only the first while implying it answers both. That's not a lie. It's worse than a lie, in a way, because it's technically defensible. It just isn't consent. Consent requires that the person saying yes understands what they're saying yes to, and almost no one does.

What we lose that isn't in the data

The real cost doesn't show up in a breach report. It shows up in what people stop doing.

Trust is infrastructure. When a developer no longer believes the workshop is private, the first casualty is experimentation — the willingness to write the ugly, wrong, embarrassing first draft that every good thing starts as. You don't paste the risky idea if you assume it's being copied. You don't commit the messy prototype if the mess is going somewhere you can't see. And notice the asymmetry, because it's the whole injustice in miniature: the solo developer ships their entire private history to a company's cloud, while the company reveals nothing about what it keeps, for how long, or who can reach it. One side is fully legible. The other is opaque. That imbalance is exactly the thing we used to build institutions to correct, and we haven't built anything for this yet.

If you want the cooler-headed version of why that toggle misleads — laid out as a signal-versus-noise autopsy rather than a lament — the [skeptic's dissection of exactly what the opt-out controls](/posts/grok-s-cli-ships-your-whole-repo-the-opt-out-toggle-governs-something-else/) is the piece I'd hand a colleague who thinks I'm being dramatic.

Which is the part that unsettles me most. Agentic tools are asking for a scale of trust we have no norms for. We know, roughly, how to think about an app that reads our contacts — we've had twenty years of that argument. We have no equivalent instinct for an assistant we deliberately invite into the most intimate record of our labor, an assistant that can act, copy, and transmit, and that arrives before anyone has agreed on what it's allowed to take. The tools are moving faster than our sense of what's ours.

I don't think the answer is to refuse them. I use these tools. They're genuinely good, and pretending otherwise is its own kind of dishonesty. But I think we're owed a much smaller, much harder thing than a boycott: the truth about what leaves the room. Tell me plainly that the whole repository goes, history and all, the deleted secrets and the abandoned ideas and the 2 a.m. variable names. Let me decide with my eyes open. The problem was never that a machine read a file. The problem is that it read the file I told it never to open, and called that consent.

FAQ

Does opting out of training in Grok Build keep my code on my machine?

No. In the captured version of xAI's Grok Build CLI, the opt-out toggle governs only training consent — whether your code is used to improve the model. It does not stop the tool from uploading your repository and git history to xAI's cloud. Those are two separate questions folded into one switch.

Why is uploading git history worse than uploading current code?

Because git history preserves everything you ever committed, including secrets you later deleted. Developers routinely commit a password or API key, then remove it and assume it's gone — but it survives in the commit history permanently. Shipping full history means shipping the exact mistakes people tried hardest to erase.

Can I prevent files from being uploaded?

Per the researcher's capture, deny rules only block the assistant from reading a file, not from uploading the whole repository. Only `.gitignore` reliably keeps a file out of the upload — and anything already recorded in git history ships regardless, because it's already part of the repo's permanent record.