Grok Build's Full-Repo Upload Broke Local-First Trust

AI coding agents already sit on a dangerous trust boundary: they read source, open configs, and often run shells inside monorepos full of unreleased code and credentials. What most developers still assume is that the blast radius is bounded by what the agent touches. A wire-level teardown of xAI's Grok Build CLI shows that assumption is wrong for at least one major product, and that the controls marketed as privacy switches do not do what people think they do.

The defensible conclusion is not "xAI stole everyone's code." It is sharper and more useful: in the tested configuration of Grok Build CLI 0.2.93, a full tracked Git repository left the machine on every session, independently of model context, including files the agent never opened, and a user-facing "Improve the model" toggle did not stop it. That is a disclosure and consent failure, not a clever exploit.

Two channels, not one

Researcher cereblab routed Grok Build through mitmproxy on macOS and separated the traffic. The first path is the one every cloud coding agent has: files the agent reads get serialized into model requests (here, toward cli-chat-proxy.grok.com / POST /v1/responses). Planted canaries such as API_KEY=CANARY7F3A9-SECRET-should-not-leave and mock database credentials appeared verbatim in those bodies. Unpleasant, but expected once you let an agent open a secrets file.

The second path is the one that changes the risk math. In parallel, the client packaged the workspace as a Git bundle and sent it through POST /v1/storage into a Google Cloud Storage bucket named grok-code-session-traces (paths under gs://grok-code-session-traces/repo_changes_dedup/v2/…). On a SuperGrok account, cloning a captured bundle recovered a tracked canary file the agent had been explicitly told not to open, plus Git history. The upload is not scoped to "what the model needed for this turn."

Scale makes the distinction hard to hand-wave. On a roughly 12 GB test repository of incompressible data, storage traffic accepted about 5.10 GiB across 73 chunks (all HTTP 200) before the run was stopped. Model-turn traffic in the same session was on the order of 192 KB. That is roughly a 27,800× ratio between what left for context and what left for storage. Whatever the operational story (session continuity, debugging, traces), the volume is not explained by model context.

Local-first marketing vs. the wire

xAI's Grok Build docs and launch framing positioned the tool as a terminal coding agent for professional work, with the usual local-first language around sessions and codebase handling. The wire data contradicts the strongest reading of that claim. Nothing in the onboarding flow the researcher described called out a full-repo bundle upload to a named GCS bucket. The "Improve the model" toggle, which most developers would treat as the data-sharing control, only affects training consent. After it was turned off, settings still returned trace_upload_enabled: true and the storage channel continued.

Community reverse-engineering later surfaced flags such as disable_codebase_upload=true and trace_upload=false that were not part of the documented setup path. After the findings circulated, the same 0.2.93 client began receiving a server-side disable_codebase_upload: true and the original storage requests stopped appearing. That is evidence of a server-side mitigation, not a published advisory, not a guarantee of global rollout, and not proof that earlier uploads were deleted. Public changelog notes for later builds (e.g. 0.2.98) and status pages did not, at the time of reporting, describe the behavior, the flag, or data handling for prior sessions.

One honest limit on the evidence: the analysis does not prove training on the uploaded code. Transmission is not the same as training. It also does not prove employee access, retention windows, or that every account and every version behaved identically. Those gaps matter for legal and PR language. They do not erase the operational fact that complete tracked repositories and unredacted secrets left developer machines without a clear, working user control.

What this means in a real workflow

Treat this as a class of risk, not a one-off Grok embarrassment.

If you already ran Grok Build against private code: assume anything tracked in those repos (and any .env or secrets file the agent could open) may have left the machine. Rotate credentials that lived on disk. Do not rely on "we turned off model improvement" as a historical mitigator; it did not gate the storage channel in the capture.

Ignore files and prompts are not enough. Ignore lists only help if the client respects them and if the agent never shell-bypasses them. Permission prompts for shell commands do not stop a first-party client upload. The only reliable pattern for secrets is still zero-disk: vaults, runtime injection, short-lived tokens. If a canary string can live in a file the agent or the uploader can see, it will eventually leave.

Verify, do not trust the settings page. For any AI CLI that claims local-first or optional telemetry:

# Cheap canary
echo 'API_KEY=CANARY-should-not-leave' > .env.canary
# Run the agent in a disposable clone, then inspect egress
# (mitmproxy, Charles, or your corp proxy)

Look for storage or "session trace" endpoints, multi-hundred-MB POSTs, and git-bundle-shaped payloads. Check whether privacy toggles change those requests or only training flags. Community reports also mentioned a .grokignore mechanism; enterprise docs did not clearly document it at the time, so treat it as untrusted until you prove it blocks the storage path on your version.

Enterprise and compliance angle. Destination was a GCS bucket under xAI's session-trace naming, not "your VPC." Reporting noted no published Data Processing Agreement tailored to Grok Build and no EU residency path for the tool. European teams running consumer or SuperGrok builds against private repos had no clean compliance story under those conditions. If you need ZDR or contractual deletion, get it in writing and re-test the wire; a server flag that appeared after public heat is not a contract.

CI and monorepos. Agents in CI that see production configs, customer schemas, or unreleased product trees multiply the problem. Full-repo upload means history and sibling packages you never intended to "chat about" can leave with a single session. Isolate agent workspaces to the minimum git subtree, strip secrets before the agent starts, and prefer headless modes with explicit allowlists once vendors expose them.

How this sits next to the rest of the field

Every major coding agent eventually reads sensitive files; that baseline is well known. What separated this incident was scope (whole bundle + history, not only opened files) and disclosure (toggle and local-first language that did not match the second channel). The market is already shifting how it grades vendors: mitmproxy and canaries are cheap, and "what the settings page says" is no longer the acceptance test.

Server-side disable flags that appear after a public gist are a better outcome than silence, but they are a weak substitute for default-off telemetry, documented retention, and client-side controls that actually gate egress. Developers integrating these tools into daily workflows should assume undocumented phone-home until they have packet evidence otherwise, and should design repos so that a full tracked clone is still something you could live with leaving the building.

The practical bar for the next generation of coding CLIs is simple: if a repository crosses the wire, the product must say so in the setup path, the toggle that looks like privacy must control that path, and multi-gigabyte "session traces" must not be the silent default. Until then, local-first is a marketing phrase, not an architecture.