Grok Build CLI uploads private repos and secrets to cloud

The core finding is not that a coding agent read a sensitive file. It is that a second, separate pipe exists. Grok Build CLI opens two distinct network paths: a POST /v1/responses channel that carries the normal model-turn traffic, and a POST /v1/storage channel that bundles the entire tracked Git repository, full commit history included, and ships it as git bundles to a Google Cloud Storage bucket literally named grok-code-session-traces ^[1]. The second path fires independent of what the agent actually reads. To prove this was not merely the model ingesting whatever it happened to open, the researcher planted a canary .env file containing the string API_KEY=CANARY7F3A9-SECRET-should-not-leave that the agent was never instructed to open, then recovered that exact string, verbatim, inside the captured upload body ^[1].

That detail is what upgrades this from a privacy complaint to a demonstrated exfiltration. A file the agent never touched still left the machine. Files the agent did read, including real secrets, were transmitted unredacted, appearing in both the live model turn and a session_state archive pushed through the GCS bucket ^[2]. The bucket's name suggests intent: it was built to capture full session context as training or debugging traces, not to send only the handful of files relevant to the task at hand ^[1].

The scale gap is what makes this hard to wave away as telemetry. On a 12 GB test repository, the /v1/storage channel moved 5.10 GiB across 73 chunks of roughly 75 MB each, every one returning HTTP 200 ^[1]. The model-turn channel that actually did the coding work moved about 192 KB. That is the storage pipe hauling away roughly 27,800 times more data than the task itself required ^[3]. As one commenter distilled it, you pay for 192 KB of work and they haul away 5.1 GB of your code.

Crucially, this is a wire-level packet capture, not speculation about what a binary might do. The measurements came off mitmproxy intercepting the traffic on the actual client, version 0.2.93 ^[1]. When skeptics on Reddit argued the reporting was biased against xAI, the reproducible rebuttal was that a packet capture has no opinions. The numbers are not an interpretation of behavior; they are the behavior, recorded on the wire.

Grok Build shipped with an 'Improve the model' toggle, the kind of control a careful developer flips off before pointing an AI at proprietary code. It did nothing to stop the leak. With the toggle disabled, the full repository still uploaded via /v1/storage, and the settings endpoint still returned trace_upload_enabled: true ^[4]. The toggle governed whether your data trained future models. It did not gate the upload channel at all ^[4]. Disabling it changed nothing about whether your code left the machine.

This is the gap between a consent control and an actual data boundary. Penligent noted that the tool's local-first positioning, the promise that nothing is transmitted during a session, was flatly contradicted by the capture once the .env and the full repo were seen leaving ^[3]. For an enterprise buyer, the lesson is uncomfortable: the visible privacy switch was decoupled from the code-egress path, so the one control users could see was not the one that mattered.

The most important comparison came from re-running the identical wire test against the other major coding agents. The researcher, posting the capture in r/LocalLLaMA, ran the same setup on Claude Code, Codex, and Gemini. All three kept the codebase local. Grok Build was the only one uploading everything. That single control experiment is what separates this from a general anxiety about AI dev tools and pins it to one product's design choice. The technical crowd on Reddit responded by reproducing the capture and rotating their credentials; a broader audience read it as confirmation of existing distrust of xAI, and a contrarian minority tried to blame users for not sandboxing, a framing the reproducers rejected since the tool was marketed as safe to run locally.

The fix xAI applied deepens rather than resolves the concern. A day after disclosure, the same client began receiving disable_codebase_upload: true from the server, and repository uploads stopped across six retests ^[2]. But the flag is server-controlled and undocumented, which means the behavior was flipped remotely and invisibly, the same way it could presumably be flipped back ^[2]. On X, the account that broke the story summarized the unresolved half: the uploads quietly stopped via a hidden server-side flag, and xAI still had not said a word about scope, retention, or whether repositories already sitting in grok-code-session-traces would be deleted. (Note: separate community reports of 8 fully uploaded private repos and a session where the upload path was a user's entire home directory circulated on X but were not independently confirmed by the primary wire-level capture, and should be treated as unconfirmed.)