--- title: "xAI Open-Sourced Grok Build. The Code That Uploaded Your Repo Came With It." date: 2026-07-17 tags: ["grok-build","xai","security","open-source","ai-coding-agents","claude-code"] categories: ["AI Tools","Industry"] summary: "Four days after being caught silently uploading entire git repositories to a Google Cloud bucket, xAI open-sourced Grok Build's 844,530-line Rust codebase under Apache 2.0 on July 15 — but the upload function is still compiled into the binary, disabled only by a server-side flag xAI can flip back on without shipping an update. External contributions are rejected and GitHub issues are disabled." --- ![xAI Open-Sourced Grok Build. The Code That Uploaded Your Repo Came With It.](/images/grok-build-open-source-exfiltration-code-remains.png) Openness is supposed to be the industry's trust-repair move of last resort: when a vendor gets caught doing something users didn't consent to, publish the source and let people verify the fix themselves. xAI followed that script almost to the letter on July 15 — and then undercut it by leaving the exact code in question sitting in the repository, merely switched off from the server side. It's a useful case study in the difference between *auditable* and *trustworthy*, and it lands one week after this blog covered the original incident. ## A Quick Recap of What Happened On July 13, independent researcher **cereblab** published a wire-level traffic capture showing that Grok Build — xAI's Rust-based coding CLI, built on SpaceXAI-leased compute in the wake of the Cursor acquisition — was uploading entire git repositories to a Google Cloud Storage bucket named `grok-code-session-traces`, regardless of what the agent actually needed to complete a task. On a 12GB test repository, model-turn traffic to xAI's `/v1/responses` endpoint totaled roughly 192KB; the storage channel moved 5.10GiB in 73 chunks — a gap of **roughly 27,800x** between what the task required and what left the machine. A planted canary file the agent was explicitly told never to open still showed up in the uploaded bundle. The "Improve the model" privacy toggle, which developers reasonably assumed controlled whether their code left their machine, controlled nothing of the sort — it only governed training use, while a separate, undocumented flag governed the upload itself ([full writeup here](/posts/grok-build-xai-silent-repository-uploads/)). xAI's response at the time was a server-side flag flip (`disable_codebase_upload: true`) and an Elon Musk post promising that "all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted." No security advisory. No deletion timeline. No way for an affected developer to confirm their own data was actually gone. ## The Open-Source Release Two days later, on July 15, xAI published the entire Grok Build source — **844,530 lines of Rust** covering the agent harness, terminal UI, tool layer, and plugin/extension system — to GitHub under an Apache 2.0 license, alongside a usage-limit reset for all users. Framed as a transparency move, the release lets anyone inspect exactly how the CLI decides what to read, what to send, and where it goes. Here's what an inspection actually turns up, according to independent analysis of build 0.2.99: the upload function is still there. It's gated by the same server-side flag xAI flipped on July 13, meaning the capability to resume bulk-uploading repositories exists in the shipped binary today, and xAI can re-enable it remotely without pushing a new release or a changelog entry a user would ever see. The fix isn't a fix in the sense of code that was removed — it's a switch that happens to be set to "off" right now, sitting inside a codebase now marketed as open and auditable. Two more details cut against the transparency framing. First, xAI is not accepting external contributions to the repository — this is source-available for inspection, not open development in the collaborative sense the license nominally implies. Second, GitHub Issues are disabled on the repo, which means the community that's supposed to benefit from "you can audit this yourself" has no first-party channel to report what it finds. As one analysis summarized it: xAI is offering "open-source theater" — the appearance of the industry's standard trust-repair gesture, without the parts of it (external review, issue tracking, an actual code change) that would make the gesture mean anything. ## "Auditing a Tool Is Not the Same as Trusting a Vendor" That line, from a follow-up analysis published after the source dropped, is the sharpest single summary of the gap here. Simon Willison, reviewing the release, credited xAI for making Grok Build's internals genuinely inspectable — that part is real, and it's more than most closed coding agents offer. But inspectability answers "can I verify what this does," not "will the vendor tell me when that changes." A dormant server flag means the honest answer to "is my code safe from bulk upload right now" is: however xAI's backend is configured today, which you cannot see, verify, or get notified about — open source repository notwithstanding. The comparison that keeps surfacing in coverage of this story is instructive. Cereblab's original tests, and follow-up analysis, found that Claude Code, Gemini CLI, and Codex read individual files as agents actually need them and don't bundle-and-ship the whole checkout plus git history off-box under equivalent conditions. That's not a coincidence of implementation detail — it reflects a design choice about where the trust boundary sits. Claude Code's `sandbox.credentials` model, which blocks agent commands from reading credential files and secret environment variables at the resource level, is a control you can point to and reason about independent of server-side state you can't see. A codebase you can read is worth something. A codebase you can read whose actual runtime behavior is one unannounced flag away from changing is worth quite a bit less, and calling it "open source" doesn't close that gap. ## What Developers Should Actually Do The guidance from the original incident still stands, and the open-source release doesn't change it: if you ran Grok Build against a repository containing real secrets — API keys, database passwords, SSH keys, cloud tokens, anything committed and later deleted from working files but still in git history — rotate those credentials now. Don't treat Musk's deletion promise or the July 15 release as resolution; neither comes with a verification mechanism. If you want to actually audit Grok Build rather than take xAI's framing at face value, the source is there to read — specifically, look at how the upload path is gated and confirm for yourself that "disabled" means "removed" or merely "flagged off." For agentic coding tools generally, the standing lesson from this saga is the one worth carrying forward: a privacy toggle or an open-source release is only as good as the specific behavior it actually constrains. Ask what the control covers, not what it's named. --- **Sources:** - [Simon Willison: xai-org/grok-build, now open source](https://simonwillison.net/2026/Jul/15/grok-build/) - [The Hacker News: Grok Build Uploaded Entire Git Repositories to xAI Storage, Not Just Files It Read](https://thehackernews.com/2026/07/grok-build-uploads-entire-git.html) - [byteiota: Grok Build Is Open Source — But the Upload Code Remains](https://byteiota.com/grok-build-is-open-source-but-the-upload-code-remains/) - [MarkTechPost: SpaceXAI Open-Sources Grok Build](https://www.marktechpost.com/2026/07/15/spacexai-open-sources-grok-build-the-rust-agent-harness-tui-and-tool-layer-behind-its-coding-cli/) - [Tech Times: Grok Build Open-Sourced After Covert Upload: Code to Exfiltrate Repos Stays In](https://www.techtimes.com/articles/320671/20260716/grok-build-open-sourced-after-covert-upload-code-exfiltrate-repos-stays.htm)