A researcher who publishes under the handle cereblab intercepted traffic from xAI's Grok Build coding tool and found it uploading entire codebases, git history and secrets included, to a Google Cloud bucket at 27,800 times the volume any single coding task required. Disabling the tool's only privacy control changed nothing. Elon Musk promised to delete the data, and xAI has not issued a formal security advisory.

On a MacBook running xAI's Grok Build coding tool, a security researcher who publishes under the handle cereblab typed one instruction into a throwaway test repository: reply OK, and do not read any files.

The terminal should have shown almost nothing. Grok Build had been told not to open a single file.

Instead, gigabytes of data started moving. By the time cereblab finished the test, the tool had packaged the entire repository, commit history included, into an archive and sent it to a Google Cloud Storage bucket controlled by xAI. A file cereblab had planted and explicitly told the agent not to touch came back readable, word for word, once the upload was retrieved.

That test sits at the center of a wire-level teardown cereblab published as a public GitHub Gist on July 10, a report that reached the front page of Hacker News on July 14. It documents that Grok Build, xAI's official command-line coding assistant, uploads far more of a developer's codebase than any coding task requires, that the tool's one user-facing privacy switch does nothing to stop it, and that a second, undocumented control is what actually shut the uploads off. Elon Musk, who founded xAI and now runs it as a division of SpaceX, responded on X with a promise to delete every file the tool had already collected.

The 27,800x Gap

Grok Build sends data to xAI over two distinct channels, and cereblab's capture is what makes the mismatch hard to explain away as routine telemetry.

The first channel carries the files the AI model actually reads to answer a coding question. In a test against a 12 gigabyte repository, that channel moved just 192 KB across five requests, a volume consistent with a handful of files being read for context.

A second channel, aimed at a separate storage endpoint, told a different story. It moved 5.10 GiB of the same repository, split into 73 chunks of roughly 75 megabytes apiece, every one of which returned a success response. The gap between the two channels came out to roughly 27,800 times.

No storage upload failed during the test. The errors that did appear were tied to a usage quota on the model channel, not to any ceiling on upload size.

The destination was a Google Cloud Storage bucket named grok-code-session-traces, identified both in the tool's compiled binary and in metadata attached to the uploaded files. cereblab found no mention of this upload behavior in Grok Build's install instructions or quickstart documentation.

A File It Was Told Never to Open

The clearest evidence in the report is not the byte count. It is a single file.

cereblab planted a marker inside a file named to make its purpose obvious and instructed Grok Build, in plain language, not to open it. The tool uploaded it anyway, packaged inside a git bundle, a format that carries not just current files but a repository's entire commit history. cereblab downloaded the bundle Grok Build had sent, cloned it, and found the untouched file intact with its marker still readable. The test was repeated on a second, unrelated codebase with the same result.

That detail matters because of what git history can hold. A secret committed and later deleted from a working file does not disappear from a repository's history; it stays in every commit that referenced it, and a full git bundle carries all of it.

Separately, cereblab confirmed that when Grok Build does read a file, its contents travel to xAI unredacted. A test .env file containing a fake API key and database password showed up verbatim in the tool's live traffic and in an archive routed to the same storage bucket. The credentials were fabricated for the test, so nothing real was exposed, but the tool applied no filtering to a file whose entire purpose is to hold secrets.

Developers who ran Grok Build against a repository containing real API keys, database passwords, or cloud tokens should treat those credentials as exposed and rotate them now, regardless of what any privacy setting displayed at the time. The risk is not limited to secrets sitting in a current .env file; it extends to any credential that ever touched a commit, a similar exposure pattern to the one LDS covered when a compromised PyPI package quietly harvested cloud credentials from unsuspecting developers' machines.

The Toggle That Did Nothing

Grok Build ships with one privacy control visible to ordinary users: a setting labeled "Improve the model," tucked into account settings under Data.

cereblab tested it directly. With the setting switched off, the tool still packaged and uploaded a full repository as a git bundle, complete with the never-read canary file. The server's own settings endpoint, queried by the CLI itself, kept returning trace_upload_enabled: true no matter what the toggle showed on screen.

