Grok's Coding CLI Quietly Uploads Your Whole Repo. Here's the 3-Minute Audit to Run.

The short version

xAI’s Grok Build CLI (v0.2.93) doesn’t just read the files you point it at. Researchers captured it uploading your entire repository, including full git history, to xAI’s cloud in the background. The “improve the model” toggle everyone assumes is a privacy switch only controls training. It does not stop the upload. If you’ve ever committed a secret to a repo and later deleted the line, that secret is still in your git history, and it ships anyway.

What did researchers actually find?

A public, reproducible wire-level capture of Grok Build CLI version 0.2.93, dated July 2026, shows the tool packaging your whole project as a git bundle and sending it to xAI cloud storage. A git bundle is a snapshot of the repository including its full commit history, not just the current files on disk. So this is not the model quietly reading a config file. This is a separate, background upload of the entire project, and it’s much bigger than anything the AI needs to answer your prompt.

The number that made me sit up: the researchers measured roughly 27,800 times more data leaving the machine than the model actually needed to do the work. That’s the gap between “the AI read three files to help you” and “your entire codebase and its history are now sitting on someone else’s server.” Those are very different privacy stories, and only one of them is the one most people think they signed up for.

Two details make it worse. First, a file the user had explicitly told the tool never to read was still recovered from the upload. The “deny” rule worked for chat and did nothing for the bundle. Second, secrets sitting in a .env file showed up verbatim in the uploaded data. Not hashed, not redacted, just there.

I want to be fair about the limits here. This is one version, one capture, and xAI hasn’t commented publicly. The harness is public and reproducible, which is the good kind of security research, but it’s still a single tool at a single point in time. Treat the specific finding as “confirmed for v0.2.93” and the lesson as “true for basically every cloud coding agent.”

Why doesn’t the privacy toggle stop it?

This is the part that actually bothers me, more than the upload itself.

Most people find the “help improve the model” setting, flip it off, and reasonably assume they’ve told the tool to keep their code to itself. What that toggle actually controls is whether xAI trains on your data. It does not control whether your data gets uploaded in the first place. Your repo still goes up. The toggle just governs what they’re allowed to do with it once it’s there.

That’s a meaningful distinction that the interface does not make obvious. “Don’t train on my data” and “don’t upload my data” are two completely different promises, and the toggle only makes the first one. A reasonable person reads the switch and assumes the second. That gap between what the control implies and what it does is the real story, not the mere fact that a cloud tool uses the cloud.

The “deny” rules have the same problem in a different costume. When you tell Grok to never read a specific file, you’re stopping it from pulling that file into the chat context. You are not stopping the whole-repo bundle from scooping it up. The only thing that reliably keeps a file out of the upload is .gitignore, because the bundle is built from git.

What’s the sneaky part about git history?

Here’s the trap, and it catches careful people.

Say three months ago you hardcoded an API key, committed it, then realized your mistake and deleted the line in the next commit. Your current files are clean. You’d pass any glance at your working directory. But git never forgot. That key still lives in your commit history, and because the upload is a git bundle that includes full history, the deleted-but-committed secret ships right along with everything else.

So “I removed that secret” is not the same as “that secret is gone.” If it was ever committed, it’s in history, and history is what gets uploaded. This is why the audit below scans history, not just the files sitting in front of you.

Is this a dealbreaker, or a “know what you’re pointing it at” thing?

My honest take: it’s not a dealbreaker, but it is a wake-up call, and the toggle behavior deserves a real fix.

Here’s the other side, stated fairly. Plenty of cloud coding tools upload a lot of context. That’s how they work. Sending the repo to the cloud isn’t automatically scandalous. If Grok Build CLI clearly said “we upload your full repo including git history to run this,” a lot of developers would shrug and keep going, because they’re already comfortable with cloud tooling. The problem isn’t the cloud. The problem is the undisclosed scope plus a privacy switch that most people will read as protection it doesn’t provide.

So I’m not telling you to uninstall anything. I’m telling you to change your mental model. Assume that whatever you point an agentic coding tool at can leave your machine in full. Once that’s your default, the specific tool matters a lot less, and this whole class of surprises stops being able to hurt you.

What’s the 3-minute audit I can run right now?

This works for Grok Build CLI, Cursor, Claude Code, or any agent that touches your repo. None of it is preachy and all of it is doable in a few minutes.

1. Assume the whole repo can leave. Adopt one rule: never point an agentic coding tool at a repo that contains real secrets or client data. If that’s your baseline, everything else is a safety net rather than your only defense.

2. Read what the privacy toggle actually covers, not what it implies. Find the setting, then find the sentence that says what it does. If it says “training,” it means training, not upload. If you can’t find a clear statement that uploads are limited, assume they aren’t.

3. Scan your git history, not just your current files. Run a secret scanner across the whole history. gitleaks, trufflehog, and git-secrets all do this. A quick start: gitleaks detect --source . --log-opts="--all" will walk every commit, not just HEAD. This is the step almost everyone skips, and it’s the one that catches the deleted-but-committed keys.

4. Rotate anything that was ever committed. If the scan turns up a key, token, or password that ever lived in a commit, rotate it. Don’t just delete it. A secret that has been in git history is a secret that has potentially already left the building.

5. Use a scratch repo to try new tools. When you want to test an unfamiliar agent, spin up a throwaway repo with dummy code and no real credentials. Let the tool do whatever it does there. You learn how it behaves before you ever expose anything that matters.

That’s it. Steps 1, 2, and 5 are habits. Steps 3 and 4 are the literal three minutes, and they’re worth doing today whether or not you’ve ever touched Grok.

If you’d rather see the proof before you run the audit, one developer’s step-by-step mitmproxy reproduction of the whole-repo upload shows exactly how the bundle leaves the machine.

The bigger point is that this is good hygiene no matter which tool spooked you. The Grok finding is a specific, reproducible example, but the fix isn’t Grok-specific, and that’s what makes it worth acting on this week instead of filing under “concerning.” If you just want the plain, unhurried summary of the finding, the straight news report on what the researchers documented is the place to start.

FAQ

Does turning off “improve the model” stop Grok from uploading my repo? No. Based on the v0.2.93 capture, that toggle controls whether xAI trains on your data, not whether your data gets uploaded. The repo upload happens regardless of the setting.

Will a .gitignore entry keep a file out of the upload? Yes, .gitignore is the reliable way to keep a file out, because the upload is built as a git bundle. A “deny” rule only stops the AI from reading a file into chat. It does not keep the file out of the bundle.

I deleted a secret from my code months ago. Am I safe? Not necessarily. If that secret was ever committed, it still lives in your git history, and the upload includes full history. Scan your history with gitleaks or trufflehog and rotate anything you find.

Is this proven, or just a claim? It’s a public, reproducible wire-level capture of Grok Build CLI v0.2.93 from July 2026. It’s one version and one capture, and xAI hasn’t commented. Treat the specific numbers as version-specific and the lesson as broadly true for cloud coding agents.

Should I stop using agentic coding tools? No. The practical move is to change your default: assume the whole repo can leave your machine, keep real secrets out of any repo you point a tool at, and use a scratch repo to test anything new.