Grok Build CLI uploaded whole repos
A wire-level audit found Grok Build 0.2.93 sending 5.10 GiB of full git history and unredacted secrets to xAI storage versus 192 KB of real model traffic.
A researcher publishing as “cereblab” ran Grok Build CLI version 0.2.93 through a proxy and published the wire capture on July 12. On a 12 GB test repository, the model-facing channel (/v1/responses) moved about 192 KB of traffic for the coding task at hand. A separate channel (/v1/storage) moved 5.10 GiB in 73 chunks of roughly 75 MB each, a gap of about 27,800 times more data than the task needed. The destination, per bucket names and metadata visible in the capture, was a Google Cloud Storage bucket called grok-code-session-traces. A planted .env file with fake credentials, and a canary file the model was told not to read, both showed up in the uploaded archive with full commit history intact. Disabling the CLI’s “Improve the model” toggle, which governs training consent, did not stop the uploads.
The writeup hit Hacker News and The Hacker News on July 14. Elon Musk said on X the previously uploaded data would be deleted; xAI has since shipped a server-side flag that stops the uploads and added a /privacy CLI command, though the fix followed the disclosure, not the other way round.
What it means
If you point a coding agent at a real repository, the agent’s own request log is not the whole story. Check what a CLI actually sends over the wire, not just what its settings claim to control, especially anything phrased as a training toggle. Rotate any credentials that ever sat in a .env file inside a repo you ran Grok Build against. The pattern echoes the case for keeping a coding agent from running attacker-supplied code and for giving agents their own scoped keys instead of ambient repo-wide credentials: a leaked key is a leaked key, whether an attacker or the vendor’s own pipeline moved it.