Update, 22:19 BST 16 July: The repository has received its first normal commit — a monorepo sync pushed on Thursday evening (parented on the morning's squash, with a real changelog: an SSRF-bypass fix in the hook runner, new OAuth workspace scopes, and assorted fixes). Public history has, in effect, started from tonight. What hasn't changed: the collection routines still return "unavailable in this build" at the new tip (the only edit to that file was a test-harness gate), issues and pull requests remain disabled, and everything before Thursday morning's squash remains uninspectable.

The takeaway: xAI has open-sourced Grok Build, the coding CLI a wire-level teardown caught uploading entire repositories — opted out or not. We cloned the repository and read it. The scaffolding around the uploads is all there: the queue, the wire formats, the privacy gates. The one thing the release cannot show you is the one thing that matters — the code that actually collected and sent your repository. In the public build it is gone, replaced by stubs that return "unavailable in this build." The history is a single squashed commit, so the pre-scandal code isn't in there either. And the repository accepts no issues and no pull requests. Whether by design or by build convention, the release is shaped exactly around the question it can't answer.

What's in the release

The repository went up under Apache 2.0 — a Rust codebase of some 2,700 files that had passed 6,100 GitHub stars by Thursday morning. Read as engineering, it's a serious release, and the upload architecture is genuinely inspectable in outline. There is a substantial upload queue that snapshots working-tree files before sending. There are destination clients for Google Cloud Storage, S3 and xAI's own proxy at cli-chat-proxy.grok.com. There are exclusion lists for what a workspace upload would skip — node_modules, .env, virtual environments.

Most tellingly, the wire types for repository collection survive intact. A structure called GitCollectChangesResponse describes exactly the shape of what the tool was built to gather: local commits, staged and unstaged changes, and untracked files with their contents — base64-encoded, with include_untracked defaulting to true. That is consistent with what the teardown observed on the wire: not diffs, whole files, including ones you never committed.

The privacy gating in the published code is also visible — and, on its face, well built. Collection runs through a three-way gate (enterprise zero-data-retention teams, a per-user opt-out, a feature flag), and the deciding function carries a comment stating the design intent: if the privacy state is unknown, collection "counts as disabled — nothing may leave the machine while the privacy state is unknown." Fail-closed, exactly what you'd want.

What's not in it

Follow any of those inspectable paths to the point where a repository would actually be walked, packaged and transmitted, and you hit a wall. The function behind the collection request returns an error: "git collect changes is unavailable in this build" (workspace_ops.rs). The serialisation handler: "git serialize_changes is unavailable in this build" (extensions/git.rs). Session-state upload fails with session_state_upload_unavailable; chat-content upload is skipped as chat_content_upload_disabled (upload/trace.rs). The per-turn archive names the teardown will recognise — before_changes.tar.gz, after_changes.tar.gz, repo_changes.tar.gz — appear only in test code; no live code path in the release produces them.

Nor can you look at what the code used to do. The published history is one commit — "Publish harness and TUI open-source" — a squashed import from what the README calls the SpaceXAI monorepo. And it doesn't even hold still: the commit we cloned was dated Wednesday evening; by 06:46 on Thursday morning it had been force-replaced with a fresh parentless squash under the same message — 158 files changed against the tree we read overnight. There are no tags, no earlier states, and nothing that ties any given day's tree to the specific shipped binary the teardown analysed. (We re-checked every finding in this piece against the new tip; all of them hold.) The server side — the proxy that received the uploads, and the remote settings service whose trace_upload_enabled boolean appears to be the server-side kill switch — is not part of the release at all.

One more wrinkle: the flag name that circulated when the uploads stopped — disable_codebase_upload, reported as the silent server-side switch — appears nowhere in these 2,700 files. The opt-out that does exist in the source is called coding_data_retention_opt_out. That's not evidence anyone misspoke — the observed flag may live server-side — but it means the published client can't corroborate that account either.

The contradiction the release can't resolve

In fairness, the upload path is not the only thing stubbed — deploy, devbox login and session-restore features get the same "unavailable in this build" treatment, which is consistent with a standing internal/public build split rather than a scandal-week excision. But the effect is the same, and here is its uncomfortable shape. The gating code xAI published would, as written, honour the opt-out. The teardown observed a shipped binary uploading regardless of the opt-out. Both can't describe the same code — and the code that would settle which is true is exactly the code that is absent from the public build. The release is consistent with "the gate was always correct and something else went wrong", and equally consistent with "the collection path didn't check the gate" — and it cannot distinguish between them.

And the repository is built so that nobody can ask on the record. Issues are disabled. Discussions are disabled. The contributing file says the repo "does not accept external pull requests or unsolicited patches" and exists for "source transparency and local builds"; security reports are routed to HackerOne, and the repo's own security policy says "Do not open public GitHub issues for security reports." Transparency, with the comment section closed.

What would actually settle it

Four things, none of them exotic: the collection code, real commit history, a tagged release matching the shipped binary, and the incident report xAI still hasn't produced — a deletion timeline and a way for affected users to verify the purge Musk promised. Until then, open-sourcing Grok Build answers the easy question — what does the tool look like now? — while the hard one, what did it do with what it took, remains exactly as unanswerable as it was on Monday.

(A small curiosity for the record: throughout the source and README, the product brands itself not as xAI but as "SpaceXAI" — the README describes the tree as "synced periodically from the SpaceXAI monorepo.")