AIArticle A wire-level capture of the official CLI gives teams a concrete privacy baseline before they point it at real code.
Mariana Souza AI coding agents that live in the terminal are convenient. They also sit on the most sensitive material most developers touch every day: source, secrets, git history, and the half-finished experiments nobody meant to share. A reproducible wire-level capture of xAI's official Grok Build CLI (version 0.2.93) makes the stakes concrete. On a normal consumer login, the tool does more than send the files an agent happens to open. It packages and uploads the whole repository, and it accepts the upload every time.
That is the baseline developers need before adoption. Not a rumor about training policy. Transmission, acceptance, and storage, measured on the wire.
What the captures actually show #
The independent teardown used mitmproxy against the real binary installed from xAI's install script, authenticated with a throwaway consumer SuperGrok login, and a canary repo full of fake secrets. Three findings hold up under that method.
First, files the agent reads go upstream verbatim. A .env
with planted canaries appeared unredacted in the live model turn on POST /v1/responses
and again inside a session-state archive accepted on POST /v1/storage
.
Second, the upload is not limited to what the agent reads. With the prompt "reply OK, do not read any files," the CLI still shipped the entire workspace as a git bundle. Cloning that captured bundle recovered a file the agent was told not to open (src/_probe/never_read_canary.txt
) plus full git history.
Third, the volume pins the intent. On a 12 GB tree of never-read random files, /v1/storage
moved 5.10 GiB (truncated mid-stream, all HTTP 200) while the model-turn channel moved 192 KB. That is roughly a 27,800× ratio. The only non-200s observed were a model-usage quota on /v1/responses
and one unrelated 404. No storage size cap appeared.
The destination is not abstract "telemetry." Strings in the binary and a captured metadata.json
name a Google Cloud Storage bucket, grok-code-session-traces
(`gs://grok-code-session-traces/…`
), reached through first-party Rust crates (`xai-data-collector`
, upload paths under `xai-grok-shell`
). Upload machinery is built in, not an optional plugin.
"Improve the model" does not turn this off #
That last point matters for anyone who treats product toggles as a control plane. Disabling "Improve the model" left /v1/settings
returning trace_upload_enabled: true
. The mechanism is active by default on a consumer login. The teardown author did not find it surfaced in the install or quickstart materials they checked (not claimed as an exhaustive docs audit).
None of this proves xAI trains on the data. That is a policy question, not a packet-capture question. What is proven is that the binary transmits, the service accepts, and the objects land in a named session-traces bucket. For a security or compliance review, transmission and retention already change the threat model. Training is a second conversation.
What this means for real adoption #
If you are evaluating Grok Build for day-to-day work, treat the CLI like any other tool that can reach production secrets, not like a local linter.
Who is affected. Anyone running the official binary against a real workspace: interactive TUI sessions, headless grok -p
automations, CI agents, and multi-worktree or subagent setups described in xAI's own docs. Consumer-auth flows (browser login to X / SuperGrok) are in scope for the capture. API-key-only environments may behave differently; that path was not the subject of this teardown, so do not assume either way without your own capture.
What actually leaves the machine.
-
Contents of files the agent reads, including env files, with no redaction observed
-
A full workspace package (tracked files plus git history) independent of tool-use, via
POST /v1/storage -
Session-state archives that can re-embed material already seen in model turns
Practical controls before you point it at anything real.
- Run it only against throwaway clones or worktrees that contain no production secrets, customer data, or private keys. Strip
.env*
, credential files, and large binary blobs first. - Prefer isolated VMs or containers with no access to your main keychain, SSH agent, or cloud credentials.
- If policy requires proof rather than trust, MITM your own traffic the same way: trust a local CA, route the binary, log method/host/path/status/bytes, and save request bodies for
/v1/responses
and/v1/storage
. The capture method is ordinary developer tooling, not reverse-engineering theater. - For teams that need Grok models without the official CLI's collection path, use the public
xAI APIfrom a tool you control, or evaluate community agents that speak the same API under your own networking and retention rules. Those choices shift responsibility back to your stack; they do not magically erase model-side logging, but they remove this particular default whole-repo upload path. - Document the residual risk for compliance. "We turned off Improve the model" is not a control if
trace_upload_enabled
stays true.
Trade-offs are sharp. You get a capable coding agent with TUI, headless mode, worktree-aware subagents, and ACP hooks for orchestration. In exchange you accept default full-workspace transmission to a GCS session-traces bucket unless you redesign the environment around the tool. That is a fine bargain for open-source experiments and greenfield toys. It is a harder sell for regulated monorepos, multi-tenant SaaS codebases, or any machine that still has yesterday's .env
sitting in the tree.
Where this sits in the agent stack #
Coding agents have been drifting toward "the whole workspace is context" for a while: IDE copilots, terminal agents, and multi-agent orchestrators all want more files, more history, more tools. Whole-repo upload is the logical extreme of that trend. The difference here is not the ambition. It is the default, the lack of an obvious off switch in the settings path that was tested, and the scale of the storage channel relative to the model turn.
If your team already treats every AI coding tool as an untrusted remote process with full filesystem read, this finding is confirmation, not surprise. If your mental model was "only what I @-mention leaves the laptop," update the model. The canary that was never opened still left in the git bundle.
For xAI, shipping a first-party collector and a named traces bucket is a product choice with clear engineering upside (debugging, evals, product improvement). For developers, the same choice means the install script is also a data-plane decision. Read it that way.
Bottom line #
Grok Build is interesting as an agent surface: headless runs, worktrees, subagents, and the same Grok models available on the API. The wire evidence on 0.2.93 says the cost of that convenience, on a consumer login, includes default upload of the full repository and unredacted secrets the agent touches, landed in grok-code-session-traces
and not disabled by the obvious product toggle.
Use it where that cost is acceptable and the workspace is scrubbed. Instrument it yourself if you need proof. And if your threat model cannot absorb whole-repo transmission to a third-party bucket, keep the model and leave the official CLI on the shelf until the control plane matches the marketing. The packets already told the story. The only open question is whether your next project directory is ready to be in that story.
Sources & further reading #
[What xAI's Grok build CLI sends to xAI: A wire-level analysis](https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547)— gist.github.com -
[Grok Build | SpaceXAI Docs](https://docs.x.ai/build/overview)— docs.x.ai -
[GitHub - superagent-ai/grok-cli: An open-source coding agent for the Grok API · GitHub](https://github.com/superagent-ai/grok-cli)— github.com
[Mariana Souza](https://sourcefeed.dev/u/mariana_souza)· Senior Editor
Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.
Discussion 0 #
No comments yet
Be the first to weigh in.