Dev ToolsArticle Wire captures show the CLI shipped complete git history to GCS, and the privacy toggle did nothing.
Rachel Goldstein
xAI marketed Grok Build as local-first. The wire data said otherwise. Packet captures of CLI 0.2.93 show the tool packaging entire tracked Git repositories (full history included) and up them to a Google Cloud Storage bucket named grok-code-session-traces
, independent of which files the agent actually opened for a task.
This is not a story about a model accidentally seeing a secret in context. It is a story about a parallel storage channel that treated the whole workspace as payload, ignored the product's own consent toggle, and got patched server-side with no advisory, no changelog note, and no public word on retention of code already collected. For any team that pointed the binary at a private monorepo, that is a supply-chain and privacy failure dressed up as product telemetry.
Two channels, one ratio that ends the argument #
Researcher cereblab routed Grok Build 0.2.93 through mitmproxy on macOS and published the captures. The client ran two channels in parallel.
The model-turn path (POST /v1/responses
) sent task-relevant traffic. On a 12 GB test repository, that channel moved about 192 KB. The storage path (POST /v1/storage
) moved roughly 5.10 GiB across 73 chunks of about 75 MB each, all returning HTTP 200. That is a ~27,800× ratio between what the model needed and what left the machine. The destination showed up in the binary and in captured metadata as gs://grok-code-session-traces/...
(paths under repo_changes_dedup/v2/
), not as ephemeral debug scratch.
The upload was a git bundle of the tracked workspace. Cloning a captured bundle recovered a canary file the agent had been told not to open (src/_probe/never_read_canary.txt
) with its marker intact, plus full history. Denying the agent permission to read a file stops it from stuffing that file into the chat context. It does not stop the whole-repo bundle.
Secrets rode along. A planted .env
canary (API_KEY=CANARY7F3A9-SECRET-should-not-leave
) and mock database credentials appeared verbatim and unredacted in request bodies on both channels. That is the difference between "agent reads what you open" and "agent ships the tree."
Consent theater #
Grok Build ships an "Improve the model" toggle. Most developers will read that as the data-collection control. Disabling it did not stop the uploads. Server responses still returned trace_upload_enabled: true
, and the repository transfer proceeded. The setting appears to govern training consent, not whether code leaves the machine. That distinction is not surfaced clearly in the setup materials the reporting checked, and the bucket name does not appear in the onboarding flow.
Local-first marketing and an opt-out that only half-opts-out is how you get silent collection at monorepo scale. The researcher is explicit that the captures do not prove xAI trained on the data, that employees browsed it, or that every account saw the same flags. Transmission, acceptance, and storage are what the evidence shows. For enterprise risk review, transmission to a named, durable GCS bucket is already the incident. Training is a secondary question you ask after you know what left the building.
A silent fix is not a postmortem #
A day after the report went public, retests of the same 0.2.93 client saw the server return disable_codebase_upload: true
alongside trace_upload_enabled: false
. Across six retests, no repository uploads were observed. That looks like a deliberate remote mitigation, flipped without a client update.
The caveats cut both ways. Verification so far is one machine and one account. There is no public confirmation it is global, staged, or permanent. The official changelog listed 0.2.98 as latest around July 12, 2026 without mentioning repository-upload behavior at all. No security advisory. No statement of purpose, scope, or retention. No answer on whether repositories already sitting in grok-code-session-traces
will be deleted.
If you already ran the tool against proprietary code, you now hold an undisclosed third-party copy problem with no published retention policy and no clear path under GDPR-style "what did you collect and can we erase it" questions. Silent server-side flips are efficient engineering. They are terrible incident response.
What this means if you ship or consume AI CLIs #
Treat any coding agent CLI as a network-connected process with full workspace access until you have proven otherwise on the wire. Marketing copy and a settings page are not a data processing agreement.
Practical steps if Grok Build (or anything like it) touched a sensitive repo:
- Rotate credentials that lived on disk in that workspace (
.env
, committed config, CI tokens, cloud keys). Canaries appeared unredacted. Assume secrets did too. - Inventory sessions: which machines, which accounts (consumer SuperGrok login vs enterprise), which repos. The upload ran from the workspace the CLI was pointed at.
- Do not rely on a single UI toggle. For this tool, "Improve the model" off still left
trace_upload_enabled: true
on the settings response. Verify with a proxy or deny-by-default network policy if policy requires it. - Prefer zero-disk secrets where you can (vault inject at runtime so there is no file for any agent or bundle to pick up). Ignore lists and "don't read that" prompts only constrain the chat path, not a full git-bundle upload.
- If you evaluate AI coding agents for enterprise use, add a standard test: canary file the agent is told not to open, full-repo size measurement on the storage channel, toggle every privacy switch, capture with mitmproxy or equivalent, and demand a written retention and deletion story before the pilot expands.
Vendors shipping agent CLIs should expect this exact test. The market is already grading tools on what crosses the wire, not on what the settings page implies.
The pattern, not just the product #
AI coding agents are infrastructure now. They run against monorepos that hold unreleased product code, customer schemas, and production config. Full-repo exfiltration as an undocumented side channel is a different risk class from "the model saw a file you opened." The Grok Build case is useful because the evidence is concrete: version, endpoints, byte counts, HTTP 200s, git-bundle clone recovery of never-read files, and a server flag that flipped after publicity.
The honest read is that undisclosed whole-repo collection was real on 0.2.93 for the tested configuration, the advertised control did not stop it, and the response was a quiet remote disable rather than a transparent fix. That combination is enough to put Grok Build (and any peer tool with similar architecture) behind a proxy and a written DPA until the retention question has a public answer. Local-first means the code stays local unless the developer clearly opts into something else. Anything short of that is just cloud SaaS with extra steps and worse documentation.
Run the wire test yourself before the next agent lands in your path.
Sources & further reading #
xAI's Grok Build CLI Uploads Git Repositories to a Google Cloud Bucket— internationalcyberdigest.com -
[xAI Grok CLI Uploads Full Repos and Secrets, Opt-Out Ignored | AI Weekly](https://aiweekly.co/alerts/xai-grok-cli-uploads-full-repos-and-secrets-opt-out-ignored)— aiweekly.co -
[Grok Build CLI Uploads Your Entire Repo to xAI Servers | byteiota](https://byteiota.com/grok-build-cli-uploads-repo-xai-servers/)— byteiota.com -
[What xAI Grok Build CLI actually sends to xAI - a wire-level analysis (grok 0.2.93) · GitHub](https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547)— gist.github.com
[Rachel Goldstein](https://sourcefeed.dev/u/rachel_goldstein)· Dev Tools Editor
Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop.
Discussion 0 #
No comments yet
Be the first to weigh in.