Grok Build's coding CLI was shipping whole repositories, secrets included, to xAI storage

xAI’s Grok Build, the company’s official coding CLI, was quietly uploading developers’ entire git repositories, including files the agent never opened and credentials committed to history, to a Google Cloud Storage bucket. An independent wire-level analysis found the behavior ran by default, and the consumer privacy toggle meant to govern model training did nothing to stop the transfer. xAI switched the uploads off server-side a day after the findings went public, which closes the immediate exposure but leaves a sharper question in place: a coding agent’s data path, not just its output, is part of what you are trusting.

What the analysis found

A researcher publishing as cereblab captured the traffic from Grok Build version 0.2.93 and published a reproducible, wire-level breakdown. The headline number is the gap between what the model needed and what left the machine. On a 12 GB repository, the model channel at /v1/responses moved about 192 KB across five requests, while the storage channel at /v1/storage moved 5.10 GiB across 82 uploads, a roughly 27,800-fold difference. As the author puts it, “the model demonstrably never ingested the files (192 KB cannot carry 5 GiB of content), yet 5.10 GiB of them left via /v1/storage.”

The destination was a Google Cloud Storage bucket named grok-code-session-traces, named in plain text inside the binary and in captured metadata. What went into it is the concerning part: a .env secrets file transmitted verbatim and unredacted, the full git history reconstructable from the wire-captured bundle, and a planted canary file the agent was explicitly told not to read, recovered intact. Disabling the “Improve the model” setting did not change any of this. The /v1/settings response still returned trace_upload_enabled: true.

One caveat matters for fairness, and the researcher makes it first: this is a measurement of transmission and storage, not of training. Upload is not the same as training, which is governed by policy and account tier. The finding is that the data left the machine and was accepted, not that a model was trained on it.

For a working developer, that distinction does not soften the practical risk. Grok Build runs locally with access to your filesystem, so sending the whole repository, including secrets buried in old commits, is a materially different exposure than routine telemetry. Anyone who ran an affected version against a codebase with live API keys, database passwords, or cloud tokens should treat those credentials as potentially exposed and rotate them, because deletion of an upload does not scrub a secret that is still sitting in git history.

How xAI responded

xAI moved quickly once the analysis reached the Hacker News front page on July 14. The company disabled the upload path server-side on July 13, and the same binary stopped making storage requests without any client update, with the server now returning disable_codebase_upload: true. On the @SpaceXAI account, xAI said enterprise teams on zero-data-retention plans never had code stored, and that consumers can run /privacy in the CLI to disable retention. Elon Musk said the previously uploaded data would be “completely and utterly deleted.”

The mechanism of the fix is worth noting. A server-side switch turns the behavior off today, but the capability still ships in the client, so what protects a user is a configuration flag on xAI’s side rather than code that is no longer there. That is a thinner guarantee than a client update that removes the upload path outright, and it puts the burden of trust back on the vendor’s server config.

Where this lands in the market

This is the second trust story in a month to turn on what a coding agent does quietly rather than what it advertises, after the hidden fingerprinting found in Claude Code that prompted Alibaba’s ban. The common thread is that these tools earn deep access to a developer’s machine, so the terms of what they read, transmit, and retain are becoming a first-class part of the product rather than a line in a privacy policy. A default-on upload that ignores the user’s own privacy toggle is exactly the kind of design that security teams now put on the review checklist before a tool touches production code.

What’s worth watching

1. Whether xAI ships a client that removes the upload path. A server flag is reversible by a config change. Code that is gone is not. The signal to watch is whether the next Grok Build release strips the capability rather than gating it.
2. Whether the toggle behavior draws scrutiny. A consumer privacy control that does not control the thing it appears to control is the kind of gap that regulators and enterprise procurement teams tend to ask about.
3. Whether affected developers actually rotate. The exposure is only closed when credentials that passed through affected versions are rotated and any deletion xAI promised is verifiable.

The durable lesson is that for tools that run on your machine and read your code, the network path is part of the security surface, and a default that favors collection over restraint is a choice users deserve to see. Stackmaven’s follow-up coverage will revisit xAI’s client fix, any proof of deletion, and whether the toggle gap draws formal scrutiny on or around October 13.

Sources cited

1. Cereblab: What xAI Grok Build CLI actually sends to xAI, a wire-level analysis (grok 0.2.93) gist.github.com
2. The Hacker News: Grok Build Uploaded Entire Git Repositories to xAI Storage, Not Just Files It Read thehackernews.com
3. Cybersecurity News: xAI Grok Build CLI Uploaded Entire Git Repositories and Unredacted .env Secrets to Cloud Storage cybersecuritynews.com