Grok Build: SpaceXAI's Terminal Coding Agent in Rust

A Fullscreen Terminal Agent That Edits Code and Runs Commands

Grok Build, installed as the grok command, is SpaceXAI's terminal-based AI coding agent. It runs as a fullscreen TUI with mouse interaction. The agent understands codebases, edits files, executes shell commands, and searches the web. It operates in three modes: interactive (the default TUI), headless for scripting and CI pipelines, and embedded in editors via the Agent Client Protocol (ACP).

The project lives in the xai-org/grok-build repository, which is synced periodically from the SpaceXAI internal monorepo. A SOURCE_REV file at the repository root records the full monorepo commit SHA corresponding to the code present in the public tree. This means the public repository's git history does not reflect every internal commit, and gaps may exist between what is visible here and what is running in production at SpaceXAI.

The binary artifact produced by a source build is named xai-grok-pager. Official prebuilt installs ship it as grok. This distinction matters when building from source: the binary you get is named differently from what the installer provides, and your PATH must be updated accordingly.

Full documentation, including keyboard shortcuts, slash commands, configuration, theming, MCP server setup, skills, plugins, hooks, sandboxing, and headless mode details, is available at docs.x.ai/build/overview. The user guide also ships with the pager crate at crates/codegen/xai-grok-pager/docs/user-guide/.

Installing the Released Binary on macOS, Linux, and Windows

SpaceXAI publishes prebuilt binaries for macOS, Linux, and Windows. On macOS and Linux (and on Windows through Git Bash), a one-line installer script handles the download and PATH setup:

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

On Windows PowerShell, the equivalent installer is available at the same domain:

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

After installation, run grok --version to confirm the binary is in place. The first time you launch grok, it opens a browser window to complete authentication. The authentication guide is at crates/codegen/xai-grok-pager/docs/user-guide/02-authentication.md in the repository.

The changelog at x.ai/build/changelog documents fixes, features, and improvements in each release. There are no GitHub releases on this repository; versioning lives entirely at the x.ai/build/changelog URL and in the prebuilt binary's version output.

Crate Layout and the Agent Runtime Architecture

The Rust workspace is organized into several crates under crates/codegen/. Each crate has a distinct responsibility:

xai-grok-pager-bin is the composition-root package that builds the final binary. xai-grok-pager implements the TUI itself, covering scrollback, the prompt, modals, and rendering. xai-grok-shell contains the agent runtime along with the leader, stdio, and headless entry points. xai-grok-tools implements individual tool capabilities: terminal I/O, file editing, web search, and others. xai-grok-workspace manages the host filesystem, version control operations, shell execution, and checkpoints.

Additional crates cover configuration (xai-grok-config), MCP server integration (xai-grok-mcp), markdown rendering (xai-grok-markdown), authentication (xai-grok-auth), sandboxing, and crash handling (xai-grok-crash-handler). Small shared leaf crates live under crates/common/, crates/build/, and prod/mc/.

The root Cargo.toml is auto-generated and is explicitly marked read-only in the README. All per-crate dependency changes should be made in the per-crate Cargo.toml files. Building the full workspace at once is described as slow; the README directs contributors to target specific crates with -p flags.

Building Grok Build from Source with Rust and DotSlash

Building from source requires three prerequisites. First, Rust: the toolchain version is pinned by rust-toolchain.toml at the repository root, and rustup installs it automatically on first build. Second, DotSlash, which is required so hermetic binaries under bin/ (including bin/protoc) can download and run. Third, protoc for proto code generation, which DotSlash resolves from bin/protoc, or falls back to a protoc on PATH or at $PROTOC.

Install DotSlash and verify it works:

cargo install dotslash
/usr/bin/env dotslash --help

To build and launch the TUI in a single step:

cargo run -p xai-grok-pager-bin

To build a release binary at target/release/xai-grok-pager:

cargo build -p xai-grok-pager-bin --release

For per-crate development work, the README shows these commands:

cargo check -p xai-grok-config
cargo test -p xai-grok-config
cargo clippy -p xai-grok-pager-bin
cargo fmt --all

macOS and Linux are the supported build hosts. Windows builds are described as best-effort and are not currently tested from this repository tree.

Headless Mode, ACP Integration, and Third-Party Licensing

The headless mode allows Grok Build to receive instructions through standard input and write results to standard output, without a terminal UI. This is the path for CI pipelines and scripting. The ACP (Agent Client Protocol) integration allows editors to embed the agent as a structured subprocess rather than opening the fullscreen TUI directly.

Third-party licensing requires review before use in environments with strict licence requirements. The first-party Rust code is Apache-2.0. However, the repository bundles tool implementations ported from openai/codex and sst/opencode. These ports are listed in THIRD-PARTY-NOTICES at the repository root and in crates/codegen/xai-grok-tools/THIRD_PARTY_NOTICES.md, with full licence texts and Apache section 4(b) change notices. The third_party/ directory holds a vendored Mermaid diagram stack, with a notice index at third_party/NOTICE.

Any licence compliance review must cover all three notice locations, not only the top-level LICENSE file. The combination of ported code from multiple open-source projects means the effective licence posture is more complex than Apache-2.0 alone.

Limitations: Closed Contributions, Windows Builds, and Monorepo Sync Gaps

External contributions are explicitly not accepted. CONTRIBUTING.md states this clearly. Changes originate inside SpaceXAI and are pushed to the public repository through periodic syncs from the internal monorepo. If you find a bug, you can open an issue, but you cannot submit a fix. This is a meaningful constraint for teams that want to maintain a patched fork: they must track the public repository and reapply their patches after each sync.

Windows builds are best-effort and untested from this repository tree. The prebuilt installer does ship a Windows binary, but anyone who needs to build from source on Windows should expect to encounter issues not present on macOS or Linux.

The root Cargo.toml is regenerated from the monorepo on every sync and should be treated as read-only. Forked repositories that modify workspace-level settings in the root Cargo.toml will have those changes overwritten when they pull new syncs from upstream.

The last push to the repository was on 2026-09-23, five days before this review. The SOURCE_REV file records the exact internal commit, but commits between public syncs are not visible in the repository history.

Grok Build vs a DIY Agent Loop

The natural alternative to Grok Build is assembling a coding agent from individual components: a language model API client, a file editing tool, a shell execution wrapper, and a TUI framework. That approach gives full control over every component, model choice, and integration. The cost is writing and maintaining all of it.

Grok Build provides that entire stack as a prebuilt binary connected to SpaceXAI's Grok model. The trade-off is that you cannot swap the underlying model, and you accept SpaceXAI's update cadence and contribution policy. For teams already using Grok and wanting a terminal interface without building one, the prebuilt binary is faster to adopt. For teams that need a specific model, a custom tool set, or the ability to contribute patches, the DIY approach retains more control.

The ACP integration path is the design choice that differs most from a monolithic agent: it allows editors to use Grok Build as a backend rather than requiring users to live in the TUI.

Editorial conclusion

Grok Build is appropriate for developers who want a terminal AI coding agent connected to the Grok API, with a one-command install on macOS and Linux. Do not adopt it expecting to contribute upstream patches, because external contributions are explicitly closed. Review THIRD-PARTY-NOTICES before deploying in environments with strict licence requirements, as the tool implementations include code ported from other open-source agents. The root Cargo.toml is auto-generated and will be overwritten on the next monorepo sync; any forks should work at the per-crate level.

Frequently asked questions

Official sources

1. Official README
2. Project repository