xAI Grok CLI Uploads Full Repos and Secrets, Opt-Out Ignored
TL;DR
- Denying the agent read permission on a file does not stop that file from being included in the full-repo Git bundle sent to grok-code-session-traces.
- ByteIota measured 5.10 GB transferred in 73 chunks on a 12 GB repository; the storage channel moved 27,800 times more data than the model-turn channel.
- xAI applied a server-side mitigation silently: no security advisory, no changelog entry, and no public statement on the scope or retention of already-collected data.
Every specific below comes from a wire-level teardown by @cereblab, published as a public gist after routing xAI's Grok Build CLI through mitmproxy on macOS. The headline finding is not that a CLI agent phones home. It is that the phone-home is the entire repository, uploaded independently of what the agent actually reads, and that the opt-out toggle in the product does not stop it.
The proof is in the ratio. On a 12 GB test repository, the model-turn channel at POST /v1/responses moved 192 KB of traffic. The parallel channel at POST /v1/storage moved 5.10 GiB across 73 chunks of about 75 MB each, all returning HTTP 200. That is roughly a 27,800× ratio between what the model needed and what shipped off the machine. The destination is a Google Cloud Storage bucket named grok-code-session-traces, staged under paths of the form gs://grok-code-session-traces/repo_changes_dedup/v2/…, not AWS S3 and not xAI infrastructure the way most users would assume.
The secrets story is worse. Files the agent read, including a canary .env with API_KEY=CANARY7F3A9-SECRET-should-not-leave and mock database credentials, showed up verbatim in the request bodies for both channels. On a SuperGrok account the /v1/storage upload was a git bundle, and running git clone against the captured bundle reconstructed a file the agent had been explicitly told not to open, src/_probe/never_read_canary.txt, with its unique marker intact. Toggling 'Improve the model' off changed nothing, since the /v1/settings endpoint still returned trace_upload_enabled: true.
The honest caveat is that this is one researcher's capture, and the author is careful about scope. The analysis explicitly does not prove xAI trains on the data, does not exhaustively test whether a hidden config flag could disable the upload, and lost some direct storage.googleapis.com PUT lines to a mid-stream truncation on the 12 GB run. What the reporting does not give you is a retention policy or a legal answer on where this sits relative to enterprise NDAs.
The useful takeaway for anyone shipping AI CLI tools right now: mitmproxy is cheap, canary files are cheap, and the market is starting to grade vendors on what actually crosses the wire rather than what the settings page says. If you sell a coding agent, expect this test to be run against you next.
What others are reporting
-
International Cyber Digest Read →
Focuses on xAI's institutional non-response: no advisory, no changelog entry, no statement on data retention scope after the silent server-side mitigation.
The tool was not sending what it needed to answer the developer. It was sending the codebase.
-
ByteIota Read →
Adds concrete data-volume metrics and frames the issue as a consent failure rather than training-use speculation, with credential-rotation remediation steps.
5.10 gigabytes transferred in 73 chunks on a 12 GB repository...the storage channel sent 27,800 times more data than the model-turn channel.
-
Penligent Read →
Provides enterprise incident-response framework and detection signals, treating Grok Build as a case study for evaluating any AI coding agent's data boundary.
A Git bundle left the machine through /v1/storage. The storage request received HTTP 200. Cloning the captured bundle recovered the never-read marker.
-
ExplainX Read →
Separates proven facts from speculation, confirms the July 13 server-side mitigation, and identifies the missing DPA as the core product failure.
a reproducible test of Grok Build 0.2.93 on a consumer account captured successful uploads of complete tracked Git repositories
-
GitHub (cereblab) Read →
Transforms the gist into runnable tooling; proves permission-deny stops agent reads but does not stop the full-repo Git bundle upload.
A permission deny stops the agent READING a file into the chat; it does NOT stop the whole-repo git-bundle upload.
Shared on Bluesky by 1 AI expert
Originally reported by gist.github.com
Read the original article →Original headline: HN Front Page: 'What xAI's Grok Build CLI Sends to xAI' — Wire-Level Analysis Finds Grok Uploads Entire Repositories to `grok-code-session-traces` Google Cloud Bucket, Not Just Files the Agent Reads