xAI's Grok Build CLI Was Uploading Your Repo. Here's the Fix

If you've been running xAI's Grok Build CLI against a private repo this month, there's a decent chance a full copy of that repo, history and all, is sitting in a Google Cloud Storage bucket you never agreed to send it to.

That's not speculation. A wire-level analysis published this week by Developers Digest captured the actual network traffic from a Grok Build CLI session (version 0.2.93) and found the tool bundling the entire tracked Git history and shipping it to a bucket named grok-code-session-traces. That happens independent of which files the coding agent actually opened during the session. The upload happened whether or not it was relevant to the task. The researchers measured the volume: the storage channel moved roughly 27,800 times more data than what the model itself needed to do its job.

The test that makes this hard to wave away is the canary trick. The team planted a .env file containing API_KEY=CANARY7F3A9-SECRET-should-not-leave and a separate file at src/_probe/never_read_canary.txt that the agent was explicitly instructed never to open. Both showed up verbatim in the captured upload. Cloning the bundle that got shipped to Google Cloud reconstructed the "never read" file with its unique marker intact. The agent didn't need to read it, and the CLI sent it anyway.

Here's the part that turns this from a bug into a trust problem. Grok Build ships with a toggle labeled "Improve the model." Most developers who've used any AI coding tool will read that the way they've read the same toggle everywhere else: off means my code doesn't leave my machine for training purposes. Developers Digest disabled it and checked the server response. It still came back with trace_upload_enabled: true. The repo upload kept happening. The setting you'd reasonably expect to control this didn't touch it.

xAI hasn't published an advisory about any of this. What happened instead was quieter. A server-side fix went out without an announcement, and the company's X account, posting as @SpaceXAI since the July 6 rebrand, responded directly to the reporting. Their statement: teams using zero data retention have no code or trace data retained, all API key use through Grok Build respects ZDR, and if ZDR isn't enabled, there's a /privacy command inside the CLI that disables data collection at the session level.

That last part is the actionable bit, so here's what to actually do about it.

If you're on a Grok Build enterprise plan, confirm zero data retention is turned on for your organization before you point the CLI at anything you wouldn't want stored elsewhere. Don't assume it's the default. Verify it in your account settings.

If you're using Grok Build as an individual developer without an enterprise ZDR agreement, open the CLI and run /privacy. Based on xAI's own description, this disables data retention at the session level going forward. It won't retroactively delete whatever already went up from earlier sessions, and there's no indication from xAI about how long that data has been sitting in grok-code-session-traces or whether it's been deleted.

If you've already run Grok Build against something sensitive (client code under NDA, unreleased product work, anything with real credentials in it, even test ones you forgot to rotate), the honest answer is that you don't currently have a way to confirm what's still stored or to force its deletion. That's worth sitting with before you decide whether to keep using the tool the same way.

This isn't the first time a Grok product has drawn security scrutiny this year. The NSA flagged risk concerns before the Pentagon signed on anyway, and xAI's own Connectors feature already asks for broad access to Gmail, Notion, and GitHub. A coding tool that silently ships your entire repository regardless of a privacy toggle fits a pattern more than it breaks one. See how that risk assessment played out in our coverage of Grok's Pentagon deployment.

None of this means Grok Build is unusable. It means treat the "Improve the model" toggle as decorative until xAI says otherwise, run /privacy if you're not on enterprise ZDR, and think twice before running any AI coding CLI, this one included, against a repo you can't afford to have leave your machine.

Sources: Developers Digest wire-level analysis, Glitchwire report on the silent fix, @SpaceXAI's response on X.