By ByteBot
xAI open-sourced Grok Build on July 15 under Apache 2.0. Four days after a security researcher proved the CLI was quietly uploading entire developer repositories to Google Cloud Storage — SSH keys, .env files, full git history, files the model never even opened — the company released the source code and reset usage limits. This is not a benevolent act. It’s damage control dressed as transparency, and the most important detail is buried: the upload code is still in the compiled binary.
What the Open-Source Release Actually Contains
The repository at github.com/xai-org/grok-build is roughly 844,530 lines of Rust, split across four packages: the TUI layer (xai-grok-pager), the agent runtime (xai-grok-shell), the tool implementations (xai-grok-tools), and workspace management. System prompts for the main agent and its subagents are now visible. So is the upload infrastructure.
xAI’s official framing: “Open sourcing Grok Build allows anyone to support making a reliable and robust harness.” The practical implication: developers can now compile the tool themselves, point it at local inference via ~/.grok/config.toml, and eliminate any network calls to xAI servers entirely. That matters. But most people won’t do this, and xAI knows it.
The Privacy Toggle Was Not What You Thought
Here’s the detail that should stick with you. Grok Build had a “Improve the model” toggle. Developers who turned it off assumed they’d opted out of data collection. They hadn’t. The toggle controls only whether your data is used for training — it says nothing about whether your code leaves your machine in the first place. Those are two separate controls. Only one was exposed to users.
Researcher cereblab ran wire-level analysis on version 0.2.93 and documented this precisely. With the privacy toggle disabled, the server still returned trace_upload_enabled: true. The uploads continued regardless. As cereblab put it: “The right default is off.”
The volume was the other alarm: the model needed roughly 192 KB to do its work. The CLI uploaded 5.10 GiB to a Google Cloud Storage bucket called grok-code-session-traces — arriving in 73 chunks of ~75 MB each. That’s a 27,800x disparity. A separate canary test confirmed files the model never accessed were still uploaded. Deleted secrets that live only in git history went along too.
We covered the original discovery on July 12: Grok Build CLI Uploads Your Entire Repo to xAI Servers. This article covers what happened next.
The Fix Has a Catch
On July 13, the same binary (0.2.93) stopped making storage requests. xAI pushed a server-side flag — disable_codebase_upload: true — and the uploads stopped. No new binary was released. The upload code is still compiled into version 0.2.99. The only thing standing between your code and xAI’s servers is a flag returned by a server xAI controls.
That’s worth sitting with. xAI retains the technical ability to re-enable uploads for any user, on any session, without pushing a software update. Elon Musk promised all previously uploaded data would be “completely and utterly deleted,” but as The Register noted, independently verifying that promise is impossible.
What Developers Should Do Now
If you ran Grok Build before July 13:
- Rotate any secrets in tracked files — API keys, database passwords, anything in a
.envfile committed to your repo - Review your git history — Secrets removed from current files but still present in commits were uploaded
- Run the
/privacycommand — This triggers xAI’s data deletion request for your account, though it’s unverifiable
For ongoing use, the open-source release does offer a real path to privacy. Compile from source, configure ~/.grok/config.toml to point at a local inference endpoint, and verify with grok inspect. At that point, nothing reaches xAI’s infrastructure. But that’s a meaningful amount of work for a tool positioned as a productivity gain.
The Broader Problem With AI Coding Tool Privacy
Cereblab’s comparison test is worth noting: in equivalent conditions, Claude Code and Gemini CLI transmitted no full repository bundles. This was not an industry-wide failure — it was specific to Grok Build’s design choices. That matters as developers evaluate which AI coding tools to trust with production codebases.
Simon Willison’s analysis of the open-source release makes Grok Build auditable in a way it wasn’t before. That’s genuinely useful. But auditing a tool is not the same as trusting a vendor. The upload code being visible in the source doesn’t mean it won’t run — it means you can see exactly how it would if xAI ever decided to flip the flag back on.
Know the difference.
