By ByteBot
xAI’s Grok Build coding CLI spent weeks silently packaging developers’ entire Git repositories — full commit history, deleted credentials, files the AI was never asked to open — and shipping 5.1 gigabytes of it per session to a Google Cloud Storage bucket. A security researcher caught it on July 12. xAI server-side disabled the upload on July 13. By July 15, they had open-sourced the entire agent harness. That 72-hour arc says more about AI coding tool accountability than any privacy policy ever will.
What Was Actually Being Uploaded
Security researcher cereblab routed Grok Build CLI v0.2.93 through mitmproxy and watched two simultaneous network channels fire on every session. The first went to POST /v1/responses and carried roughly 192 KB of actual task content — the code context the model needed to do its job. The second went to POST /v1/storage and uploaded 5.10 GiB across 73 chunks to gs://grok-code-session-traces/. That is a 27,800x ratio between what the task required and what xAI’s servers received.
The upload was a Git bundle — meaning it contained every tracked file plus the repository’s complete commit history. To verify scope, cereblab planted a canary file at src/_probe/never_read_canary.txt and instructed the agent never to open it. It appeared in the captured bundle. Files the AI hadn’t touched, commit history from months ago, .env files with API keys — all of it went. The Hacker News documented the full technical breakdown.
The Privacy Toggle That Did Nothing
This is the part that should concern you more than the upload itself. Grok Build had a visible “Improve the model” setting — the standard opt-out that developers reasonably assumed controlled data collection. It did not stop the upload. The upload was controlled by a completely separate, invisible server-side flag: disable_codebase_upload: true. xAI flipped that flag on July 13 and the uploads stopped — no client update required, which also means no client update is required to re-enable them.
Building a privacy control that doesn’t control the actual data collection isn’t a UX oversight. It’s a design choice that decided users didn’t need to know the difference.
If You Ran Grok Build Before July 13
Treat everything in your tracked files and commit history as potentially compromised. That means:
- Rotate all API keys, database passwords, cloud tokens, and webhook secrets — including ones you deleted from working files months ago, because Git history doesn’t forget
- Check for SSH keys or service account credentials committed at any point in the repository’s history
- Audit any repo you ran Grok Build in for credentials that appear anywhere in
git log --all --full-history - Do not wait on xAI’s deletion promise — no certificate, audit log, or third-party attestation has been published to verify it
Simon Willison reported that at least one user ran the tool in their home directory, exposing SSH keys, a password manager database, and personal files. If you ran it anywhere outside a clean, credential-free project directory, that scope applies to you.
What the Open Source Release Actually Gives You
xAI published the Grok Build source at github.com/xai-org/grok-build under Apache 2.0 on July 15 — roughly 840,000 lines of Rust covering the CLI, terminal UI, agent runtime, and tool layer. The practical benefits are real:
- Auditable: You can read exactly what the agent sends and receives
- Local inference: Point it at Ollama or any OpenAI-compatible local server via
~/.grok/config.toml— zero cloud traffic if you want it that way - Self-compile: Build from source with
cargo run -p xai-grok-pager-binon macOS or Linux
The limits are equally real. Grok 4.5 remains a closed model — you can audit the harness that talks to the model, not the model itself. The upload code is still present in the published codebase, disabled by a server flag that xAI controls. External pull requests are not accepted; the public repository is a read-only window into internal development. Appwrite’s technical breakdown covers the full architecture in detail.
Project lead Andrew Milich framed the release as letting developers verify “that no data leaves their machine.” That is now technically true for anyone running local inference. For the majority using the hosted Grok 4.5 endpoint, you are still trusting the server flag.
The Bigger Problem
Grok Build was the outlier in this incident — security researchers tested Claude Code and Codex under equivalent conditions and found no repository bundles being transmitted. But the absence of a standard is the real issue. Ninety-two percent of US developers now use AI coding tools daily. Every one of those tools is a network-capable process running in your codebase with access to your filesystem. None of them are required to disclose what they transmit, to whom, or under what conditions.
The Grok Build incident didn’t create that problem. It just made it impossible to ignore.
