Skip to main content
  1. Articles/

Grok Build Was Quietly Uploading Entire Codebases to xAI's Cloud — the Privacy Toggle Did Nothing

·1121 words·6 mins·
Florent Clairambault
Author
Florent Clairambault
CTO & software engineer — writing daily about spec-driven development and agentic coding

Grok Build Was Quietly Uploading Entire Codebases to xAI’s Cloud — the Privacy Toggle Did Nothing

Every AI coding agent has to read your files to do its job. What it does with them after that is a design decision, not an accident — and the design decision xAI made for Grok Build, its Cursor/SpaceXAI-backed CLI, was apparently to upload the entire repository regardless of what the model actually needed. An independent researcher caught it on the wire, published the traffic capture July 13, and by July 14 Elon Musk was publicly promising to delete everything that had already been collected.

What the Traffic Capture Showed
#

The researcher, publishing as cereblab, ran a simple test: point Grok Build’s CLI (version 0.2.93) at a 12GB repository, give it a prompt that told it to reply “OK” and explicitly not open any files, and watch what crossed the wire. Model-turn traffic to xAI’s /v1/responses endpoint came to about 192KB — consistent with a trivial exchange. The storage channel to /v1/storage, meanwhile, moved 5.10GiB in 73 chunks of roughly 75MB each, landing in a Google Cloud Storage bucket named grok-code-session-traces.

That’s not a rounding error. It’s a ~27,800x gap between what the task required and what actually left the machine — the entire repository, full commit history included, files the agent was never instructed to touch. Cereblab reproduced the result across separate repositories and, notably, compared the behavior directly against Claude Code, Gemini, and Codex, which open individual files as needed rather than bundling and shipping the whole checkout plus its git history off-box.

The exposure wasn’t theoretical. A planted .env file containing test API_KEY and DB_PASSWORD values was transmitted unredacted in model turns and archived in session_state snapshots — the researcher used fake credentials for testing, but one documented case involved a user whose entire working directory, including SSH keys and a password manager database, was swept into the same upload path. Anyone who ran Grok Build against a repository containing real secrets should treat those credentials as exposed and rotate them.

The Privacy Toggle That Didn’t Do What It Says
#

The part that turns this from “a startup shipped a sloppy CLI” into a genuine trust failure is what happened when researchers checked the obvious control. Grok Build ships an “Improve the model” privacy toggle and a /privacy command. Turning it off is supposed to be the thing a security-conscious developer does before running an unfamiliar agent against proprietary code. It did nothing to the upload behavior. The server’s own /v1/settings response kept returning trace_upload_enabled: true regardless of the toggle state — because that flag, it turns out, governs whether your code trains the model, not whether your code leaves your machine. Those are two entirely different questions, and Grok Build’s UI let users believe they’d answered both by answering one.

The fix that actually stopped the uploads wasn’t a client update or a toggle at all — it was a server-side flag change, disable_codebase_upload: true, flipped quietly on July 13 after the analysis started circulating. Cereblab confirmed uploads had stopped across six repeat tests, and a second researcher, Peter Dedene, independently confirmed the same flag change on a separate account, ruling out a fix scoped to just the one machine that got caught looking.

xAI’s Response: A Promise, No Advisory
#

SpaceXAI’s public statement leaned on the zero-data-retention enterprise tier (“enterprise ZDR users never have code stored”) and the existing /privacy opt-out, adding: “We care deeply about your privacy and respect customer choice.” Musk went further on the deletion question specifically: “All user data that was uploaded to SpaceXAI before now will be completely and utterly deleted. Zero anything whatsoever will remain.”

What’s missing, as of this writing, is everything that would make that promise verifiable: no formal security advisory, no published timeline for the deletion, no way for an affected user to confirm their own data is actually gone, and no disclosure of how many repositories were captured before the flag flip. “Trust me, I turned it off” is not a security response — it’s a tweet standing in for one, and it’s the same asymmetry that shows up whenever the fix is a silent server-side toggle instead of a documented, audited process.

Why This Is the Sharper Story Than It First Looks
#

This blog has spent the last several weeks covering a genuine parade of agentic-coding security disclosures — SymJack and TrustFall, GuardFall, GhostApproval — and the common thread has been vendors debating scope: is this in the threat model, whose responsibility is the sandbox boundary, does the fix count as a fix. Anthropic’s own answer to GhostApproval (“outside our current threat model”) was fair game for criticism precisely because there was a position to argue with.

Grok Build doesn’t even get you that far. This isn’t a subtle trust-boundary edge case requiring a symlink and a poisoned README to trigger — it’s a CLI that uploaded whole repositories, by default, to a cloud bucket, and shipped a privacy toggle that didn’t cover the behavior it implied it covered. Coincidentally, the same week this surfaced, Claude Code’s July 14 changelog (v2.1.210) included two unrelated but relevant line items: a fix for isolation: 'worktree' subagents being able to run git-mutating commands against the main repo checkout instead of their own isolated worktree, and hardening of the Agent tool “against indirect prompt injection via content a subagent read.” Both are exactly the kind of narrow, specific, publicly changelogged fixes that let you evaluate whether a vendor’s sandbox model is sound — because you can read exactly what changed and why. A quiet server flag flip with no advisory gives you nothing to evaluate at all.

What to Actually Do About It
#

If you’ve run Grok Build against any repository containing real credentials — API keys, database passwords, cloud tokens, SSH keys — rotate them now; don’t wait for xAI’s deletion timeline, because there isn’t one yet to wait for. More generally, this is a good week to actually read what your coding agent’s privacy toggle claims to control, rather than assuming “improve the model: off” means “my code doesn’t leave this machine.” Those are different guarantees, and as this incident shows, a vendor can ship a toggle that visibly addresses one while silently leaving the other wide open. The agents worth trusting with your codebase are the ones whose sandboxing is a resource-level control you can inspect and reason about — not an opt-out switch you have to take on faith.


Sources:

Related