What xAI's Grok Build CLI Actually Sends Home: A Wire-Level Analysis

A security researcher at Cereblab ran xAI's Grok Build CLI through a proxy and captured everything it sends home. The findings are raising serious questions about what coding agents do with your codebase.

What the Research Found#

The wire-level analysis, published as a GitHub Gist and discussed extensively on Hacker News, documents three primary data transmission behaviors in Grok Build CLI version 0.2.93.

Finding 1: Unredacted File Contents Transmission#

The CLI transmits file contents to xAI servers without redaction. This includes .env secrets files. The researcher captured traffic showing API keys and database passwords appearing verbatim in both the live model-turn channel (POST /v1/responses) and in persisted archives uploaded via POST /v1/storage.

This is the baseline expectation for any coding agent - it needs to see your code to help you write it. But the scope of what gets transmitted goes much further.

Finding 2: Whole-Repository Upload at Scale#

Beyond files the agent actively reads during your session, Grok uploads entire repository snapshots independent of what code it actually processes.

The numbers from the researcher's testing:

• A 12 GB repository generated 5.10 GiB of uploads across 82 storage requests
• All requests returned HTTP 200 success codes
• The model-processing channel used 192 KB while the storage channel used 5.10 GiB - a ~27,800x difference

The researcher proved the upload captures the full codebase by cloning the git bundles uploaded via POST /v1/storage and recovering files that were never read during the agent session.

Finding 3: Google Cloud Storage Destination#

The uploads land in a GCS bucket called grok-code-session-traces. The researcher identified this through binary strings in captured traffic, metadata inspection, and direct observation of GCS PUT requests.

What HN Is Saying#

The discussion on Hacker News has been substantial, with several key threads emerging.

One commenter suggested a benign explanation: uploading the full codebase lets the model inspect it during "thinking" without round-tripping back to the client for tool calls. Others pointed out this is a weak justification given the privacy implications.

The security-conscious crowd is recommending sandboxing approaches. One detailed comment described using bubblewrap to isolate coding tools so they can only read the working project directory with .git read-only and sensitive directories hidden, plus network namespace isolation that only allows connections to specific LLM provider hostnames.

Several commenters noted the timing irony - concerns about Chinese AI companies copying code have been prominent, while a US-based company is uploading entire repositories without clear disclosure.

A Grok user shared that there is apparently a config option to disable this:

[harness]
disable_codebase_upload=true

However, the researcher's analysis found that even with the "Improve the model" toggle disabled in the UI, the server still returned trace_upload_enabled: true. The relationship between these settings is undocumented.

The Broader Pattern#

This research lands in a context of increasing scrutiny on coding agent telemetry. Earlier analysis comparing Claude Code and OpenCode found significant differences in how much data different harnesses send before even reading your prompt.

The tension is fundamental: coding agents need context to be useful, but the boundary between "context for the current task" and "persistent data collection" is not always clear - or clearly communicated.

As one HN commenter put it: "With all the coding agent options, you're choosing to trust your computer, code, and business to whichever harness, model, and provider you pick. It's not a great state of affairs, but that's where we are. Choose wisely."

Practical Takeaways#

If you're using Grok Build or evaluating coding agents generally:

Check configuration options. The disable_codebase_upload=true setting exists, though the researcher's findings suggest server-side behavior may not fully respect client preferences in all cases.

Separate credentials from code. Never store production secrets in .env files within repositories that coding agents access. Use external secret managers, environment variable injection at runtime, or at minimum keep credentials in gitignored files outside the project directory.

Consider network isolation. Tools like bubblewrap can restrict which hosts coding tools can reach. This doesn't prevent data transmission to the LLM provider, but it can limit unexpected communication with other services.

Prefer open-source harnesses with API access. Tools like OpenCode let you use models via their API while maintaining more control over what leaves your machine. The tradeoff is potentially reduced performance compared to native agent runners with custom optimizations.

Audit what you're sending. If you're working with sensitive code, run your coding tools through a proxy periodically and review the traffic. The researcher used mitmproxy; Charles Proxy and Proxyman are other options.

The Trust Question#

This analysis highlights a gap in the current coding agent ecosystem. Users are making implicit trust decisions without full information about what data leaves their machine.

The technical capability exists to upload anything a tool can access. The question is what policies and disclosures are in place, and whether those policies are actually enforced at the protocol level.

For Grok Build specifically, the mechanism for repository uploads was undocumented in CLI setup materials the researcher reviewed. That's the core issue - not that data collection happens, but that the scope of data collection exceeds what users reasonably expect based on available documentation.

Until coding agents standardize around transparent telemetry disclosure - perhaps through required data manifests or auditable upload logs - the burden falls on developers to verify tool behavior independently.

Sources#

• Original wire-level analysis (GitHub Gist)
• Hacker News discussion