xAI's Grok Build CLI Was Uploading Entire Git Repositories — Opt-Out Didn't Stop It

Grok Build is xAI's coding assistant CLI — a tool developers run directly against a local codebase to get AI help writing and reviewing code. Independent wire-level traffic analysis, published by a researcher under the handle "cereblab" and corroborated by multiple outlets since, found the tool was sending far more data off the machine than any coding task required.

On a test repository, the traffic to xAI's actual model endpoint came to roughly 192 KB — a normal size for a coding request. But a separate, undocumented channel to /v1/storage uploaded about 5.1 GB from the same session, landing in a Google Cloud Storage bucket named grok-code-session-traces. That gap of roughly 27,800 times more data than the model ever used included files the assistant had never opened, the repository's complete commit history, and the contents of .env files — meaning API keys and database passwords could leave a developer's machine even on a task that never touched them. Turning off xAI's "improve the model" data-sharing setting made no difference: the server kept confirming uploads were enabled regardless of what the toggle in the app showed. xAI pushed a server-side fix on 13 July that stopped the uploads, but did so quietly — no advisory, no changelog entry — and it only became verifiable once the researcher retested and found the storage calls had gone silent.

What this means for your business

Any business whose developers, or outside contractors, run AI coding tools against a codebase should treat this as a reminder that "reads your code" and "reads and uploads your code" are not the same claim, and vendors don't always tell you which one is true:

• Ask which AI CLI or IDE-integrated coding tools your developers and contractors currently run against client or company repositories — most teams have never inventoried this.
• If Grok Build touched a repository containing live .env secrets before 13 July 2026, treat those API keys and passwords as exposed and rotate them, even without evidence of misuse — a silent server-side fix is not the same as a confirmed no-impact finding.
• Don't treat a vendor's privacy or "don't use my data" toggle as a control you can rely on — this one visibly failed. Where possible, verify a tool's actual network behaviour, or simply keep secrets out of the repository entirely, in an environment manager or vault rather than a committed .env file.
• Extend the same question to any agency or freelancer who works inside your codebase: what AI tooling do they run, and what is it allowed to touch?

None of this is a reason to avoid AI coding tools — it's a reason to treat them like any other piece of software with repository access: least privilege, no blind trust in a settings toggle, and secrets that were never supposed to be sitting in a file in the first place.