An independent security researcher gave Grok Build an instruction that shouldn't have been remotely controversial: "Just reply OK. Do not read or open any files." The CLI complied, replying OK. But packet captures showed that behind the scenes, it quietly ran a git bundle operation, packaging the entire repository along with its commit history and sending it via POST /v1/storage to xAI's servers, which returned a 200 status code.

This was a wire-level traffic analysis of xAI's Grok Build CLI, version 0.2.93, conducted by an independent AI security researcher going by the pseudonym Cereblab. The test environment was macOS on Apple Silicon, using the grok-4.5 model. Cereblab compiled the analysis, packet captures, and SHA-256 checksums into a public GitHub gist with a blunt title: "What Exactly Does xAI's Grok Build CLI Send to xAI."

Told to "Just Reply OK" — the Whole Repo Got Bundled Up Anyway

Cereblab planted a file in the test repository that nothing had asked to be opened: src/_probe/never_read_canary.txt, containing a unique marker string, CANARY-XR47P2-NEVERREAD-UNIQUE. The instruction given to Grok Build was: "Reply strictly with: OK. Do not read or open any files."

Grok Build dutifully replied OK — but at the same time, it bundled the entire repository into a git bundle and uploaded it via the storage endpoint, with a request body of 152,102 bytes, which the server returned as a 200. The researcher downloaded the intercepted bundle file, ran git clone on it, and found the reconstructed repository contained the very file that was never supposed to be read — the marker string intact, character for character — along with the repository's full four-commit history. He then repeated the same test on an entirely unrelated Cloudflare Worker project, cereblab_auth, and again successfully recovered a newly planted sentinel marker, CANARY-AUTH-4T8K2-NEVERREAD, from the uploaded bundle. Two independent reproductions, identical results.

The significance of this evidence chain is that it rules out explanations like "the model misread context" or "local caching" — what gets uploaded has nothing to do with what Grok actually reads. Whether it reads a file or not, the entire repository gets bundled up and shipped out regardless.

192KB vs. 5.1GB: A Gap of Over 27,000x

To determine the scale of data this mechanism could upload, Cereblab built a roughly 12GB repository stuffed with random-content files the model would never read. During testing, the /v1/responses endpoint responsible for sending content to the model transmitted only 196,705 bytes total — about 192KB — across five requests, with the largest single request around 60,000 bytes. Meanwhile, the /v1/storage endpoint responsible for uploads kept firing off content-upload requests — 82 of them, plus one deduplication check — all returning 200. Of these, 73 were chunks of roughly 75,014,000 bytes each, totaling 5,476,083,317 bytes transmitted, or about 5.10GiB. That figure came from the point where the researcher deliberately stopped the packet capture — he didn't wait for the full 12GB to finish uploading — but it was already enough to demonstrate that this upload mechanism could reliably move multi-gigabyte volumes of data, with not a single failed request.

Dividing the two channels' transfer volumes gives a ratio of roughly 27,800x: the model "saw" only 192KB, yet 5.1GB of content left the machine. The data's final destination wasn't xAI's own AI infrastructure, as many assumed, nor was it AWS S3 — it was a Google Cloud Storage bucket named grok-code-session-traces, with file paths formatted like gs://grok-code-session-traces/repo_changes_dedup/v2/.../sha256_…. These strings are hardcoded in the client binary, visible upon decompilation.

Turning Off "Improve the Model" Did Nothing; the New Privacy Command Doesn't Address This Either

Grok's account settings include an option similar to a "user experience improvement program," called "Improve the model." Cereblab specifically disabled it and repeated the full repository upload test — nothing changed. Grok Build still bundled the entire repository into a git bundle and shipped it out; the server's /v1/settings endpoint kept returning trace_upload_enabled: true, upload_enabled: true, session_registry_enabled: true, plus a per-file cap parameter, max_upload_file_bytes: 1073741824 (1GiB). In other words, the toggle that appears to control "whether my code gets sent out" actually only governs training use — it has nothing to do with whether code leaves your machine.

After the story blew up, xAI added a new /privacy command to Grok Build, letting users opt out of data retention and delete previously synced data. Cereblab specifically retested this, and the conclusion was unsparing: what actually stopped the uploads was a server-side global switch unrelated to any user action, disable_codebase_upload: true. The /privacy command, from start to finish, was only ever a "per-session retention setting" — not remotely the switch that blocks code from leaving the machine. As he put it bluntly in a gist update: that's not the switch that fixes the problem, and "the correct default should be off."

Secrets in .env Went Straight Into the Request Sent to the Model

The test repository also included a .env file with fake credentials: API_KEY=CANARY7F3A9-SECRET-should-not-leave and DB_PASSWORD=CANARY7F3A9-DBPASS. When Grok Build read this file as part of a task, both strings appeared verbatim in a 48,070-byte POST /v1/responses request body — and also appeared, character for character, in the session-state archive bundled and uploaded to cloud storage. There was no redaction, masking, or filtering of any kind: neither a filename containing .env nor field names containing API_KEY or PASSWORD triggered any interception mechanism. The researcher used fictitious credentials in testing, so no real credentials were exposed — but this pathway applies equally to any real secrets in any real project.

A Developer's Home Directory — SSH Keys and Password Vault Included — Got Uploaded Too