The reason is architectural. Training consent and data transmission are two separate questions, and Grok Build exposed a control for only one of them.

Control	What it appears to govern	What the wire capture showed
"Improve the model" toggle	Whether xAI trains future models on your data	Uploads and trace_upload_enabled: true continued regardless of the setting
/privacy CLI command	Zero Data Retention status; deletes previously synced data	The only self-service option for individual subscribers
disable_codebase_upload flag	An undocumented server-side switch	Confirmed by retests as the mechanism that actually halted uploads on July 13
Zero Data Retention (ZDR)	No code or trace data stored at all	Applies to enterprise teams and API-key customers, not individual SuperGrok or X Premium Plus subscribers

"Improve the model" governs whether a future version of Grok gets trained on a user's data. It says nothing about whether that data leaves the machine in the first place. A developer who switched the toggle off had every reason to believe their code was staying local. It was not.

What Actually Stopped It

One day after the report went public, Grok Build's uploads stopped, but not because of anything a user changed.

On July 13, cereblab reran the identical binary and captured zero storage uploads across six separate tests. The server's settings response had changed on its own, now returning disable_codebase_upload: true. Developer Peter Dedene independently tested his own account and reported the same flag, confirming the change was server-side and not limited to a single machine.

No client software update accompanied the change. Grok Build's public changelog listed version 0.2.98 as current as of July 12, the day before the shutdown, with no mention of repository uploads. A separate review of a newer build found the upload code still compiled into the binary, simply held inactive by the server flag. That means xAI keeps the ability to switch it back on for any user without shipping an update or telling anyone.

The Case for Reasonable Doubt

Every cloud-based coding tool has to send some code to a remote server to function. cereblab's own report concedes as much, and a comparison the researcher ran against rival coding agents found that Claude Code and OpenAI's Codex sent no full repository bundle under the same test conditions, a contrast that sharpens rather than excuses Grok Build's behavior.

Wire capture proves transmission and storage. It does not prove xAI trained a model on any uploaded repository, and cereblab says so explicitly. One theory floated in the Hacker News discussion, and echoed by other outlets covering the report, is that uploading a full codebase lets Grok Build's underlying model, grok-4.5, inspect files during its reasoning process without repeated round trips back to the developer's machine: a latency optimization rather than a data grab. xAI has not confirmed or denied that explanation. Independent benchmarks already rank Grok 4.5 well behind xAI's own marketing claims, which makes the silence around this design choice harder to read as innocent.

The test secrets were also formatted strings rather than realistic high-entropy API keys, so whether a differently shaped credential would be caught by some undisclosed filter remains untested. Whether files excluded from git tracking are swept into the same upload was not confirmed either way.

What xAI has said publicly does not resolve those gaps. The company's account posted on X that enterprise customers on Zero Data Retention never have code stored, and that individual subscribers can run the /privacy command to opt into deletion. Andrew Milich, xAI's head of Grok Build, confirmed that changing privacy settings triggers retroactive deletion of previously synced data. Musk's own post went further: "As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted. Zero anything whatsoever will remain."

None of that has arrived as a security advisory. xAI has not published a timeline for the deletion, a way for users to confirm their own data was removed, or an account of how many repositories were collected before July 13. It is also not the company's first stumble in a coding-tool race it has pursued in part by hiring engineers away from Cursor; speed has repeatedly outpaced disclosure.

Security researchers have raised similar concerns about other AI coding assistants before, including config files that can hide instructions from developers entirely. Trusting an agent with a codebase means trusting infrastructure most users never see.

The Bottom Line

A coding tool with one visible privacy switch uploaded entire codebases regardless of how that switch was set, and stopped only when xAI silently flipped a server-side flag nobody outside the company could see. The gap between "we won't train on your data" and "your data never left your machine" is not a technicality. It is the whole story here, and Grok Build gave users a control for the first while quietly running the second by default.

The practical fix is not complicated. Anyone who pointed Grok Build at a real codebase before July 13 should rotate every credential that file or its git history ever held, run the /privacy command regardless, and stop assuming a settings toggle means what it says. xAI has said the uploads stopped. It has not said why they started, how long the data sat in that bucket, or what happens the next time a flag gets flipped without anyone watching.