Grok Build CLI uploaded entire Git repositories to xAI storage by default

What is this?

On July 12, 2026, a researcher publishing as cereblab released a wire-level teardown of xAI’s Grok Build coding CLI (version 0.2.93), reported by The Hacker News on July 14. The finding is a default-behavior data-exposure issue rather than a remote exploit: Grok Build uploaded the entire tracked Git repository and its full commit history to a Google Cloud Storage bucket run by xAI — not just the files a coding task actually needed. What the captures establish is transmission, acceptance, and storage of the code; they do not claim xAI trained on it or that staff read it.

This matters for the site’s readers because it is a concrete, recent example of a broader problem: cloud AI coding agents are not “local-first,” and the control most developers assume protects them — the training opt-out — governs a different thing entirely.

How it works

Any cloud coding agent must send some source code to a remote model to function; that channel is expected. The issue is the scope of what left the machine and through which path.

The researcher instrumented the CLI and separated two channels. On a 12 GB test repository of files the model never opened, model-turn traffic to /v1/responses came to roughly 192 KB, while a separate storage channel to /v1/storage moved about 5.10 GiB — a roughly 27,800× gap between what the model needed and what was uploaded. The upload ran as 73 chunks of about 75 MB, each returning HTTP 200, and its volume tracked total repository size. The destination bucket, grok-code-session-traces, was named both in the binary and in a staged metadata.json.

To prove the upload was indiscriminate, the researcher planted an unread canary file (src/_probe/never_read_canary.txt) with a unique marker, explicitly told the agent not to open it, then cloned the Git bundle out of the intercepted request and recovered the canary verbatim along with the repo’s complete history. A second, unrelated repository reproduced the result.

A separate and simpler path concerns secrets: when Grok read a file during a task, its contents entered the model turn, and a tracked .env went along unredacted (planted, fake API_KEY and DB_PASSWORD values), also landing in a session_state archive bound for storage.

Crucially, the setting most developers would reach for did nothing. With “Improve the model” turned off, Grok still uploaded the repository, and the server’s /v1/settings response kept returning trace_upload_enabled: true. That toggle governs whether your data trains the model — not whether your code leaves the machine. Those are two different controls, and only one was exposed to the user.

Why it matters

A repository is far more than its current working tree. It can hold proprietary code, internal URLs, customer data, and credentials that were removed from the working tree but still sit in commit history. Uploading the whole tracked repo plus history is a much wider boundary than sending the handful of files a task opens. In the researcher’s own cross-tool comparison, Claude Code and Codex sent no repository bundle, and Gemini sent none in an idle test; Grok Build was the outlier. All of them are still cloud tools that transmit the files they open, so “local only” is the wrong mental model for any coding agent — but wholesale collection of the workspace was specific to Grok Build here.

Defenses

Rotate exposed credentials first. If you ran the tool, rotate anything Grok could have sent: anything it read, anything in a tracked file, and anything in the Git history the bundle carried — including a secret that was committed and later deleted. Deleting a file later does not remove it from history.

Use the actual data control, not the training toggle. For individual Grok subscribers, xAI’s stated control is running /privacy in the CLI to disable retention and delete previously synced data; enterprise teams on zero data retention (ZDR) are described as never having code or trace data stored. Verify the behavior yourself rather than relying on a training opt-out, which does not govern egress.

Keep secrets out of tracked files and history. Use a secret manager and environment injection instead of committed .env files, add secrets to .gitignore before first commit, and scan and scrub history for previously committed credentials.

Treat agent network egress as a boundary. Where possible, monitor what a coding agent actually sends at the wire level, prefer tools that transmit only the files a task needs, and account for the fact that a data-collection path disabled by a server flag can be re-enabled without a client update.

Status

Item	Reference	Notes
Disclosure	cereblab wire-level teardown, 2026-07-12	Grok Build CLI 0.2.93; whole-repo + history upload to grok-code-session-traces
Reporting	The Hacker News, 2026-07-14	Corroborates channel split, canary recovery, unredacted .env
Vendor response	xAI / @SpaceXAI / E. Musk, on X	Server-side upload shutoff on 2026-07-13; /privacy for consumers; ZDR for enterprise; deletion promised, not independently verified
Latent code	Analysis of build 0.2.99	Upload code reported still in the binary, held off by a server flag — re-enable-able without an update
Classification	Data exposure / privacy	Not a CVE; captures show transmission and storage, not training

The durable lesson is a governance one: a “don’t train on my data” switch is not a promise that your code stays on your machine. For any cloud coding agent, treat repository egress as its own control surface, keep credentials out of tracked history, and verify what actually leaves the machine.