gist.github.com via Hacker News

xAI Grok CLI Uploads Full Repos and Secrets, Opt-Out Ignored

TL;DR

  • On a 12 GB repo, Grok CLI's /v1/storage channel moved 5.10 GiB across 73 chunks while model turns used only 192 KB, a ~27,800× ratio.
  • Full repositories, including files the agent was told not to open, upload as git bundles to a Google Cloud Storage bucket named grok-code-session-traces.
  • Toggling 'Improve the model' off does not stop the codebase upload; /v1/settings still returns trace_upload_enabled: true.

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.