A security researcher just published wire-level proof that xAI’s Grok Build CLI uploads your entire repository to a Google Cloud Storage bucket — including files the agent never reads, never touches, and you never asked it to share. On a 12 GB test repository, 5.1 gigabytes transferred successfully. Your .env file went along for the ride, credentials unredacted. The opt-out setting you may have toggled? It doesn’t stop the uploads.
The analysis, published by researcher “cereblab” on GitHub Gist, landed on the Hacker News front page. xAI marketed Grok Build as “local-first” — a term that implied your codebase stays on your machine. The wire-level analysis tells a different story.
What the Grok Build CLI Data Collection Analysis Found
Cereblab intercepted every packet leaving the machine while Grok Build CLI v0.2.93 ran.
Your .env file leaves the machine, verbatim
When the agent reads a file, that file’s content is serialized into the model request and sent to cli-chat-proxy.grok.com. The researcher planted API_KEY=CANARY7F3A9-SECRET-should-not-leave in a secrets file, and it appeared verbatim in the captured traffic. A 48 KB file containing database credentials and API keys transmitted in the clear.
xAI’s launch materials described Grok Build as “local-first,” with “nothing from your codebase transmitted to xAI servers during a session.” The wire data contradicts this directly.
The whole repository uploads — not just what the agent reads
Grok Build runs two data channels simultaneously. The first is the model-turn channel: files the agent reads, sent as context. The second is a background upload of the entire workspace as a git bundle, sent via a separate POST /v1/storage endpoint to a GCS bucket called grok-code-session-traces.
The numbers: 5.10 gigabytes transferred in 73 chunks on a 12 GB repository. All 83 storage requests returned HTTP 200. Zero failures. The researcher later cloned a file from the captured bundle that the agent had never read during the session — proving the upload isn’t scoped to what Grok touches, but to everything that exists in the workspace. The storage channel sent 27,800 times more data than the model-turn channel.
The privacy toggle doesn’t stop uploads
Grok Build includes an “Improve the model” toggle. After disabling this setting, the server’s response still included "trace_upload_enabled": true. The repository upload proceeded as normal.
The toggle governs training consent. It does not stop your code from leaving your machine. This distinction is not documented anywhere in Grok Build’s setup materials.
Transmission Is Not Training — But That’s Not the Only Problem
The researcher is explicit: this analysis “does not prove xAI trains on this data.” The grok-code-session-traces bucket likely exists for session continuity, debugging telemetry, or operational logging.
But the real problem isn’t what xAI does with the data after it arrives. It’s that developers had no reasonable way to know this was happening. The “Improve the model” toggle explicitly signals user control over data sharing. The “local-first” marketing explicitly signals code stays on your machine. Neither claim holds up under the wire-level evidence.
What Developers Should Do Now
If you’ve run Grok Build inside a codebase containing secrets, treat those credentials as potentially exposed and rotate them. Add a .grokignore file to exclude sensitive directories. Enterprise teams should enable Zero Data Retention (ZDR) mode. Read the full wire-level analysis on GitHub Gist.