A Packet Capture Says xAI's Grok Build Uploads Your Whole Repo, Secrets Included, With the Opt-Out Off

TL;DR

A wire-level teardown published July 10 and now on the Hacker News front page claims that Grok Build, the coding-agent CLI from xAI, uploads far more than the context it shows you. In the author's capture of version 0.2.93, a 12 GB canary repository produced about 192 KB of visible model-turn traffic and 5.10 GiB of background uploads to a Google Cloud Storage bucket named grok-code-session-traces: never-read files, full git history, and unredacted .env secrets included. Toggling "Improve the model" off did not stop it. These are one researcher's findings, not yet independently reproduced, and xAI has not responded as of publication. But if you point closed-source agents at private code, the working assumption should be that the only privacy policy that counts is the one you can see in a packet capture.

The teardown

The analysis comes from a pseudonymous researcher, cereblab, who routed the grok binary (version 0.2.93, with the binary's SHA-256 published in the writeup) through mitmproxy to decrypt and log every HTTPS request the CLI makes. The methodology is the part that makes this worth your attention: instead of eyeballing traffic, the author seeded canary repositories with uniquely marked fake secrets, things like API_KEY=CANARY7F3A9-SECRET-should-not-leave, then grepped the captured wire traffic for the markers.

The sweep ran across repo sizes from 64 MB up to 12 GB, and the writeup preserves its receipts: captured request bodies, upload logs, and git bundles pulled straight off the wire.

Two channels, one visible

The core claim is architectural. Grok Build talks to xAI over two distinct channels. Channel one is POST /v1/responses: the ordinary model turns, carrying your prompt and whatever file snippets the agent decides to read. That is the traffic you would expect, and it stayed small in every test. Channel two is POST /v1/storage: background uploads of archived session_state and repo state, which the capture shows landing in a Google Cloud Storage bucket. The binary itself contains the strings grok-code-session-traces, storage.googleapis.com, and "Uploading bytes to GCS via proxy".

It is the difference between a contractor walking through the two rooms you hired them to renovate, and their van leaving every night loaded with photographs of every room in the house, including the ones they never entered. You only ever see the contractor.

The numbers

The headline experiment used a 12 GB repository of random files the agent was never asked to read and never touched. Per the preserved logs, the model-turn channel carried 196,705 bytes for the whole session, roughly 192 KB. The storage channel carried 5,476,228,005 bytes, about 5.10 GiB, in chunked uploads of roughly 75 MB apiece, every one of them acknowledged with HTTP 200. That is a factor of about 27,800 between what the session looked like and what actually left the machine.

Two details push this past "telemetry is chatty". First, the capture includes git bundles leaving via POST /v1/storage; cloning those bundles back out recovered the never-read canary files verbatim, full git history attached. Second, the fake .env secrets showed up unredacted in both channels, in a model-turn request body and inside the archived session state. Grok never opened most of those files. They made the trip anyway, which is a level of thoroughness the agent itself rarely gets accused of.

The toggle that doesn't toggle

Grok Build has an "Improve the model" setting, the thing a reasonable person would flip off and consider the matter closed. In the capture, turning it off changed nothing about the uploads: the CLI's /v1/settings response still reported trace_upload_enabled: true, and the repository archives kept flowing. It is possible the toggle governs training consent server-side while the transport keeps running regardless. The capture cannot see xAI's backend; it can only see that the bytes departed.

What xAI actually promises

xAI's API security FAQ is clear about the API side: "xAI never trains on your API inputs or outputs without your explicit permission", requests and responses are stored for 30 days for abuse auditing and then automatically deleted, and enterprise customers can enable Zero Data Retention so nothing persists at all.

The catch is scope. Grok Build is an early-beta product sold through SuperGrok and X Premium Plus subscriptions, the consumer side of the house, and the security FAQ does not mention the CLI at all. Whether repository archives in a session-trace bucket count as "API inputs" under that policy, and whether the 30-day deletion clock applies to them, is exactly the kind of question the documentation does not currently answer.

To be precise about what the gist does and does not show: storage is not training. Nothing in the capture demonstrates that xAI trains on the uploaded code, and the author says so explicitly. But 5 GiB of your repository sitting in a vendor's bucket is a data-governance fact all by itself, whatever happens to it afterward.

The caveats, straight

• This is a single researcher's capture, published under a pseudonym. As of publication, nobody in the HN thread has reported an independent reproduction, and xAI has not responded.
• The findings are version-specific to grok 0.2.93. A point release could change any of this behavior, in either direction.
• Some observations, like direct storage.googleapis.com PUTs during the 3 GB run, were seen but not preserved as artifacts; the author flags this.
• Server-side retention or deletion is invisible to a packet capture. The uploads could be short-lived. They could also not be.

What you should do about it

The good news is that the methodology is the remedy, and it is not exotic. The gist's approach reproduces in about twenty minutes for any agent CLI you use: install mitmproxy, trust its CA, set HTTPS_PROXY, point the agent at a throwaway repo seeded with canary strings, and grep the flows. If a vendor's story and your capture disagree, believe the capture.

Beyond auditing, the standing hygiene applies with new force. Treat closed-source agent CLIs as egress pipelines and run them in containers or VMs with allowlisted network access when the code is sensitive. Keep real credentials out of the working tree entirely and inject them at runtime, because an agent that can read your filesystem will eventually put your .env somewhere you did not expect. And weight open-source harnesses more heavily for private work: you can read what they send before you run them.

Key Takeaways

• A mitmproxy teardown of xAI's Grok Build CLI (v0.2.93) claims a 12 GB canary repo produced 192 KB of model traffic and 5.10 GiB of background uploads to a GCS bucket, a roughly 27,800x gap.
• Recovered git bundles contained files the agent never read, with full history; seeded .env secrets crossed the wire unredacted.
• Turning "Improve the model" off did not stop the uploads in the capture; settings still reported trace_upload_enabled: true.
• xAI's API security FAQ promises 30-day retention and no training without permission, but does not mention Grok Build, which ships via consumer subscriptions.
• The findings are unreproduced so far and xAI has not responded; treat them as one rigorous capture, not settled fact.
• Canary repos plus mitmproxy are a twenty-minute audit you can run on any coding agent you use. Consider running it.

Sources: cereblab's wire-level analysis (GitHub gist), Hacker News discussion, xAI API security FAQ, Grok Build documentation, mitmproxy