You run a coding agent in your terminal. It reads files, edits code, runs commands. You assume it only sends what it needs to the model: the files it touched, the prompt it is working on. That is a reasonable assumption. It was also wrong if you used Grok Build before July 13.

A security researcher publishing as cereblab ran version 0.2.93 through a mitmproxy and caught something that should never happen. Every session opened two channels: one to the model at /v1/responses carrying about 192 KB of task data, and a second to /v1/storage that uploaded 5.10 gigabytes in 73 chunks of roughly 75 MB each. The ratio is 27,800 to one. That second channel was a Git bundle: every tracked file, every commit, every deleted-but-still-in-history secret, all packaged and shipped to a Google Cloud Storage bucket named grok-code-session-traces.

Data exfiltration comparison: Grok Build vs other coding agents in per-session upload volume

The wire does not lie

The difference between Grok Build and every other terminal coding agent is not subtle. The researcher planted a file named never_read_canary.txt with explicit instructions not to open it. Claude Code, Codex CLI, and Gemini each transmitted only what their agents touched, roughly the expected ~192 KB. Grok Build sent the whole repository. The captured bundle cloned back the canary verbatim along with the repo's full commit history.

This is not a bug in an edge case. On a 12 GB repository where the model never read a single file, the storage channel moved 5.10 GB while the model channel transferred 192 KB. A 27,800x gap between what the model needed and what left the machine is a design decision, not a glitch.

The secrets path is worse. When Grok Build read a tracked .env file during a task (standard behavior for a coding agent) the unredacted API_KEY and DB_PASSWORD values went into both channels. The model got them and the storage bucket got them. The researcher used fake secrets in the test. Real developers using the tool before July 13 had real credentials transmitted with no redaction and no warning.

The toggle that toggled nothing

Grok Build ships with an "Improve the model" toggle. Disabling it reads like a data-sharing opt-out. It did nothing. The server's /v1/settings response kept returning trace_upload_enabled: true, and the full repository upload ran regardless. Whether you opted in or out, your code left the machine.

The training-consent control and the data-transmission control are architecturally separate in Grok Build's design. Only one of them was exposed to the user. The other was silently on by default with no user-facing switch.

When xAI responded, company staff directed affected users to run the /privacy CLI command. cereblab corrected this publicly: the /privacy command is a per-session retention toggle that governs what happens to data after it arrives at xAI's servers. It has no effect on whether your repository is transmitted in the first place. What actually stopped the uploads was a server-side flag named disable_codebase_upload: true that xAI flipped globally on July 13.

A toggle for the toggle, set by xAI, not by the developer.

What the Git bundle carried

The upload format matters. A Git bundle is a single file that contains every version of every tracked file. A secret you committed six months ago and deleted from the working tree last month is still in the bundle. It sat in the commit history, bundled into the binary, shipped to xAI's Google Cloud bucket.

Standard remediation advice (deleting the file, rotating today's keys) does not cover this. If a credential was ever committed to a tracked file in a repository you ran Grok Build on, assume it was transmitted. That includes API keys rotated months ago, database passwords replaced twice over, SSH keys you thought were only in one old commit.

The TechTimes analysis pointed out something the raw volume numbers miss: the Git bundle format makes the exposure retroactive to the entire history of the repository, not just its current state.

Open source as damage control

Two days after the wire capture hit the front page of Hacker News, xAI published 844,530 lines of Rust under Apache 2.0 on GitHub. The open-source release is a meaningful transparency step: the code is real, the architecture is legible, and you can now verify exactly how the agent loop works, how tool calls are dispatched, and how extensions load.

But the upload code is still there. The file gcs.rs contains the full Google Cloud Storage upload infrastructure. The function upload_session_state() returns a hardcoded error, disabled at the function level, not removed. The code is held off by the server-side flag, not eliminated from the client. xAI controls that flag and can re-enable the behavior for any or all users without pushing a software update.

What this means for the rest of them

The wire-level comparison matters beyond Grok Build. Claude Code, Codex CLI, and Gemini did not ship full repositories in this test. None showed the parallel storage channel. Grok Build was the documented outlier. But "local only" is the wrong mental model for any cloud-grounded coding agent. Every tool in this category sends files to a remote model. The question is the boundary: what exactly leaves your machine.

cereblab's comparative methodology sets a useful baseline. Every AI coding tool should be tested the same way. If you are using any of these agents on a repository with sensitive code or credentials, run your own mitmproxy test. Trust the wire, not the marketing.

Elon Musk promised full deletion of all uploaded user data. xAI has not provided an affected-user count, a deletion audit, or a mechanism for individual developers to verify their data was purged. The company has not explained why full repositories were uploaded by default, how long they were kept, or how many users were affected. The transparency gap that made the upload scandal consequential is still the same gap that makes the remediation hard to trust.

Sources