xAI Open-Sources Grok Build, Its Rust AI Coding Agent

Grok Build open source is now a reality: xAI has published the full source code for its terminal-based AI coding agent, grok, on GitHub under the permissive Apache 2.0 license. The move puts xAI in direct competition with a rapidly maturing field of autonomous coding tools — and gives developers something increasingly rare: a production-grade agentic coding harness they can read, audit, and extend from the ground up.

The repository, xai-org/grok-build, is described as xAI's terminal-based AI coding agent — a "coding agent harness and TUI" that is "fullscreen, mouse interactive, extensible" — and is synced periodically from xAI's internal monorepo. It quickly gathered well over 1,700 GitHub stars and hundreds of forks after going public — a number that has kept climbing (the repository shows roughly 1.8k stars at the time of writing) — signalling real developer appetite for a credible open alternative in a space that already includes OpenAI Codex CLI, Anthropic's Claude Code, and SST's OpenCode (sometimes searched as grok build opencode by developers comparing the two). Tool implementations from both openai/codex and sst/opencode were directly ported into Grok Build's tooling layer, a lineage the repo documents openly in its THIRD_PARTY_NOTICES.

---

What Grok Build Actually Is — and What It Isn't

Grok Build is not a plugin, an IDE extension, or a web dashboard. It's a full-screen, mouse-interactive Terminal User Interface (TUI) written almost entirely in Rust (99.6% of the codebase, per GitHub's language breakdown). The binary is built under the internal name xai-grok-pager but shipped to end users as the grok command. That naming distinction matters because it reveals the tool's architecture: the "pager" is the rendering and interaction layer wrapping a much deeper agentic runtime.

At its core, Grok Build is a coding agent harness — it doesn't just autocomplete lines of code. According to the repository description, it "understands your codebase, edits files, executes shell commands, searches the web, and manages long-running tasks," all from within a single terminal session. The underlying model powering it by default is grok-4.5, xAI's latest frontier model; xAI's documentation states plainly that grok-4.5 is "the same model that powers Grok Build," accessible via the xAI API.

Why it matters: Publishing the full harness — not just a thin wrapper — means the community can inspect exactly how an xAI coding agent orchestrates tool calls, manages context, and handles multi-step tasks. That level of transparency is unusual even among projects that call themselves "open source."

It's also worth being precise about what "open source" means here. External contributions are not accepted — the repo's README states this explicitly and points to its CONTRIBUTING.md. The repository is a periodic export of an internal monorepo, which also explains its abbreviated commit history rather than the incremental commit log you'd expect from a conventionally developed open-source project. The Apache 2.0 license grants broad rights to use, modify, fork, and redistribute — but upstream development remains entirely under xAI's control. That's an important distinction for teams evaluating whether to build production tooling on top of it.

