Grok Build Is Now Open Source — What Exactly Was Opened?

On July 16, xAI released the source code for Grok Build. After downloading the official 0.2.102 macOS build, I noticed an odd detail first: the binary reports commit ab5ebf69acec, which does not exist in the public repository and does not match the SOURCE_REV recorded there.

This does not mean the official binary is compromised, but it does expose a distinction that is easy to blur: seeing the source code, and confirming that the program running on your computer is that source code, remain two separate things.

My conclusion is that xAI has released a substantial body of code. It covers the local client harness that runs Grok Build on your machine — far more than just a TUI. But the Grok model, the cloud service, and the official binary’s build chain remain closed. A portion of Grok Build is now inspectable; the full product is not yet a white box.

What Was Opened: The Client That Controls Local Operations

When Grok Build modifies a repository, it first scans for relevant files locally and assembles context for the model. Once the model returns a proposed next action, the client decides which commands can run directly and which require user approval, then invokes tools, edits files, or executes commands. MCP connections and user-configured hooks enter the execution pipeline at this layer as well.

This client code determines what the agent can do on your computer and when a human should intervene. The dialog box you see in the terminal is only the surface; what actually holds local authority is the harness behind it.

The model and the harness play different roles here. The model proposes a plan based on context; the harness translates that plan into actual operations on your machine. The same Grok model plugged into a different client might have different directory access, different tool availability, or different rules about when dangerous commands pause for confirmation. Conversely, the same harness can drive different models. Separating the two makes the significance of this release clear: xAI did not open-source the model responsible for reasoning; they open-sourced the execution layer responsible for turning reasoning results into actions in the development environment.

The Rust repository xAI released includes the agent runtime, file and command tools, permission management, sandbox support, MCP, hooks, and more. The README also provides local build instructions and allows the client to connect to local models. The code is under the Apache-2.0 license — anyone can read it, modify it, build their own, and fork it. For a tool that reads projects, edits code, and runs commands, this release is not merely a gesture. It gives high-privilege local behavior an inspectable foundation, line by line, for the first time.

The scope extends beyond the interactive terminal workflow. The repository also includes a headless mode for scripts and CI, as well as ACP support for integrating the agent into editors and other external programs. In other words, xAI released the client foundation that can be embedded into automated workflows — not merely the display layer of a terminal application.

What Remains Closed: The Model, the Cloud, and the Official Build Chain

The repository does not contain the Grok model. How the model reasons, how the server handles and retains data, and how accounts interact with the remote service when using xAI’s offering all fall outside this release. The client source code can tell us what it prepares to send; it cannot, on its own, answer what the server does after receiving it.

There is also a layer of constraint in how the project was opened. The README explains that this repository is periodically synced from xAI’s private monorepo; the CONTRIBUTING page explicitly states that external pull requests are not accepted. Apache-2.0 makes the code legally forkable, but the canonical repository remains a one-way publication from xAI. This is open source, not open development.

The mismatched commit I noted at the beginning exposes another gap. The public history starts at the initial release commit and cannot be mapped to the internal commit used by the official binary. The repository currently lacks a release tag anchoring the official installer package to a public commit, a complete reproducible build recipe, public CI, SBOM, or source-to-binary attestation. macOS code signing proves the program was distributed by xAI; it does not prove which public commit it corresponds to.

This creates a practical consequence. A developer can select a public commit, compile it, and audit that specific program. If they install the version xAI distributes instead, they must independently verify that binary’s runtime behavior. Even when both programs carry the same version number, their audit conclusions do not automatically transfer without build provenance. Source availability answers “is there code to read”; the release chain must still answer “is what I downloaded the code I read.”

The diagram below summarizes this boundary: the client is now inspectable and independently buildable, while the model, cloud service, and the mapping between official installers and public source all require separate verification.

Open Source Does Not Close the Book on the Earlier Upload Incident

The upload controversy from early July involved a different version. The original packet capture analysis tested 0.2.93 (f00f96316d4b). Under the researcher’s consumer account and environment, the client uploaded tracked Git repositories in full, including their history — even test files the model had not read.

That experiment did not prove the current version still behaves the same way, nor did it cover all account types, untracked but .gitignore-listed files, or training usage. Conversely, the current public repository cannot clarify the old version either, because f00f96316d4b is absent from the public Git history, leaving no way to compare code changes before and after the incident.

The old packet capture and the current source code thus answer two different questions. The former records what one specific binary did at one point in time; the latter shows how the client published today is designed to work. Merging the two bodies of evidence produces two opposing errors: concluding from the old experiment that the current version behaves identically, or declaring from the current code that the old controversy is resolved.

What open source genuinely changes is the method of verification going forward. A developer can now pin a public commit, build the client from source, inspect how it selects files, requests approval, and executes tools, then compare those results against the official binary’s actual network and file behavior. The model and server side still require independent verification through policies, packet captures, and runtime testing.

So the precise description of what Grok Build open-sourced is this: xAI released the client harness that governs local files, commands, and tools; it did not release the model, the cloud system, or the full official release chain. This does not automatically establish trust — but it turns part of the trust problem into an engineering problem, one that can be addressed by reading code, running tests, and reproducing results.