Grok Build CLI Secretly Uploads Your Entire Repo to xAI

A security researcher published wire-level proof this week that xAI's Grok Build CLI uploads your entire Git repository to a Google Cloud Storage bucket, independent of the files the coding agent actually reads. The teardown, posted by a researcher known as cereblab after routing Grok Build 0.2.93 through a proxy on macOS, is damning because it does not rely on guesswork: it captured the traffic, cloned the uploaded bundle, and recovered a file the agent had been explicitly told not to open. Our read is blunt. This is the exact gap between marketing and behavior that erodes trust in AI coding tools, and if you have run Grok Build on a repo with secrets, you should treat those credentials as exposed.

• Grok Build runs two channels at once: the expected model-turn request, and a hidden background upload of the whole workspace as a Git bundle to a bucket named grok-code-session-traces.
• On a 12 GB test repo the model needed 192 KB of context, but 5.10 GiB left the machine across 73 chunks, roughly a 27,800x ratio between what was needed and what shipped.
• A planted .env secret appeared verbatim in the captured traffic, and the "Improve the model" toggle did not stop the upload because it only governs training consent.
• xAI marketed Grok Build as "local-first" with nothing transmitted during a session, a claim the wire capture directly contradicts.

What did the researcher actually capture?

cereblab ran Grok Build 0.2.93 through mitmproxy on macOS and watched every request the client made. The first channel was unremarkable: when the agent reads a file, that file goes into a POST /v1/responses request so the model has context, exactly like any API-based assistant. The second channel is the problem. In parallel, the client fires a POST /v1/storage request that carries the entire tracked workspace, packaged as a Git bundle, to a Google Cloud Storage bucket named grok-code-session-traces under paths like gs://grok-code-session-traces/repo_changes_dedup/v2/. On a 12 GB repository, the model-turn channel moved 192 KB while the storage channel moved 5.10 GiB across 73 chunks of about 75 MB each, every one returning HTTP 200. That is a roughly 27,800x gap between what the task required and what left the machine.

RelatedZimbra Patches Stored-XSS RCE in Classic Web Client

How do we know it ignores the agent's instructions?

This is the detail that turns a telemetry complaint into a genuine finding. The researcher ran a session with the prompt "reply OK, do not read any files." Grok replied, and it still uploaded the repository as a Git bundle. Cloning that captured bundle recovered src/_probe/never_read_canary.txt, a file the agent was told not to open, with its unique marker intact, plus the full commit history. The upload is not a side effect of what the model reads. It is a separate, always-on mechanism that packages whatever Git tracks, regardless of what you ask the agent to do. Only files excluded by .gitignore stayed off the wire.

Why is the secrets exposure the real damage?

Because coding repos routinely contain credentials, and the capture shows they leave unredacted. cereblab planted a canary key, API_KEY=CANARY7F3A9-SECRET, in a .env file and found it verbatim in the captured traffic, appearing both in the live model turn and in the uploaded session archive. If Grok Build could reach a real .env, the safe assumption is that those values crossed the network. That means the mitigation is not deleting the local file, it is rotation: revoke and reissue API keys, database passwords, cloud tokens, signing secrets, and webhook credentials for any repo you touched with the tool. A deleted file does not un-expose a key that already shipped.

Doesn't the privacy toggle cover this?

No, and that is the trap. Grok Build ships an "Improve the model" control that most developers read as "do not send my data." The capture shows it governs training consent only. With the toggle off, the server response still carried trace_upload_enabled: true and the Git-bundle upload continued. Worse, the behavior is undocumented: community reverse-engineering surfaced two suppression flags, disable_codebase_upload=true and trace_upload=false, that appear nowhere in xAI's official setup materials. A privacy control that does not control the privacy-relevant behavior is arguably worse than none, because it manufactures false confidence.

1. Jul 8 2026Grok Build ships with Grok 4.5. Marketed as "local-first," with nothing from your codebase transmitted during a session.
2. Jul 12 2026cereblab publishes the wire capture. mitmproxy teardown, canary recovery, and a public reproduction harness on GitHub.
3. Jul 12 2026Silent server-side mitigation. Retesting the same client, the server began returning disable_codebase_upload: true; the storage uploads stopped.
4. Jul 13 2026Changelog shows 0.2.98. No release note describes the finding, the new flag, or whether earlier uploaded data was deleted.

Who is affected, and what should they do?

Anyone who ran Grok Build 0.2.93 on a repository with tracked secrets, private source, or client code under NDA. The practical exposure is broadest for teams: a single developer session can lift an entire monorepo and its history. Because the client binary did not need to change for the behavior to stop, a version number is not a reliable safety signal here; two runs of the same binary on different days can behave differently based on server config. For regulated teams the compliance angle is sharp too, since there is no published Data Processing Agreement or EU data-residency option for Grok Build, which leaves European users without a clean legal path under current conditions.

RelatedAdobe ColdFusion Patches 11 Critical Bugs, 6 Rated 10.0

What is the honest scope of the finding?

The researcher was careful, and so are we. The capture proves a full Git repository crossed the network independent of the task. It does not prove xAI trained on that code, that employees viewed it, that every account received the same configuration, or that untracked files were swept up. The grok-code-session-traces name suggests session continuity or debugging telemetry as the likely purpose. The core problem is not what xAI did with the data after it arrived, it is that developers had no reasonable way to know it was leaving at all, while the marketing said the opposite.

Our take

The technical severity here is real but recoverable: rotate your secrets, scope future agent sessions to a temporary directory that holds only the files a task needs, and verify what leaves the boundary. The harder damage is to trust. "Local-first" is a specific promise, and a background channel that ships your whole repository plus unredacted secrets is the precise opposite of it. That the fix was a silent server flag rather than a published advisory makes it worse, because users cannot audit a mitigation they were never told about. AI coding tools are earning enormous access to the most sensitive thing developers own, their code and their keys. The minimum price of that access is telling people, in plain language and in the setup docs, exactly what crosses the wire. Grok Build failed that test, and a quiet patch does not pass it retroactively.

Original analysis by GenZTech. Reporting informed by GIGAZINE.