After the report was published, a developer using the handle "A Green Being" posted on X saying that after accidentally running Grok Build from their user home directory, their entire home folder — including SSH keys, password manager database, documents, photos, and videos — was uploaded to xAI's servers.

That individual case was quickly corroborated independently. A user going by wetlink left a comment on Cereblab's gist saying they'd reproduced the same behavior on a second machine (same version number, same SHA-256 checksum). Local logs at ~/.grok/logs/unified.jsonl recorded 339 repo_state.upload.enqueued events across four different repositories — and in one session, the repo_path field was literally the user's entire home directory. All of this happened before any mitigation was in place.

Git history itself amplifies the risk: even if sensitive information has since been deleted from a repository's current working tree, as long as the commit history hasn't been scrubbed, secrets, internal server addresses, or unreleased feature code committed months earlier would still be swept up and shipped out along with the complete git bundle.

Among Comparable Tools, No One Else Does This

Cereblab used the same methodology to test Claude Code, Codex, and Gemini, and found all three behaved responsibly: they sent only files the model had actually opened, and the planted "never read" sentinel file never left the local machine in any of them. Gemini hit a quota limit during the real-task test and couldn't complete the full run, but no repository-level upload was observed in idle-state testing either. Cereblab told Cybernews: "The other three stayed local and only sent what they actually opened — my 'never read' file never left my machine."

The Server Quietly Flipped the Switch; Musk's Statements Contradicted Each Other

Once the story gained traction, xAI didn't issue a formal statement first — instead, it quietly set disable_codebase_upload to true on the server side. Cereblab ran six consecutive retests and no longer observed repository-level uploads on the /v1/storage endpoint.

Hours later, the official X account for SpaceXAI (xAI's current name) posted a response, stressing that "we take your privacy very seriously and respect our customers' choices," and explaining that for teams with Zero Data Retention (ZDR) enabled, "no tracking or code data is retained," while users without ZDR could run the /privacy command to view or change their settings and delete previously synced data. Company employees Andrew Milich and Jason Ginsberg both weighed in in the comments to reassure developers, and then Elon Musk himself joined in, replying with his signature single word "true," and promising: "As a precaution, all user data previously uploaded to SpaceXAI will be thoroughly and completely deleted, with nothing left behind."

But that same day, in a separate, unrelated tweet, Musk encouraged users to "keep sharing data," reasoning that retaining "some" data helps with debugging — directly at odds with the "complete deletion" commitment he'd just made. Cereblab wasn't buying the official explanation either, publicly pushing back that /privacy was never the switch that actually solved the problem, and that the company shouldn't credit a user setting that doesn't actually work.

The Switch Is Still There — It's Just Been Paused for Now

Cereblab added a note to the gist clarifying that this "fix" was purely a server-side remote toggle, not a new client release. That means xAI could flip the switch back on at any time without shipping a new version — and developers would have no way of knowing. Wetlink, the commenter who reproduced the issue, checked again on July 13 and found the server was now returning in_remote_trace_upload_enabled: false — uploads were suspended for the moment, but the capability itself remains built into the client code. Wetlink therefore recommended that anyone who wants uploads truly disabled add a manual "hard gate" to their local config file — [harness] disable_codebase_upload = true — rather than relying solely on the server-side remote flag, which could be flipped back at any time.

Both The Register and Axios stated explicitly that they were unable to independently verify whether — or when — SpaceXAI actually completed the data deletion Musk promised. Axios added some industry context: this isn't the first time in 2026 that an AI company has run into controversy over data retention policy. Earlier this year, when Anthropic launched Fable 5 and Mythos 5, it began retaining user data for 30 days for those two models — even for some enterprise customers who had zero-data-retention agreements in place — citing the need to "support our safety work." Cybernews also flagged an additional dimension of concern: Grok is currently in use by the U.S. government and has been cleared for access to classified Pentagon networks — adding a layer of risk to "uploading entire repositories by default" that shouldn't be dismissed, though no reporting so far has established a direct connection between this incident and that access.

If You've Used Grok Build, Here's What to Do Now

If you processed private or sensitive repositories with Grok Build before xAI's server-side fix, you should treat this as a potential third-party data breach — not something you can resolve by simply turning off the software:

  • Don't limit your audit to the current working tree — search the complete Git commit history too, specifically for cloud service keys, database connection strings, package registry tokens, signing material, OAuth credentials, and webhook secrets.
  • Any credential that was ever present in a readable repository, or read during any session, should be revoked and rotated outright — not supplemented with a new one, since issuing a new key doesn't invalidate the old one.
  • Check access logs on downstream systems — cloud platforms, code hosting, databases, CI/CD — for any anomalous calls during this period.
  • Don't focus only on .env files — any keys, certificates, or internal hostnames of any format that ever appeared in the repository history should be treated as potentially having left the machine.

Cereblab's advice is more direct: anyone who ran Grok Build against a real repository before this was exposed should assume any secrets in that repository "may" have been uploaded, and proactively rotate API keys, database passwords, cloud tokens, signing keys, and webhook credentials. As for whether the data already sitting in the grok-code-session-traces bucket has actually been cleaned up, there's currently no way for a third party to verify that on developers' behalf — that answer can only come from xAI itself, and it needs to be verifiable.