xAI's Grok Build CLI Quietly Uploaded Whole Repos — Then Went Open Source

What happened

xAI's grok coding-agent CLI, Grok Build, came under sustained community backlash after developers discovered that running it in a directory could upload that entire directory to a Google Cloud Storage bucket. One user reported running the tool in their home directory and watching it upload, in their words, "my SSH keys, my password manager database, my documents, photos, videos, everything." The report and follow-up analysis spread quickly through developer communities including Hacker News.

Independent analysis backed up the anecdote. Researchers intercepting the CLI's traffic found it transmitting a full Git bundle — every tracked file plus the repository's complete commit history — to a bucket used for session traces, a volume of data far larger than anything the coding task at hand required.

The privacy toggle didn't stop it

The more serious finding wasn't that the tool uploaded data by design — coding agents routinely need to send file context to a model backend — but that the upload continued regardless of the app's own opt-out setting for using data to improve the model. A toggle presented to users as controlling data collection had no effect on whether their files left the machine.

That gap between a documented privacy control and actual network behavior is the part worth dwelling on. Consent UI is a promise; only a packet capture confirms whether the software keeps it.

xAI's response: kill the upload, then open the code

xAI moved to shut off the upload path and address the fallout. Elon Musk stated that "all user data that was uploaded to [xAI] before now will be completely and utterly deleted." Days later, xAI released the entire Grok Build codebase — reported at roughly 844,530 lines, predominantly Rust — under an Apache 2.0 license, as documented by Simon Willison.

Notably, the offending code was not deleted, only disabled. The upload logic still exists in the source (in the xai-grok-shell upload module); the function that used to ship files off-box now returns a hard-coded unavailability error instead. Open-sourcing lets the community verify that behavior directly rather than take xAI's word for it — which is itself a meaningful, if belated, improvement.

Why this matters beyond one vendor

Agentic CLI tools are, by design, granted broad filesystem access so they can read code, run commands, and make edits. That access model makes them a high-value target for exactly this failure mode: a default-on data path that quietly reaches far beyond what the user's task needed, discovered only because someone happened to run a proxy against it.

• Treat any agentic CLI with filesystem access as a potential exfiltration path until you've verified its network behavior yourself — don't rely on the vendor's own toggle.
• Run new AI coding tools in a scoped or disposable environment first, away from credentials, password vaults, and unrelated personal files.
• When a vendor open-sources a tool after an incident, audit the actual data-handling code paths, not just the change in license.
• Budget for periodic re-verification: a vendor can silently re-enable a data path in a future release just as easily as it disabled this one.