Grok Build v0.2.93 uploaded whole repos to xAI's bucket

xAI’s Grok Build coding CLI was uploading full git repositories — every tracked file plus complete commit history — to a Google Cloud Storage bucket named grok-code-session-traces, whether or not the current task needed those files. The finding, published July 14 by The Hacker News, came from a researcher going by cereblab and applied to version 0.2.93. xAI switched the server-side upload flag off on July 13 after being notified.

Cereblab tested this by planting a file at src/_probe/never_read_canary.txt that the agent was not asked to open. The canary came back out of the intercepted upload, along with a secret that had been deleted from the repo weeks earlier and only survived in history. Both details matter because they close off the two natural defenses of the design: “it only sent files it read” and “it doesn’t matter what’s in git history.”

The “Improve the model” toggle in the CLI did nothing. Uploads persisted whether it was on or off. The real switch was a server-side flag called disable_codebase_upload that xAI flipped after the research landed. Elon Musk said the previously uploaded user data would be “completely and utterly deleted,” and the @SpaceXAI account added that enterprise teams on zero-data-retention contracts were never affected. For consumer users, the ongoing knob is a /privacy command inside the CLI that disables retention and deletes synced data.

Nothing in the reporting shows xAI trained on those repos, that a person read them, or that anything leaked further. What is documented is transmission and storage — which is enough to matter if any of those repos ever contained credentials, customer data, or a client’s source under NDA.

What to actually do

If Grok Build 0.2.93 or earlier ever ran against a repository you care about, treat the git history of that repo as uploaded to a third party between the tool’s release and July 13.

• Rotate any credential ever committed to that history, even if it was force-pushed out later. That’s the point of cereblab’s deleted-secret recovery — “we removed it” is not a defense once the bundle is sitting in someone else’s bucket.
• Run /privacy in the CLI to opt out of retention going forward, on every machine and account that ran the tool. Do not rely on the “Improve the model” checkbox — it demonstrably did not do what it says.
• Assume the same posture for any AI coding CLI you have not personally traffic-analyzed. The failure mode here is not exotic. It is the default for anything that has a “help improve the model” toggle and a network connection.
• If you’re on an enterprise ZDR contract, xAI’s public position is that you were not affected. Verify that against your own contract language before you rely on it; ZDR clauses have exceptions, and this incident is a fair prompt to re-read yours.

Priority call

Rotate first if you handle client code under NDA or if any of your repos have ever held live credentials — for those users, this is credential-rotation work, not a shrug. If Grok Build only ever touched personal projects with no secrets and no third-party code, you can safely drop it to the “run /privacy and move on” bucket.

The broader lesson doesn’t need dressing up. UI toggles in AI coding tools are marketing copy until you have watched the network traffic yourself. Treat every one of them that way.