Summary: On July 15, xAI open-sourced Grok Build with the coding agent and terminal UI source, spanning context assembly through tool-call dispatch. The release exposes the agent loop, tool contracts, UI, and extension system, making harness behavior auditable in code. A local-first path supports self-compilation, local inference, and one config.toml, though the announcement omits a license and version number.
A coding agent’s model can be swapped out; the harness is what actually shapes its behavior — how context gets assembled, how responses from the model get parsed, how calls to tools get dispatched, and what happens when things fail. On July 15, xAI announced the open-sourcing of Grok Build, with the coding agent’s complete source — TUI included — published on GitHub. Make no mistake: this is not an open-source gesture that keeps the core behind closed doors while opening only the trim — the announcement states plainly that the published code runs the full span, context assembly all the way through tool-call dispatch.
What got published: four blocks that make up a full agent loop
Read the codebase as four blocks. Block one covers the agent loop itself — the assembling of context, the parsing of model responses, the dispatching of tool calls. This sits at the heart of any harness, and it is why one model behaves differently when the harness around it changes. Block two is the tools: reading code, editing it, searching it, and executing commands, with the input and output contract of every tool written into the source. Block three is the terminal UI — input handling, rendering, plan review, plus the inline diff viewer a human looks through to check what the agent plans to do and what it has changed. Block four is the extension system — the mechanics by which hooks, skills, plugins, MCP servers, and subagents get loaded and invoked.
Stack the four blocks together and you get a full cross-section of a coding agent in operation — a view this space rarely offers, because rival products either stay shut entirely or open just the SDK layer. Laid side by side, the blocks also set out the division of labor — the loop shows why one model performs differently from harness to harness; the tools map the agent’s true attack surface, because reading files, writing files, and running commands are each a high-privilege operation; human judgment gets into the flow through the TUI, and plan review plus inline diffs are the points where you can intercept; and where the ecosystem’s boundary falls is decided by the extension system.
Why open-source at all: a harness you can trust starts with code you can read
The stated rationale deserves quoting word for word: open-sourcing is the most direct path to a robust and reliable harness. That sentence carries two implications. One, documentation cannot guarantee a reliable harness — docs may describe an extension’s format, but the details that genuinely determine behavior, load priority among them, along with permission boundaries and error-handling paths, are written nowhere but the source. Two, per the announcement the source itself is the definitive reference for anyone building on the extension ecosystem: when docs trail behind or turn ambiguous, the code is what governs.
For anyone adopting it, the tangible payoff is auditability. Can a given hook touch the prompt? What context reaches an MCP tool? What settings does a subagent inherit? From here on, those questions get answered by opening the code, not through behavioral guesswork or by asking support.
The local-first path: compile it yourself, run inference locally, drive everything from config.toml
The announcement has a second headline: a fully local-first route. You compile Grok Build yourself, aim the agent at local inference, and let a single config.toml carry all configuration. For setups constrained by privacy or cost, that marks the dividing line: data never has to leave the machine, and no cloud quota bill ever comes due. One config.toml carrying everything adds a third layer on top: all configuration has a single source of truth; behavior becomes something you can reproduce and put under version control; and handing an environment to another team means passing over one config file instead of rebuilding it from a verbal description.
None of that makes local-first safe by default — the line is yours to draw: an agent running on your own machine can still reach into the wrong directory, run a command that causes damage, or let environment variables slip out. These behaviors are yours to inspect once the code is open; carrying out the inspection does not happen by itself. Before real deployment, verify each of the three: command allowlists, sandbox isolation, and secrets handling.
Who this codebase is for
Three groups stand to gain the most. If agent loop design is what you want to learn, start with block one: the trade-offs between how context gets assembled and how tool calls get dispatched are the hardest material to pick up from documentation alone. If you write extensions, go straight to block four, which shows how each of the five extension mechanisms is loaded and invoked — and the announcement’s position is that the source is the definitive reference. If you want a local-first workstation, follow the configuration path: compiling it yourself plus local inference amounts to a full alternative to depending on the cloud.
Two practical cautions before you lean on any of this: no license terms and no version number appear in the announcement, so nail down the license before you formally depend on the code; and instead of turning the entire repository into a fork you maintain forever, most teams extract more value from using it as study material for harness design and measuring its approach to context assembly and its tool contracts next to their own setup. Models rotate quarterly; what endures is harness design patterns. That endurance is exactly where this source release’s long-term value lies.