Repo of the day: Grok Build, xAI's coding agent goes open source

🔍 What Grok Build is

Grok Build is xAI's terminal coding agent: a fullscreen, mouse-interactive TUI that reads your codebase, edits files with diff-based review, runs shell commands, searches the web and manages long-running tasks. Launched in beta in May 2026 and aimed at engineers working on large codebases, it runs in three modes: interactively in the terminal, headless for scripts and CI pipelines, and inside editors via the Agent Client Protocol (ACP), the same mechanism other agents use to integrate with IDEs.

The published repository contains the Rust source (99.6% of the code) of the CLI/TUI and the agent runtime. First-party code is under Apache 2.0; third-party parts keep their original licenses. One detail says a lot about the state of the ecosystem: the third-party notices include in-tree ports of the tool implementations from openai/codex and sst/opencode — open source harnesses are literally swapping parts with each other.

repo       xai-org/grok-build
what       xAI's terminal coding agent (harness + TUI), now open source
how        Rust 99.6% · `grok` binary · TUI, headless or editors via ACP
extensions skills, plugins, hooks, MCP servers, subagents
extra      local-first: compile it yourself, point it at your inference via config.toml
license    Apache 2.0 (first-party) · ~19,600 stars · synced from the monorepo

⚙️ How to try it: binary or build from source

The quick path is the prebuilt binary, published for macOS, Linux and Windows: one install script and the `grok` command is ready; on first launch it opens the browser to authenticate. That's the path for using the agent, not studying it.

The interesting path for readers of this article is the second one: building from source with Cargo. You need the Rust toolchain (pinned by `rust-toolchain.toml`, installed by `rustup` on first build), DotSlash to fetch the hermetic tools under `bin/` (notably `protoc` for proto code generation) and little else. The produced binary is named `xai-grok-pager`; official installs ship it as `grok`. macOS and Linux are the supported build hosts, Windows is best-effort.

# Quick path: official binary (macOS / Linux / Git Bash)
curl -fsSL https://x.ai/cli/install.sh | bash
grok --version

# Study path: build from source
cargo install dotslash          # prerequisite for bin/protoc
git clone https://github.com/xai-org/grok-build && cd grok-build
cargo run -p xai-grok-pager-bin              # build + launch the TUI
cargo build -p xai-grok-pager-bin --release  # release binary

🧩 The harness anatomy: the crates that matter

What makes the repository a valuable read is the crate separation, because it mirrors the typical architecture of a modern coding agent. `xai-grok-pager` is the TUI — scrollback, prompt, modals, rendering. `xai-grok-shell` is the agent runtime, with the leader, stdio and headless entry points. `xai-grok-tools` implements the actual tools: terminal, file editing, search. `xai-grok-workspace` handles filesystem, version control, execution and checkpoints. Around them, the supporting crates: configuration, MCP, markdown, sandbox.

It's exactly the map you need to understand how an agent works: xAI's announcement states that the published source covers the agent loop (how context is assembled, how model responses are parsed, how tool calls are dispatched), the tools, the terminal UI with the inline diff viewer, and the extension system. If you work with skills, plugins, hooks or MCP servers on any agent, here you can see in black and white how each is loaded and invoked.

🏠 Local-first: your binary, your inference

The most concrete point of the open-sourcing is that Grok Build can now run fully local-first: you compile it, point it at your own inference — even a locally served model — and drive everything from `config.toml`. For anyone with confidentiality constraints on their code, that's the difference between "I trust the vendor's pipeline" and "I know exactly what leaves my machine, because I can read it in the source".

The user guide, shipped in the repository and published on docs.x.ai, covers the rest of the surface: keyboard shortcuts, slash commands, configuration, theming, MCP servers, skills, plugins, hooks, headless mode and sandboxing. They are the same concepts anyone using Claude Code or Codex CLI already knows — the file names change, the ideas don't.

🏢 Why it's interesting, for developers and SMBs

For developers, the value is not (just) another agent to try: it's a reference text. The questions we ask ourselves while configuring an agent — why isn't the skill being loaded? how are tool results passed back to the model? what actually goes into the context? — have a readable answer in this source, in a language, Rust, that makes module boundaries and responsibilities explicit. Even just comparing how Grok Build, Codex and opencode implement the same file-editing tool is a design lesson; the in-tree ports prove that implementations are becoming shared heritage across harnesses.

For an SMB introducing agents into its development processes, the signal is infrastructure maturing: coding agents are converging on common primitives — skills, plugins, hooks, MCP, subagents, sandboxing — and becoming inspectable components rather than opaque services. Being able to compile the harness and keep inference in-house opens scenarios for teams with strict requirements on where source code travels. It still needs a case-by-case assessment: default usage remains tied to xAI's models and account, and governance should be reasoned about as with any agent.

⚠️ Limits and caveats before adopting it

Some honesty. The first limit is its nature: this is open code, not a community project. External contributions are not accepted, the repository is a mirror synced periodically from the internal monorepo (the public history starts with a handful of commits and a `SOURCE_REV` file recording the origin SHA), and the root `Cargo.toml` is generated and should be treated as read-only. Reading yes, forking too, getting a PR merged no.

On the practical side: the build has non-trivial prerequisites for anyone new to Rust (DotSlash, protoc via hermetic tools), Windows as a build host is explicitly best-effort, and the "official" experience — authentication, models, changelog — stays attached to the xAI ecosystem. Finally, the star count is a snapshot of these days and the project is young as open source: crate structure and configuration surface may change with every sync.

• No external contributions: read-only repository for the community, periodic sync from the monorepo.
• Generated root Cargo.toml: edit the per-crate Cargo.toml files, not the global one.
• Build with prerequisites: pinned Rust toolchain, DotSlash and protoc; Windows best-effort.
• Default tied to xAI: without the local-first setup, authentication and inference go through Grok services.
• Young as an open source project: structure and config may change between syncs.

✅ Where to start

The path I suggest starts with reading, not using: clone the repository and open `crates/codegen/xai-grok-tools` to see how the file-editing and terminal tools are implemented, then `xai-grok-shell` for the agent loop. If you already use another agent, compare the implementations with what you know: it's the fastest way to understand what your daily tool actually does. As a second step, try the Cargo build and launch the TUI; as a third, experiment with the local-first configuration pointing at your own inference.

The broader signal is the direction of the ecosystem: after Codex and opencode, xAI too has put its harness on the table, complete with declared ports of other people's implementations. Agent harnesses are becoming common, readable infrastructure — and for anyone building software with agents, knowing how to read them is becoming a baseline skill.

More articles from the blog