Grok Build is open source. Vendor independence is a separate question.

On July 14, 2026, xAI's public GitHub organization released the Rust source for Grok Build, which its repository describes as SpaceXAI's terminal coding agent. The tree covers the command-line and terminal interfaces plus the agent runtime, including headless operation and Agent Client Protocol support. It carries an Apache-2.0 license and quickly drew substantial discussion, including questions about whether outsiders could build it and what still depended on the vendor.

Engineering and procurement leaders can answer those questions only by separating several properties that are often compressed into “open.” Source visibility, license rights, permission to fork, a documented build, model choice, operation without vendor services, and influence over upstream development are related, but none proves the others. Grok Build is open source. Calling it vendor-independent requires additional evidence about how a team would build, configure, update, and operate its own chosen version.

Apache-2.0 grants lasting rights to the published client code

The license gives recipients broad rights to reproduce the work, prepare derivative works, sublicense it, and distribute source or object forms, subject to the license's conditions. Those are substantive rights: a team can inspect the published client, modify it for its own needs, maintain a fork, and redistribute a compliant build. The repository also states that first-party code uses Apache-2.0 while third-party and vendored code keeps its original licenses and notices, so a redistribution review must include those materials as well.

This is why the closed contribution policy does not make Grok Build less open source. The Open Source Definition concerns the rights attached to the software, including access to source, modification, derived works, and redistribution. It does not require a project owner to accept outside pull requests. Licensing and project governance answer different questions, a distinction also worth preserving when reviewing the mixed licensing around an early tool such as the Juggler coding-agent workbench.

The scope of the grant matters. The repository says it contains the Rust source for the Grok Build client and agent runtime. That grant does not transfer operation of SpaceXAI's hosted models or promise that every service the default product reaches is included in the public tree. Source rights make the client inspectable and forkable; runtime independence depends on whether the remaining services can be replaced or removed.

The public tree records its origin while upstream development remains internal

Grok Build's README says the public repository is periodically synced from the SpaceXAI monorepo. A root-level SOURCE_REV file records the full monorepo commit SHA represented by the public tree. At the July 19 snapshot, that file contained ba69d70c2f7d70a130a323b2becdf137af784c7f; the value can change with a later sync and should not be treated as a permanent release identifier.

That arrangement provides provenance for the snapshot: a reviewer can record which public tree was assessed and which internal source revision SpaceXAI associated with it. It does not create an open upstream process. The project's contribution policy says SpaceXAI develops the software internally and accepts neither external pull requests nor unsolicited patches. The company describes the public tree as serving source transparency and local builds under Apache-2.0.

A team may therefore maintain its own fork under the license, but it cannot assume that a change will flow back into SpaceXAI's version. It also cannot use the public repository alone to predict sync timing, roadmap decisions, or the relationship between an independently modified fork and later public snapshots. These are maintenance and influence questions, not tests of whether the current code is open source.

A documented source build improves replaceability once a team proves it locally

The README documents a source-build path rather than supplying code without build instructions. It pins the Rust toolchain in rust-toolchain.toml, requires DotSlash so hermetic tools such as protoc can be downloaded and run, and gives Cargo commands for launching, checking, and producing a release build. macOS and Linux are supported build hosts; Windows source builds are described as best-effort and not currently tested from the public tree, although released binaries are available for macOS, Linux, and Windows.

Documentation establishes that SpaceXAI has specified a build path. It does not replace a buyer's own clean-environment build or prove that an internally built binary matches an official release. A team that needs operational replaceability should preserve the exact source revision, toolchain, fetched build inputs, commands, output hashes, and any local patches from its own successful build. Until that work succeeds on the team's supported hosts, “we have the source” is stronger than “we can produce and support our own binary.”

Custom model endpoints remove one dependency while the defaults retain others

Grok Build's custom-model guide adds a direct replacement path for model inference. Administrators can configure endpoints that use OpenAI Chat Completions, OpenAI Responses, or Anthropic Messages protocols. The guide includes third-party providers, corporate gateways, a local OpenAI-compatible server, and an Ollama example. The shipped client therefore has documented ways to direct model requests elsewhere.

The defaults still matter. New sessions use the SpaceXAI-hosted grok-build model, and the default browser sign-in uses SpaceXAI OAuth. The authentication guide also documents xAI API keys, enterprise OIDC, an external authentication provider, and per-model credentials. Session credentials are stored in ~/.grok/auth.json, while MCP OAuth tokens use ~/.grok/mcp_credentials.json; both receive owner-only permissions on Unix, and the documentation warns that anyone with filesystem access to those paths can use the credentials.

A custom model endpoint can replace the default inference provider, but its presence does not show that every model behaves equivalently with the agent or that every vendor path has disappeared. The team still needs to test its chosen backend, authentication method, updater configuration, web and tool integrations, telemetry settings, and failure behavior with vendor endpoints unavailable. This resembles the distinction in our analysis of the open-model production ownership gap: permission to use or replace one component does not transfer the operating work around it.

Public source lets buyers inspect operational defaults and platform caveats

The sandbox documentation shows the practical value of a public client even before a team forks it. Grok Build's sandbox guide states that sandbox mode is off by default and documents OS-level profiles using Landlock on Linux and Seatbelt on macOS. For profiles that restrict networking, child-process network blocking is enforced on Linux but is a no-op on macOS. In-process web requests and model calls remain network-capable on both platforms.

The permissions guide separately documents layered tool authorization through deny, ask, and allow rules, hooks, permission modes, remembered grants, and the OS sandbox. These details do not establish that the tool is safe, private, or suitable for a particular environment. They let a buyer inspect the actual defaults and platform caveats, then compare them with deployment policy instead of relying on a product label.

That review should include the components around the visible client. Our Agent BOM analysis explains why agent dependencies, plugins, tools, and configuration deserve their own inventory. The AI workflow security review worksheet can then connect those components to the files, credentials, network destinations, and approvals used in one real development workflow.

Procurement language should match the independence the team has verified

Call Grok Build open source when discussing the published client's license and source rights. Apache-2.0 allows inspection, modification, forking, and redistribution, and the closed upstream contribution channel does not revoke those rights. Record the public snapshot and SOURCE_REV when a decision depends on the exact code reviewed.

Use “vendor-independent” only for the portions the team has proved it can replace and operate. That claim may cover a locally maintained client after a clean source build, a tested alternative model endpoint, organization-controlled authentication, a deliberate update process, known network destinations, and staff able to patch and support the fork. Any part that still requires a vendor-hosted model, identity service, update source, or other network service should remain named as a dependency.

BaristaLabs can help document those boundaries through AI consulting and strategy before procurement turns source access into a broader independence claim. The useful outcome is precise ownership language: which parts are inspectable, which are replaceable, which remain vendor-hosted, and which the operator is prepared to run.

Sources

• xAI GitHub: Grok Build repository and README
• Grok Build contribution policy
• Grok Build SOURCE_REV
• Grok Build Apache-2.0 license
• Grok Build authentication guide
• Grok Build custom-model guide
• Grok Build sandbox guide
• Grok Build permissions and safety guide
• Open Source Initiative: The Open Source Definition
• Hacker News discussion of the Grok Build source release