Grok Build CLI uploaded entire private repos to xAI. What actually happened.

On July 13, 2026, a researcher going by cereblab published a wire-level teardown of Grok Build CLI, xAI's terminal coding agent. Routing the tool through a local proxy, they showed it shipping far more than a prompt and a few files to xAI's servers. It sent the whole repo. This is the verified version of that story, the parts that are still open, and why it is the cleanest argument we have seen this year for running your AI on your own machine.

What did Grok Build CLI actually upload?

The whole repository, including files it was never asked to read and secrets in your .env, was packaged and sent to an xAI-controlled cloud bucket. The evidence is a reproducible harness, not a single screenshot: a canary git repository, an intercepting proxy, and downloadable capture files anyone can replay. Here is what it showed for grok 0.2.93:

• The whole repository left the machine. Grok Build CLI packaged the full repo, every tracked file's contents plus git history, as a bundle and sent it via POST cli-chat-proxy.grok.com/v1/storage to a Google Cloud Storage bucket named grok-code-session-traces.
• It uploaded even when told not to read files. With the literal prompt “reply OK, do not open any files,” the bundle still went out. The deny controls block the model from reading files; they do not block the separate upload.
• Secrets went up unredacted. A planted .env holding a canary API key appeared verbatim in the request body. A file the agent was explicitly never asked to read was recoverable by cloning the captured bundle.
• The volume was wildly out of proportion. In one capture the tool uploaded roughly 5.10 GiB when about 192 KB was all the model actually needed to respond. This was not “the context it read.” It was the repository.

Why didn't the opt-out stop it?

Because the “Improve the model” toggle controlled training consent, not whether your code was transmitted at all. This is the part that should bother developers most. It is the kind of setting you flip off precisely to keep your code to yourself. In the researcher's tests, disabling it did not stop the upload, and the app's own settings endpoint still reported that uploads were enabled. Those are two different promises, and the gap between them is where the trust breaks. You did the responsible thing, the UI told you it was handled, and the repository left anyway.

Does this mean xAI is training on my code?

No. The capture proves the code was transmitted to and stored by xAI, not that xAI trains on it, which is a separate policy question the wire data cannot answer. We are careful here because overclaiming would be its own kind of dishonesty, and the researcher says so directly. The bucket is named for session traces, which is consistent with debugging or session-continuity telemetry rather than a training pipeline.

A few more honest boundaries:

• This is the Grok Build CLI, the coding agent, not the Grok chat app or the website. Do not conflate them.
• Sending code to a server is by design for any cloud coding agent. The story is not that an upload happened. It is the scope (the entire repo and its secrets, not just what was needed), the silence (no clear disclosure), and the broken opt-out.
• xAI appears to have disabled the full-repo upload server-side roughly a day after the disclosure, adding a configuration flag to turn it off. As of this writing there is no formal public statement from xAI, and no word on what happens to code already collected.

Why this is a local-first argument, not a Grok argument

It is tempting to file this under “xAI did a bad thing.” That is too small. The real problem is structural: when your coding agent runs against someone else's cloud, a privacy setting is a promise, and a promise can be misimplemented, quietly changed, or scoped differently than you assumed. You are trusting a checkbox to accurately describe what a binary does over the network, and here the checkbox was wrong.

A local-first tool removes the promise from the equation. If the model runs on your machine with your own keys, there is no session-trace bucket, because there is no server to trace to. You cannot misconfigure an upload that the architecture does not perform. This is the same reason we keep coming back to it: cloud AI tools train on your code by default and make you hunt for the opt-out, and the opt-out only works if the vendor wired it up honestly.

A local-first CLI that has nowhere to upload your code

The fix for a coding CLI that ships your repo to a cloud bucket is a coding CLI that runs the model on your machine. That is the bias behind Bodega One Code: a local-first desktop IDE and terminal CLI with AI chat and an autonomous agent, 10+ LLM provider presets including fully local models, and an air-gap mode that enforces zero network egress at the process level. When the machine is air-gapped, a run cannot reach the network, so there is no grok-code-session-traces equivalent to audit or opt out of. Your code stays where you wrote it because there is nowhere else for it to go.

The parallel is exact. Grok Build is a terminal coding agent, and so is the Bodega One Code CLI (v0.1.0): an interactive TUI or fully headless runner for CI, sharing one brain with the desktop app so your providers, keys, and sessions carry over. The difference is where the model runs and where your repo goes. You can install it with one line:

curl -fsSL https://github.com/BodegaoneAI/bodegaone-cli-releases/releases/latest/download/install.sh | sh

Windows, macOS, and Linux installs and the full command reference are on the CLI docs. Honest caveat, since this whole post is about not taking claims on faith: Bodega One Code is in open beta and it is not open source, so “trust the architecture” still means trusting our binary. The difference a local-first, bring-your-own-model design makes is that the privacy claim is testable the same way cereblab tested Grok: put it behind a proxy in air-gap mode and watch for egress. There should be none. If you want a fully open-source setup instead, Aider or opencode pointed at a local model through Ollama is a solid path, and we will happily tell you so.

What to do if you use Grok Build CLI (and should you rotate keys?)

Yes, rotate any credentials that lived in a repo you opened with it, update the CLI, and treat any cloud tool's data toggle as a training setting rather than proof your code stays local. In order:

1. Update the CLI so you have the server-side change, and check for the disable_codebase_upload configuration flag the fix introduced.
2. Rotate any secrets that lived in a repo you opened with it, especially anything in a committed or untracked .env. Treat those keys as exposed.
3. Assume the “Improve the model” style toggle is about training, not transmission, in any cloud tool, until a network capture proves otherwise.
4. For anything sensitive, run the model where the code lives. A local-first or air-gapped setup, whether that is Bodega One Code or an open-source stack, turns this class of incident into a non-event.

Sources

• github.com/cereblab/grok-build-exfil-repro - reproducible harness, canary repo, and capture files
• cereblab - “What xAI Grok Build CLI actually sends: a wire-level analysis (grok 0.2.93)”
• IBTimes UK - “Security concerns as xAI Grok Build CLI uploads git repositories” (July 13, 2026)
• International Cyber Digest - “xAI's Grok Build CLI uploads entire git repositories to a Google Cloud bucket”
• Hacker News - discussion thread on the Grok Build CLI disclosure