What exactly does Grok Build CLI upload to xAI?

The teardown shows Grok Build CLI 0.2.93 uploading two things: the raw contents of files the agent reads, including .env secrets, over POST /v1/responses, and the entire repository as a git bundle over POST /v1/storage. The storage channel accounted for 5.10 GiB in a single 12 GB test session while the model-turn channel moved only 192 KB.

Does turning off 'Improve the model' actually stop the uploads?

No. Cereblab flipped the 'Improve the model' toggle off and re-ran the CLI. The settings endpoint still returned trace_upload_enabled: true and the storage channel kept accepting chunked git-bundle uploads with HTTP 200. The documented opt-out path does not block the repository-scale transmission.

What's the practical risk for a developer using Grok Build CLI on private code?

The Grok Build CLI teardown shows unredacted API keys, database passwords, and every tracked file's history flowing to a Google Cloud bucket named grok-code-session-traces. Any secret sitting in a .env file or in git history is treated as normal payload, and xAI has not published a Data Processing Agreement covering how that bucket is retained or accessed.

What version of Grok Build CLI was tested, and does newer behave the same?

The wire capture is on Grok Build CLI 0.2.93. xAI shipped 0.2.97 on July 11 with unrelated developer-experience fixes; the disclosure does not test that build, and xAI has not publicly stated whether the whole-repo storage upload has been changed. Anyone on a later build should re-run the trace or wait for confirmation.

How is this different from what Claude Code or Cursor send?

The Grok Build CLI analysis explicitly compares its two channels and finds the ~27,800× storage-vs-model disparity is unique among the coding CLIs it has profiled. Claude Code and Cursor transmit selected file snippets on model turns; they do not stream the whole git bundle to a third-party cloud bucket independent of the agent's context window.

cereblab · 2026-07-10 · major

Grok Build CLI ships whole repos and .env secrets to xAI — wire-level teardown

Cereblab's wire-level analysis of Grok Build CLI 0.2.93 shows the tool uploads whole git repos plus unredacted .env secrets to a Google Cloud bucket, even when 'Improve the model' is off.

GitHub gist header — wire-level teardown of xAI Grok Build CLI 0.2.93

A wire trace of Grok Build CLI shows secrets and full repos leaving your machine even after you opt out.

Quick facts

Product tested	xAI Grok Build CLI 0.2.93
Where uploads land	GCS bucket grok-code-session-traces
Whole-repo upload	Yes, streamed as git bundles
12 GB test	5.10 GiB uploaded across 73 chunks
Model-turn vs storage	192 KB vs 5.10 GiB (~27,800×)
'Improve the model' off	No effect — uploads continue
xAI DPA on that bucket	Not published at disclosure time

What is it?

Grok Build CLI is xAI's official coding agent. The disclosure is a wire-level packet capture of version 0.2.93 that shows the tool posting file contents — including .env files with API keys and passwords — to two channels: a live model endpoint at POST /v1/responses and a session-state archive at POST /v1/storage that routes to a Google Cloud bucket called grok-code-session-traces.

How does it work?

Beyond the files the agent chooses to read, Grok Build CLI packages the entire repository as a git bundle and streams it up in ~75 MB chunks. In one recorded 12 GB test repo, the storage channel uploaded 5.10 GiB across 73 chunks while the model-turn channel moved only 192 KB — a ~27,800× disparity that rules out selective transmission.

Why does it matter?

Any team piping company code through Grok Build CLI has been shipping full history and secrets to xAI infrastructure without a way to stop it. Toggling 'Improve the model' off did not disable the upload — the server kept returning trace_upload_enabled: true — so the standard opt-out path is ineffective. xAI has not published a Data Processing Agreement covering the bucket.

Who is it for?

Any developer or org using Grok Build CLI on private repos.

Frequently asked questions

What exactly does Grok Build CLI upload to xAI?: The teardown shows Grok Build CLI 0.2.93 uploading two things: the raw contents of files the agent reads, including .env secrets, over POST /v1/responses, and the entire repository as a git bundle over POST /v1/storage. The storage channel accounted for 5.10 GiB in a single 12 GB test session while the model-turn channel moved only 192 KB.
Does turning off 'Improve the model' actually stop the uploads?: No. Cereblab flipped the 'Improve the model' toggle off and re-ran the CLI. The settings endpoint still returned trace_upload_enabled: true and the storage channel kept accepting chunked git-bundle uploads with HTTP 200. The documented opt-out path does not block the repository-scale transmission.
What's the practical risk for a developer using Grok Build CLI on private code?: The Grok Build CLI teardown shows unredacted API keys, database passwords, and every tracked file's history flowing to a Google Cloud bucket named grok-code-session-traces. Any secret sitting in a .env file or in git history is treated as normal payload, and xAI has not published a Data Processing Agreement covering how that bucket is retained or accessed.
What version of Grok Build CLI was tested, and does newer behave the same?: The wire capture is on Grok Build CLI 0.2.93. xAI shipped 0.2.97 on July 11 with unrelated developer-experience fixes; the disclosure does not test that build, and xAI has not publicly stated whether the whole-repo storage upload has been changed. Anyone on a later build should re-run the trace or wait for confirmation.
How is this different from what Claude Code or Cursor send?: The Grok Build CLI analysis explicitly compares its two channels and finds the ~27,800× storage-vs-model disparity is unique among the coding CLIs it has profiled. Claude Code and Cursor transmit selected file snippets on model turns; they do not stream the whole git bundle to a third-party cloud bucket independent of the agent's context window.

Try it

Reproduction repo: github.com/cereblab (see 'Reproduce that Grok Build CLI uploads your whole repo').