Grok Build Is Open Source, but xAI Won’t Take Your Patches

On July 16, 2026, xAI's GitHub organization published the Rust source for Grok Build. Grok Build is a terminal coding agent that can edit files, run shell commands, search the web, and manage long-running tasks. Publishing the code of a tool with that much authority is useful. The repository's contribution guide draws a clear boundary around that openness.

The policy states that SpaceXAI develops the software internally and does not accept external pull requests or unsolicited patches. It describes the public tree's purpose as source transparency and local builds. Developers can read and build the agent, but they cannot send a fix into the product through the normal pull-request workflow.

Grok Build's first-party code uses the Apache License, Version 2.0, a permissive license that grants broad rights to use, modify, and redistribute the software under its terms. The Open Source Definition requires licenses to allow modifications and derived works. It does not require the original maintainer to accept your patch. Grok Build's closed contribution policy does not make its open-source license less real.

The distinction is between license rights and project governance. A license tells you what you may do with a copy. Governance determines who decides what enters the upstream product. Grok Build gives developers real rights on the first axis while keeping the second inside xAI.

Those rights are especially valuable for a coding agent. This software works inside repositories, touches files, invokes the shell, and can operate for long stretches. Teams can inspect how that authority is implemented instead of treating the distributed binary as the only available account of its behavior. They can also make local changes or build the code for environments where a vendor binary is unacceptable.

The repository explains where the public code sits in the development chain. It is periodically synced from the SpaceXAI monorepo, and a file named SOURCE_REV records the internal revision represented by the public tree. That gives each snapshot useful provenance. It also confirms that the GitHub repository is downstream of the internal source of truth rather than the place where the product is developed.

A fork is possible, though maintaining one could become expensive. A team that changes the public code would need to reconcile those changes with later snapshots from the internal monorepo. The effort would depend on how far its fork diverges and how xAI changes the same areas. The repository has only just appeared, so there is no evidence yet that a durable community fork will emerge or that the sync model will make one impractical.

The closed contribution path has a more immediate consequence. If you repair a bug for your own deployment, the license lets you keep or distribute that fix. The official policy offers no pull-request route for returning it to xAI's product. Other users benefit only if xAI makes a similar internal change or someone maintains the fix outside the upstream tree.

Publishing the source still gives developers meaningful control. They can inspect, modify, redistribute, and fork the code. For a tool that can operate on a codebase and invoke the shell, source transparency and local builds are practical capabilities rather than ceremonial gestures.

An open license and an open development process remain different commitments. Before adopting an open-source coding agent, read both LICENSE and CONTRIBUTING.md. Grok Build's license explains the freedom you receive; its contribution policy explains that xAI decides which changes enter the upstream product. Both facts determine how much control you have and who carries the maintenance work when your needs diverge from the vendor's.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com