On versioning: the repository reflects what is effectively an early, beta-era release — capable and already widely deployed internally at xAI, but appearing publicly for the first time without the polished release history of more established tools. Treat it accordingly: excellent for experimentation and internal tooling, but think carefully about stability expectations for mission-critical pipelines. (The draft's "0.1" framing is an interpretation of that maturity level rather than an official version tag published by xAI.)

---

Three Operating Modes: Interactive, Headless, and Embedded

One of Grok Build's architectural strengths is that it isn't a single-purpose tool. It supports three fundamentally different execution modes, each targeting a distinct developer workflow — the repo itself describes running it "interactively, headlessly for scripting/CI, or embedded in editors via the Agent Client Protocol (ACP)."

Interactive TUI Mode

The default experience is a full-screen terminal interface with mouse support, scroll-back, a persistent prompt, and modal overlays. This is the mode most users will encounter first. It renders output in real time and supports a full set of slash commands (e.g., /model <name> to hot-swap the underlying model mid-session — xAI's docs confirm you "switch inside the TUI with /model <name>") and keyboard shortcuts documented in the embedded user guide under crates/codegen/xai-grok-pager/docs/user-guide/.

Headless Mode

Pass the -p flag and Grok Build drops all TUI overhead and runs as a pure command-line pipeline tool:

grok -p "Explain this codebase"
grok -p "Refactor auth.rs to use async/await" --output-format streaming-json

The --output-format streaming-json flag (documented in xAI's official docs) makes it trivially composable with other CLI tools, shell scripts, and CI/CD pipelines. This is where Grok Build starts to look less like a developer assistant and more like infrastructure. Automated code review, pre-commit hooks, and PR-level refactor bots are all tractable use cases in headless mode. The grok build CLI in this configuration behaves as a first-class automation primitive rather than a conversational interface.

Agent Client Protocol (ACP) Mode

The third mode is the most forward-looking. The Agent Client Protocol (ACP) — an open protocol originally introduced by the Zed editor team for connecting agents to editors — allows Grok Build to be embedded inside other applications (editors, orchestration frameworks, or custom toolchains) as a subprocess communicating over a defined protocol interface. This positions Grok Build not just as an end-user tool but as a composable agent runtime that third-party software can drive programmatically.

---

Grok Build Install: Getting It Running in Under a Minute

Installation is deliberately frictionless. xAI ships prebuilt binaries for macOS, Linux, and Windows, distributed via simple one-liner scripts documented in the repository README.

macOS and Linux

curl -fsSL https://x.ai/cli/install.sh | bash

Windows (PowerShell)

irm https://x.ai/cli/install.ps1 | iex

Verify the install

grok --version

On first launch, the tool opens a browser window for authentication. For non-interactive environments — servers, containers, CI runners — you can bypass browser auth entirely by setting the XAI_API_KEY environment variable:

export XAI_API_KEY="xai-..."

Building from Source

Because the codebase is now public, you can also build directly from the GitHub repository. Requirements are minimal: a Rust toolchain (automatically provisioned by the pinned rust-toolchain.toml via rustup) and protoc for protocol buffer code generation.

# Build and launch the TUI
cargo run -p xai-grok-pager-bin

# Compile a release binary
cargo build -p xai-grok-pager-bin --release
# Binary lands at: target/release/xai-grok-pager

# Fast validation without full compilation
cargo check -p xai-grok-pager-bin

macOS and Linux are fully supported build hosts. Windows builds from source are described as "best-effort and not currently tested," so production Windows users should stick to the prebuilt binary for now.

---

Quick-Start Workflow: A Typical Grok Build Session

To make the tool's interaction model concrete, here's what a typical early session looks like after installation and API key configuration:

1. Navigate to your project root and launch the TUI: grok
2. At the prompt, ask a codebase-scoped question: "Summarize the architecture of this project and identify any obvious code smells in the auth layer."
3. Grok Build reads relevant files, reasons over the codebase structure, and streams its analysis with file references inline.
4. Follow up with an action: "Refactor the session token validation into a dedicated middleware module." The agent proposes a diff, requests confirmation, then edits the files directly.
5. Switch models mid-session if needed: /model my-openrouter-model
6. For a repeatable version of the same task, exit the TUI and run headless: grok -p "Check all TODO comments and generate a prioritised issue list" --output-format streaming-json | jq .

This loop — explore, propose, confirm, apply — is where the Rust-native TUI pays dividends: response rendering is fast, scroll-back is native, and the agent can hold large context windows without perceptible lag in the interface layer.

---

Architecture Deep Dive: The Rust Crate Layout

The repository's internal structure reveals a clean separation of concerns across five primary crates (all located under crates/codegen/). Understanding this layout is essential for developers who want to fork, extend, or audit specific subsystems.

Crate	Role
xai-grok-pager-bin	Composition root; compiles to the final grok binary
xai-grok-pager	TUI layer: scrollback, prompt, modals, rendering pipeline
xai-grok-shell	Agent runtime + entry points for leader, stdio, and headless modes
xai-grok-tools	Tool implementations: terminal execution, file editing, web search
xai-grok-workspace	Host filesystem access, VCS integration, execution environment, checkpoints

The xai-grok-tools crate deserves special attention because its third-party notices explicitly acknowledge that tool implementations were ported from openai/codex and sst/opencode. The repository's top-level notice describes "in-tree source ports (including openai/codex and sst/opencode tool implementations)," and a crate-local crates/codegen/xai-grok-tools/THIRD_PARTY_NOTICES.md carries the license texts plus the Apache §4(b) change notice for those ports. This is transparent open-source practice, and it also tells you something about Grok Build's design philosophy: rather than reinventing foundational agent tooling from scratch, xAI adapted proven patterns from the broader ecosystem and concentrated their differentiation at the TUI, runtime, and model layers.

The root Cargo.toml is auto-generated and read-only; developers forking the project should edit per-crate Cargo.toml files instead. The repo also includes clippy.toml and rustfmt.toml at the root for linting and formatting consistency.

---

Security and Trust Model: What the Agent Can Access

For teams evaluating Grok Build for production or shared-infrastructure use, the permission surface of an agentic coding tool is not an abstract concern. Based on the open crate structure, several practical points are worth noting:

• Filesystem access: The xai-grok-workspace crate mediates host filesystem operations, VCS integration, execution, and checkpoints. Because this code is now auditable, security teams can trace exactly which paths the agent can read and write, and under what conditions checkpoints are created.
• Shell execution: The xai-grok-tools crate implements terminal execution. Headless CI use cases should be scoped to restricted environments (containers, VMs) the same way you would scope any code-executing agent — verify the sandbox behaviour in the repo's dedicated sandbox crate before assuming defaults protect you.
• Network access: Web search is a built-in tool capability. In air-gapped or network-restricted environments, verify whether this can be disabled via configuration before deployment.
• API key handling: Credentials flow through the XAI_API_KEY environment variable or browser-based authentication. The config file at ~/.grok/config.toml can reference environment variable names per model definition (via the env_key field), which avoids hardcoding secrets in config files.
• MCP server trust: MCP servers discovered in the working directory are surfaced via grok inspect. As with any MCP integration, treat untrusted MCP servers with the same caution you'd apply to untrusted shell scripts — they extend what the agent can invoke.

The open-source release materially improves the security posture for enterprise adoption: rather than trusting a black-box binary, security teams can verify behavior directly from source. That's a meaningful advantage over closed-source alternatives in regulated or sensitive development environments.

---

Model Configuration and Custom Model Support

Out of the box, Grok Build runs on grok-4.5 via the xAI API, which exposes an OpenAI-compatible REST interface at https://api.x.ai/v1. But the configuration system is deliberately model-agnostic. The config file lives at ~/.grok/config.toml (or %USERPROFILE%\.grok\config.toml on Windows) and accepts arbitrary model definitions:

[model.my-model]
model = "model-id"
base_url = "https://api.example.com/v1"
name = "Display Name"
env_key = "API_KEY_ENV_VAR"

[models]
default = "my-model"

The base_url field accepting any OpenAI-compatible endpoint is significant. Because the xAI API itself is OpenAI-compatible at https://api.x.ai/v1, this same mechanism can route Grok Build at any provider that speaks the OpenAI Chat Completions protocol. Grok Build with OpenRouter is a natural integration: OpenRouter aggregates dozens of models behind a single compatible endpoint, so developers can point base_url at https://openrouter.ai/api/v1, set their OpenRouter API key via env_key, and run Grok Build against any model in OpenRouter's catalogue — all without touching the tool's source code. To be clear, OpenRouter integration is not officially documented by xAI; it is an inference from the tool's OpenAI-compatible configuration architecture, and readers should validate it against their own setup rather than treat it as a supported feature.

Model switching works in both modes:

• Inside TUI: /model <name>
• Headless: grok -p "Your prompt" -m my-model

The grok inspect command surfaces the full current configuration state — xAI's docs describe it as showing "what Grok discovered in the current directory, including config sources, instructions, skills, plugins, hooks, and MCP servers" — making it a practical first stop when something in the toolchain is misconfigured.

---

Grok Build vs. Claude Code and the Agentic CLI Landscape

The agentic coding CLI space has become genuinely competitive. Any serious Grok Build review needs to situate it against the tools developers are already using.

Tool	Developer	Language	Default Model	Source Available	License	TUI	Headless/CI	MCP Support
Grok Build	xAI	Rust	grok-4.5	Yes	Apache 2.0	Full-screen	Yes	Yes
Claude Code	Anthropic	TypeScript	Claude (Sonnet/Opus family)	No	Proprietary	Inline CLI	Yes	Yes
OpenAI Codex CLI	OpenAI	Rust / TypeScript	GPT-5-codex family	Yes	Apache 2.0	Inline CLI	Yes	Limited
OpenCode (sst)	SST	TypeScript	Multi-provider	Yes	MIT	Full-screen	Partial	Yes

Grok Build vs. Claude Code

The sharpest contrast is with Claude Code: Anthropic's tool is closed-source, model-locked to Claude, and distributed as an npm package. Grok Build's source availability and model-agnostic configuration are meaningful differentiators, particularly for security-conscious teams and those who want to avoid vendor lock-in at the model layer. Claude Code, however, benefits from a more mature documentation ecosystem and a longer track record in production developer environments. For teams that have already standardized on Claude models and Anthropic's safety infrastructure, the switching cost is real — the tools are architecturally different enough that workflows don't transfer automatically. It's worth noting that xAI itself ships a grok-build-plugin-cc Claude Code plugin that delegates tasks to the Grok Build CLI, so the two tools can also interoperate rather than compete outright.

Grok Build vs. OpenCode

The comparison with OpenCode — from which Grok Build directly ports some tool implementations — is nuanced. Both offer full-screen TUIs; the key differences are language and model strategy. Grok Build is Rust (offering performance and memory safety at the binary level), while OpenCode is TypeScript. OpenCode was designed from the start as a multi-provider router, so developers who switch models frequently may find it more immediately flexible than Grok Build without additional TOML configuration. That flexibility gap narrows considerably once you wire Grok Build to any OpenAI-compatible provider via config.toml.

This is also a space where the broader conflation of generative AI with "AI" generally creates real evaluation confusion — agentic coding tools are not interchangeable, and the choice between them turns on runtime architecture, licensing, and model access as much as on raw output quality.

---

Extensibility: MCP Servers, Skills, Plugins, and Hooks

Grok Build's extensibility model is one of its most ambitious architectural bets. The tool supports four distinct extension points, all surfaced together by grok inspect:

• MCP Servers: Grok Build integrates with the Model Context Protocol, the emerging open standard for connecting AI agents to external tools and data sources. MCP servers discovered in the current working directory are surfaced via grok inspect. This means Grok Build can immediately consume any of the many MCP server implementations already published by the community — databases, API integrations, documentation systems, and more.
• Skills: Encapsulated capability units that extend what the agent can do in a given context — comparable to "tools" in other agentic frameworks. xAI also operates an official plugin-marketplace repository for distributing these.
• Plugins: Broader integration hooks that can modify or augment Grok Build's core behavior, surfaced alongside skills and MCP servers in grok inspect output.
• Hooks: Event-driven callbacks that fire at defined points in the agent lifecycle, enabling automation and observability integrations — useful for logging tool calls to external systems, triggering CI jobs on task completion, or enforcing approval gates before destructive operations.

The combination of these four layers, plus MCP's growing ecosystem of server implementations, means Grok Build is positioned to benefit from a rapidly expanding network of third-party integrations without requiring xAI to build every data connector themselves. This is the same strategic bet that made MCP support in tools like Claude Code and Cursor a significant community differentiator over the past year.

For developers building serious internal tooling, the fact that all of this extensibility machinery is now auditable in the open-source repo changes the risk calculus considerably. You can verify what a hook can and cannot access, trace exactly what a plugin receives, and — crucially — sandbox the execution environment to match your organization's security model.

---

Key Takeaways

• Apache 2.0 licensed: Grok Build is genuinely open source with a permissive license. Fork it, embed it, redistribute it — but upstream pull requests are not accepted, since development happens in xAI's private monorepo (the README states external contributions are not accepted).
• Rust-native TUI: At 99.6% Rust, it is one of the few production coding agents built on a systems language, offering strong performance and memory safety characteristics by default.
• Beta-era release: Capable and internally battle-tested at xAI, but appearing publicly for the first time; calibrate stability expectations accordingly for production use.
• Three execution modes: Interactive TUI, headless/CI pipeline mode (with --output-format streaming-json), and ACP-embedded mode for integration into third-party applications and editors.
• Model-agnostic by configuration: grok-4.5 is the default via https://api.x.ai/v1, but any OpenAI-compatible endpoint — including OpenRouter and self-hosted models — can be wired in via ~/.grok/config.toml (OpenRouter itself is not officially documented, but the config architecture supports it).
• MCP + plugins + skills + hooks: A four-layer extensibility system, all discoverable via grok inspect, that positions Grok Build to absorb a growing ecosystem of external tool integrations.
• Code lineage is transparent: The repo openly credits openai/codex and sst/opencode for ported tool implementations, complete with license texts and an Apache §4(b) change notice — responsible open-source practice and a useful signal about the tool's design priorities.
• Security-auditable: Unlike closed-source alternatives, the full agent runtime — filesystem access, shell execution, network calls — is inspectable in the published source, lowering the trust barrier for enterprise adoption.
• 1,700+ GitHub stars at launch: Rapid community traction (now around 1.8k stars) confirms real developer interest, though the compressed commit history reflects its monorepo export origin rather than conventional open-source development history.

---

What Comes Next

The immediate question for the developer community is how quickly an extensibility ecosystem matures around Grok Build. MCP server adoption has accelerated significantly, and a Rust-native agent that can consume those servers natively is well-positioned to benefit. The deeper question is whether xAI will keep the open repository and the internal monorepo in meaningful sync — or whether the published code gradually drifts into a less-capable snapshot of the real tool. The monorepo-export import history makes this a genuine concern: there is currently no public commitment on how frequently or faithfully syncs will occur.

On the model side, grok-4.5's availability via an OpenAI-compatible API endpoint lowers the barrier for developers who want to experiment with the underlying model in their own pipelines without adopting the full Grok Build harness. For those who do adopt the harness, the configuration system's support for custom model endpoints means Grok Build could serve as a long-term CLI frontend even as underlying models evolve or multiply. The open-source release is, in that sense, less a one-time event and more the opening move in a longer-term developer relations strategy from xAI — one aimed squarely at the same technically sophisticated audience that made tools like Google's machine learning production guides so widely circulated. Whether the cadence of monorepo syncs keeps pace with community expectations will be the real test of that commitment.