Grok Build Goes Open Source: Trust Repair in 72 Hours

Grok Build went open source on July 15, 2026 — roughly 72 hours after an AI-safety researcher published wire-level evidence that the CLI had been silently uploading complete Git repositories to a SpaceXAI-controlled cloud bucket. The company published the entire Rust harness at github.com/xai-org/grok-build under Apache 2.0 and framed the release as the final piece of a privacy overhaul.

The speed is remarkable, and the code is genuinely substantial: 844,530 lines of Rust by Simon Willison’s count, covering the agent loop, the tool implementations, the terminal UI, and the extension system. For a tool that runs by default on Grok 4.5, SpaceXAI’s flagship coding model, that is a meaningful shift in posture — especially from a company still settling into its July rebrand from xAI to SpaceXAI.

But “open source” is doing a lot of work in the announcement, and most coverage repeated it uncritically. This piece reads the repo itself: what SpaceXAI actually published, why a squashed monorepo mirror with contributions disabled is not the same thing as an auditable history, why the upload code that caused the scandal still ships in the tree, and — the part a GitHub page can never show — why the switch that turned the uploads off lives on SpaceXAI’s servers, not in the code you can read.

The release landed in two places at once: an announcement at x.ai/news/grok-build-open-source dated July 15, 2026, and the repository itself at github.com/xai-org/grok-build, which went public late in the US day. First-party code is licensed Apache 2.0; vendored code keeps its original licenses. Per the repo’s own README, four subsystems are included:

What is not open: the model. Grok Build’s default grok-build-latest alias resolves to Grok 4.5 ($2 per million input tokens, $6 per million output, 500K context), and those weights remain fully closed. This is an open-source harness around a proprietary model — closer to what Google did with its CLI agent than to an open-weights release. That distinction matters for every claim in the announcement, because the harness is only half the system.

The short version of the scandal, for context: on July 12, 2026, the AI-safety researcher publishing as Cereblab released a wire-level traffic analysis showing that Grok Build CLI v0.2.93 was silently uploading complete Git repositories — including unredacted secrets and full commit history — to a SpaceXAI-controlled Google Cloud Storage bucket, even when the agent was instructed to open no files. Crucially, the in-CLI /privacy toggle did not stop the uploads; what stopped them was a silent server-side flag, disable_codebase_upload: true, pushed remotely with no client update and no changelog entry. We covered the full timeline and what actually fixed it in depth two days ago, and our earlier look at Grok Build’s parallel-agent CLI covers what the tool does when it behaves.

Three days later the harness was public. On July 13, Elon Musk had pledged on X that previously uploaded user data would be “completely and utterly deleted” — a commitment no outside party can verify, and one we treat throughout this piece as a pledge rather than a fact. On July 15, the announcement post positioned open-sourcing as the capstone: with retained data deleted, retention off by default, and the harness on GitHub, SpaceXAI said it was “offering complete user privacy.”

Was the release reactive, or an accelerated roadmap item? The honest answer is that nobody outside the company knows. A Hacker News commenter, “loufe,” captured the plausible middle ground: the release may have been on the roadmap but “prioritized as a bit of whiplash” following the upload furore. Either way, the sequencing is the story — this is the fastest scandal-to-open-source turnaround we have tracked from any frontier AI vendor, and the release must be read as a trust-repair move, because that is explicitly how the vendor framed it.

Open a mature open-source project and the commit log is the institutional memory: you can see when a feature landed, who reviewed it, what a security fix replaced. Open xai-org/grok-build and there is essentially nothing behind the current snapshot. At launch the repo carried a single squashed commit; machine-generated monorepo syncs have landed since, and more will accumulate — but none of them carries per-change development history. Each is a bulk snapshot with a message like “initial sync from the monorepo.”

Simon Willison, reviewing the repo on day one, put it plainly: “So far the repo has just a single commit releasing the code, so sadly we don’t get any insight into how the codebase developed over time.” The README is candid about why: the repository “is synced periodically from the SpaceXAI monorepo,” with a SOURCE_REV file at the root recording the internal monorepo commit SHA each snapshot was cut from. The public repo is a generated artifact — a projection of a private codebase, refreshed on the vendor’s schedule.

The second structural limit: external contributions are not accepted, per the repo’s own README and contributing policy. There is no pull-request path, no community review loop, no way for an outside maintainer to become load bearing. You can read and you can fork — nothing more. Security findings route exclusively through HackerOne; the SECURITY.md file explicitly says not to open public GitHub issues for security reports. This is publish-only open source: legally open under Apache 2.0, operationally one-directional.

None of this makes the release worthless — a readable, buildable, forkable harness is strictly better than a closed binary. But it reframes what kind of transparency was purchased. A synced mirror with squashed history answers “what does the code say today?” It cannot answer “what did the code say on July 11?” — which, after a scandal about behavior that was quietly changed server-side, is precisely the question an audit would want to ask.

Here is the detail most of the celebration skipped: the Google Cloud Storage upload machinery that caused the scandal was not deleted. The modules — upload/gcs.rs, upload/trace.rs, upload/manifest.rs, upload/turn.rs, and upload/config_files.rs — all remain in the published source under the CLI’s shell crate. We read the raw files directly rather than relying on secondary reporting.

