Grok Build CLI Privacy: Wire-Level Analysis Shows Full Codebase Uploads

Grok Build CLI privacy is not what the marketing suggests. A wire-level analysis published on 13 July 2026 shows that version 0.2.93 of xAI's terminal coding agent uploads entire repositories, including .env files with live secrets, to a Google Cloud Storage bucket named grok-code-session-traces. The behaviour persists even when the "Improve the model" setting is turned off, and it captures files the agent never opened during a session.

The short version: if you have run Grok Build against a repository that contains credentials, treat those credentials as exposed and rotate them.

TL;DR

• Grok Build CLI v0.2.93 uploads full repository contents to a GCS bucket, not just files the agent reads.
• On a 12 GB test repo, 5.10 GiB was transferred in 83 successful POST requests to /v1/storage.
• .env files with API keys and database passwords were sent verbatim, unredacted.
• The "Improve the model" opt-out does not stop uploads; the server still reports trace_upload_enabled: true.
• The storage channel moved roughly 27,800 times more data than the model-turn channel (5.10 GiB versus 192 KB).
• Zero Data Retention (ZDR) mode exists for enterprise teams but is not the default.

What did the wire-level analysis actually prove?

The analysis intercepted TLS traffic from the Grok Build binary (SHA-256 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c) and reconstructed payloads. Two channels emerged: a small model-turn channel for prompts and responses, and a larger storage channel that streamed working-directory archives to grok-code-session-traces.

To rule out "the agent uploaded what it needed," the researcher planted a canary file at src/_probe/never_read_canary.txt and told the agent not to read it. The file still appeared in the recovered git bundle. That distinguishes context-window traffic from bulk transmission and contradicts xAI's "local-first" marketing, which stated that nothing from a user's codebase is transmitted during a session.

The researcher scoped the finding carefully: the analysis proves transmission, acceptance, and storage; it does not prove training. Whether uploads train models is a policy question requiring different evidence.

What exactly is uploaded and where does it go?

The destination is a Google Cloud Storage bucket, grok-code-session-traces, not referenced in the CLI's install guide. Uploads are POSTed to /v1/storage; all 83 requests returned HTTP 200. The payloads include:

• Source files across the entire repository tree, not just files opened in the session.
• Dotfiles and configuration, including .env variants that typically hold API keys, database URLs, and signing secrets.
• Files that the agent was told, in-session, not to read.

The volume difference is the tell. On a 12 GB repository, the model-turn channel carried 192 KB — consistent with a normal chat exchange. The storage channel carried 5.10 GiB. A tool that only needs the files it reads does not send five gigabytes.

Does the "Improve the model" toggle stop uploads?

No. The setting appears as an opt-out for model improvement, and users have reasonably inferred it keeps code out of xAI's pipelines. In captured traffic, the server response still included trace_upload_enabled: true after the toggle was disabled, and storage POSTs continued.

The polite reading: the toggle governs a downstream stage, not transmission. The practical reading: it does not change what leaves your machine.

How does this square with xAI's enterprise privacy promises?

xAI's enterprise documentation describes a six-phase data lifecycle and offers Zero Data Retention as a team-level opt-in. ZDR, when active, prevents inputs and outputs from being persisted. The wire analysis does not contradict ZDR; it highlights that ZDR is opt-in, not default, and that CLI defaults do not match the "local-first" phrasing from launch materials.

For an individual developer on the standard tier: the CLI transmits full repository contents, the opt-out toggle does not prevent that, and a stricter mode exists but must be enabled at the enterprise level.

What should developers do right now?

Treat this as a credential-exposure incident for any repository you have run Grok Build against.

1. Rotate secrets in affected repos. Any keys, tokens, or database passwords in .env, .envrc, or config files should be considered leaked. Rotate them at the provider.
2. Run a secret scanner such as gitleaks or trufflehog over the working tree to find keys not in .env.
3. Purge sensitive fixtures. Test data, customer exports, and private notes committed to a working tree were in scope.
4. Enable ZDR if you are on an enterprise plan. It is not the default. See xAI's enterprise documentation.
5. Block egress at the network layer for coding agents until you have verified their traffic. A zero-trust AI gateway that mediates outbound requests is the durable answer.
6. For high-sensitivity work, prefer a local model. If your threat model rules out third-party transmission, a local AI setup is the honest option.

What does this mean for AI coding agents more broadly?

Grok Build launched in May 2026 as a terminal-native competitor to Claude Code and Cursor. The category depends on trust: the agent reads source to be useful, and users assume "reads" and "uploads" are the same set of files. This is the first widely publicised case where a wire capture disagrees with the marketing at that exact point.

The lesson is not "Grok Build bad, others good." Privacy claims from any coding agent should be verified at the network level, not accepted from a landing page. mitmproxy, Wireshark with SSL keylog files, or a controlled outbound proxy give a truer picture than a policy page. The same defensive posture that applies to AI-generated code applies to the agents that generate it.

Assume any agent with read access to a repo can transmit more than the files it references. Keep secrets in a manager rather than .env, keep customer data out of working trees, and read the loop-engineering approach to agents to understand what your tools do between prompts. If you are evaluating Grok 4.5 and other agentic setups, factor the network profile into the comparison, not only benchmark scores.

FAQ

Q: Does this prove xAI is training on my code? A: No. The analysis proves transmission, acceptance, and storage. Whether that data is used for training is a separate policy question not established by the network capture.

Q: Which Grok Build CLI version was tested? A: Version 0.2.93 (SHA-256 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c). Later versions may differ; the default install as of mid-July 2026 exhibits the uploads.

Q: Does turning off "Improve the model" stop the uploads? A: No. The captured server responses returned trace_upload_enabled: true with the toggle disabled, and storage POSTs continued. The setting appears to govern a downstream stage, not transmission.

Q: Are Zero Data Retention (ZDR) users affected? A: ZDR prevents persistence of inputs and outputs for enterprise teams that enable it. It is not the default for individual accounts. Even with ZDR active, transmission behaviour warrants independent verification.

Q: Should I stop using AI coding agents entirely? A: Not necessarily. Verify each tool's network behaviour, gate outbound traffic through a controlled proxy, and reserve sensitive repos for tools you have tested or for local models.

Q: How can I verify a coding agent's traffic myself? A: Route the agent through mitmproxy, install its CA certificate, and inspect payloads. Compare outbound bytes to files the agent should have read. Discrepancies are visible within a few sessions.