Grok Build Was Shipping Your Entire Codebase to the Cloud, Secrets Included

If you've been running an AI coding agent inside a private repo, this is the story to read closely. Security researcher Cereblab published a wire-level analysis of SpaceXAI's Grok Build CLI (version 0.2.93) showing that alongside the normal back-and-forth with the model, the tool was quietly packaging entire Git repositories and shipping them to a Google Cloud Storage bucket called grok-code-session-traces.

What the wire capture showed

The numbers are the story. Traffic to the model endpoint (/v1/responses) — the actual coding conversation — came to roughly 192 KB. Traffic to a separate storage endpoint (/v1/storage) came to 5.1 GiB across 73 chunks: about 27,800 times more data than the task needed. That gap is what happens when an agent isn't just reading the files it's told to read — it's bundling the whole working tree and mailing it home.

Two details make this worse than a bandwidth story. First, the uploaded bundles included files the agent had been explicitly instructed not to open. Second, tracked .env files went up unredacted, canary API_KEY and DB_PASSWORD values included — meaning any secret ever committed to the repo, even one later deleted from the working copy, was still exposed via Git history in the bundle.

The privacy toggle didn't work

SpaceXAI's user-facing 'Improve the model' setting is supposed to opt users out of data collection. According to Cereblab's testing, it had no effect on the storage channel: with the toggle disabled, the server's own /v1/settings response still returned trace_upload_enabled: true, and full-repository uploads proceeded anyway. For a tool marketed to developers working in private codebases, a privacy control that's cosmetic rather than functional is the part that should worry teams most — it means consent had no bearing on what actually left the machine.

The response

Cereblab's report went public on July 12, 2026. By July 13, the same 0.2.93 binary had stopped making storage requests — Cereblab retested six times and observed zero uploads, with the server now returning disable_codebase_upload: true. Elon Musk posted that SpaceXAI would delete all data uploaded before the fix, per The Register: "As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted." As of reporting, that pledge came via a social post rather than a security advisory or changelog entry — no deletion timeline, no way for users to confirm removal, and no disclosure of how many repositories were captured.

Why this matters beyond one CLI

Agentic coding tools need broad filesystem access to be useful — that's the whole premise of vibecoding. But broad access is a trust bet, and this incident shows how quietly that bet can go bad: a background telemetry channel doing 27,800x the work the visible feature needed, invisible to anyone not capturing packets. The fix here is procedural, not just a vendor patch. Any team adopting an AI coding agent should know, before granting repo access, what leaves the machine, whether stated privacy settings actually gate it, and what a network capture during a real session shows — not what the marketing page claims.

If you've used Grok Build

• Rotate every credential the tool could have touched — not just secrets in files it read this session, but anything in the repo's Git history, including deleted commits.
• Treat any repo opened with the CLI before July 13, 2026 as potentially exposed, since that's when the upload channel was confirmed disabled.
• Don't rely on an in-app privacy toggle as a security control until you've verified its effect with your own traffic capture.