What changed is how they behave. The central function, upload_session_state() in trace.rs, now unconditionally returns a hard-coded failure — session_state_upload_unavailable — after draining its pending queue. Sibling paths are disabled the same way: config-file upload reports config_content_upload_disabled, and the manifest module reports artifacts as disabled at multiple call sites. These are string-flag stubs, not removals. Willison’s write-up noted the same hard-coded error, and TechTimes ran a July 16 piece making the “the exfiltration code stays in” case independently.

Hacker News got there too. Commenter “lifthrasiir” linked straight to trace.rs in the discussion thread and asked: “Is this the infamous ‘cloud upload’ routine? I’m not sure it is indeed insidious, though it is of course possible that the code has been filtered out.” That ambivalence is the correct reading. Keeping the code is not inherently sinister — deleting every upload path would break legitimate opt-in telemetry and sync features outright. The problem is what the stub pattern implies about where control lives.

This is the analytical core of the whole episode, so it is worth stating carefully. The scandal’s scariest finding was never “upload code exists” — every cloud-connected tool has upload code. It was that the behavior changed remotely, silently, with no client update, which means it could change back the same way. Open-sourcing the harness does not close that gap. It relocates the trust question from “what does the binary do?” (now largely answerable) to “what do the servers tell the binary to do?” (still unanswerable from the outside). That is genuine progress on the first question and zero progress on the second.

SpaceXAI’s announcement made a set of distinct claims that most coverage graded as a single pass/fail. They deserve separate verdicts, because they have very different evidentiary status. The scorecard below is our own synthesis — each “what the repo shows” cell comes from direct reads of the published source, README, and security policy, cross-referenced against the announcement language quoted by Willison and the press record. No outlet we reviewed structured the claims this way.

One more claim deserves its own paragraph because it is the most contested. SpaceXAI’s announcement stated that “since launch, Grok Build has fully respected zero data retention (ZDR)” and that disabling data upload in the CLI was always respected. That is the vendor’s own retrospective characterization — and it sits in direct tension with the independently reported record: Cereblab’s wire-level capture showed uploads continuing regardless of the toggle, and the fix arrived as a server-side flag. Both things are on the record; we present them side by side rather than adjudicating what only an internal investigation could settle.

How much code is 844,530 lines? Willison ran his own SLOCCount tool — which excludes whitespace and comments — against the repo, then ran the identical tool against OpenAI’s open-source Codex CLI for scale: openai/codex weighs in at 950,933 lines of Rust. Grok Build is roughly 89% the size of Codex — two coding-agent harnesses, both in Rust, both within shouting distance of a million lines. And only about 3% of Grok Build’s total is vendored third-party code, so roughly 97% — around 819,000 lines — is first-party work.

The line count is a genuinely useful data point — it settles, with numbers, that a production terminal agent is a serious systems project rather than a wrapper script. But it is worth separating scale from openness: raw size says nothing about auditability. A million readable lines with no history and no contribution path is a different artifact from a smaller repo with years of reviewable commits. The THIRD_PARTY_NOTICES.md file adds a wry footnote to the competitive story, too — several of Grok Build’s tools were ported directly from Codex and OpenCode, in a way Willison describes as looking compliant with the Apache and MIT licenses. The coding-agent wars are being fought partly with each other’s open-source parts.

Open-sourcing was the headline, but the announcement bundled three further commitments. First, default data retention was disabled for all Grok Build users, retroactive to July 12 — previously, retention was on by default for anyone without a zero-data-retention arrangement, which had applied only to enterprise and API-key customers. Second, SpaceXAI said it is deleting all previously retained coding data — echoing Musk’s July 13 pledge, and equally unverifiable from outside. Third, a paid security channel: per The Register’s July 16 coverage, HackerOne bounties for the newly public codebase run from $100 to $20,000, scaled by severity.

The personnel angle matters here too. Andrew Milich, who heads Grok Build and previously spent four years building the end-to-end-encrypted app Skiff, responded to the original criticism by confirming — per TechTimes’ reporting of his statement — that switching the /privacy setting now triggers retroactive deletion of previously synced data. That is a privacy-literate leader saying the right things; it is also, again, a behavior that lives server-side.

Community reception split along exactly the line this post has been drawing. The generous reading, from Hacker News commenter “arcanemachiner”: “I’ll probably never use this, but at least they’re not delusional enough to attempt to justify keeping their coding agent closed-source, especially after their recent data-harvesting cockup.” The skeptical reading pointed at the leftover upload stubs and the synced-mirror structure. Both readings are correct, which is the most honest one-line summary of this release available. European tech press framed it bluntly as damage control; the repo racked up thousands of stars within its first days regardless.

This is the third agent-trust story in three days — after the upload scandal itself and OpenAI’s move to encrypted agent instructions, which raised the mirror-image auditability question from the other direction. The pattern across all three is the same: agent vendors are being forced to decide, in public, how much of their systems users get to inspect — and inspection rights are becoming a real procurement criterion, not a philosophical preference. Here is how we would act on this release, by situation:

Looking forward, we expect this release to reset the baseline for the category: once one frontier vendor ships its full harness, “why can’t we read yours?” becomes a question every competitor’s enterprise buyers ask in the next renewal cycle. The durable lesson for buyers is architectural, though — any agent that phones home has behavior that no repo can prove, so contracts and controls have to cover the server side explicitly. If your team is formalizing how it evaluates and governs coding agents — inspection rights, egress controls, data-path verification — that is exactly the kind of framework our AI transformation engagements build with clients.