Grok Build: SpaceXAI's Rust-based terminal coding agent with a full-screen TUI

What Grok Build actually is

Grok Build is a terminal-based AI coding agent, not a library or a framework. The README describes it as a full-screen TUI that understands your codebase, edits files, executes shell commands, searches the web, and manages long-running tasks. It runs interactively, headlessly for scripting or CI, and embedded in editors via the Agent Client Protocol (ACP). The primary audience is developers who live in the terminal and want an AI agent that can act on the codebase directly, rather than a chat window. The project is written in Rust, with the main binary named xai-grok-pager, shipped as grok. The repository is a periodic sync from a private monorepo, which means the source you see is a snapshot, not a continuously developed open project.

How the runtime is structured

The repository layout shows a clear separation of concerns. The composition-root package is crates/codegen/xai-grok-pager-bin, which builds the binary. The TUI itself lives in crates/codegen/xai-grok-pager, handling scrollback, prompt, modals, and rendering. The agent runtime is in crates/codegen/xai-grok-shell, with leader, stdio, and headless entry points. Tool implementations (terminal, file edit, search) are in crates/codegen/xai-grok-tools, and the workspace layer (host filesystem, VCS, execution, checkpoints) is in crates/codegen/xai-grok-workspace. The rest of the CLI closure covers config, MCP, markdown, and sandboxing. This modular structure suggests that the agent can be driven through different entry points: a TUI, a headless mode for CI, and an ACP interface for editor integration. The README mentions that the root Cargo.toml is generated and should be treated as read-only, which implies that the workspace configuration is managed elsewhere and synced, a notable constraint for anyone wanting to modify the build.

Getting it running: binary install and source build

For end users, the README provides a one-line install script: curl -fsSL https://x.ai/cli/install.sh | bash for macOS/Linux/Git Bash, or irm https://x.ai/cli/install.ps1 | iex for Windows PowerShell, followed by grok --version. For developers, building from source requires Rust (toolchain pinned by rust-toolchain.toml, auto-installed by rustup), DotSlash (cargo install dotslash) to run hermetic tools like bin/protoc, and protoc (either via DotSlash or on PATH). The build commands target specific crates: cargo run -p xai-grok-pager-bin launches the TUI, cargo build -p xai-grok-pager-bin --release produces target/release/xai-grok-pager, and cargo check -p xai-grok-pager-bin validates quickly. The README explicitly warns that full-workspace builds are slow, so you should always target specific crates. On first launch, the TUI opens a browser for authentication, as detailed in the authentication guide. This is a real dependency: you cannot use the tool without going through that browser flow.

Key features: full-screen TUI, mouse interaction, extensibility

The README highlights that the TUI is full-screen and mouse interactive, which is a differentiator from many terminal agents that are line-based. The user guide (shipped with the pager crate) covers keyboard shortcuts, slash commands, configuration, theming, MCP servers, skills, plugins, hooks, headless mode, and sandboxing. That list suggests a rich feature set: MCP (Model Context Protocol) servers allow integration with external tools, and plugins/hooks enable custom behavior. The headless mode is explicitly for scripting and CI, which means you can run the agent without the TUI, likely via a stdio interface. The ACP (Agent Client Protocol) support for editor embedding is a significant architectural choice, as it allows editors like VS Code or Neovim to connect to the agent as a client. However, the README does not provide details on how ACP is implemented or which editors are supported, so you would need to consult the online docs at docs.x.ai/build/overview.

Limitations and failure modes

A clear limitation is platform support: macOS and Linux are supported build hosts, while Windows builds are best-effort and not tested from this tree. That means Windows users may face build failures or undefined behavior. Another failure mode is the dependency on DotSlash: the README says it is required so hermetic tools under bin/ can download and run. If dotslash is not on PATH, the build fails, and the sanity check /usr/bin/env dotslash --help is provided to catch that early. The root Cargo.toml being generated is a constraint for developers: editing it is discouraged, and you must work within per-crate Cargo.toml files. Also, since the repository is a periodic sync, the code may lag behind the latest monorepo changes, and the SOURCE_REV file records the monorepo commit SHA, but there is no guarantee of freshness. Finally, external contributions are not accepted, so you cannot submit fixes or features upstream; you would have to fork and maintain your own version.

Licensing and third-party code

First-party code is licensed under Apache-2.0, as stated in the LICENSE file. However, the repository contains vendored third-party code, including in-tree source ports of openai/codex and sst/opencode tool implementations. These are listed in THIRD-PARTY-NOTICES and a crate-local notice at crates/codegen/xai-grok-tools/THIRD_PARTY_NOTICES.md, which includes license texts and an Apache §4(b) change notice. There is also a vendored Mermaid diagram stack under third_party/, with its own NOTICE. This is important for anyone considering redistribution: you must comply with the original licenses of those ports, and the Apache §4(b) notice indicates that modifications to those files must be documented. The README does not provide legal advice, but it clearly signals that not all code in the repository is under Apache-2.0. For a project that claims to be open source, this is a common but often overlooked complication.

Alternative approaches and comparison

A real alternative is the openai/codex project, which is mentioned in the THIRD-PARTY-NOTICES as a source for in-tree tool implementations. OpenAI's Codex is also a terminal-based AI coding agent, but it is a separate project with its own development model. The key difference is that Grok Build ports codex's tool implementations, but Grok Build is a closed-development project (no external contributions), while codex is an open project on GitHub with community involvement. Another alternative is sst/opencode, also referenced as a port source. Opencode is an open-source terminal AI agent that emphasizes a different interaction model. The practical difference is that Grok Build offers a full-screen, mouse-interactive TUI and ACP support, which may not be present in the same way in alternatives. If you value community contributions and independent releases, codex or opencode might be more suitable. The README does not provide a comparison, so this is based on the ports mentioned.

Maintenance and upgrade cost

The repository is synced periodically from a monorepo, which means updates arrive as snapshots, not as incremental commits. There is a changelog at https://x.ai/build/changelog for released binaries, but the source tree may not always match the latest release. For users of the prebuilt binary, upgrades are handled by re-running the install script, which is straightforward. For developers building from source, the maintenance cost is higher: you must keep Rust toolchain and DotSlash updated, and you need to monitor the SOURCE_REV to know which monorepo commit you are on. The README warns that full-workspace builds are slow, so any upgrade that touches many crates could be time-consuming. Also, since external contributions are not accepted, you cannot rely on the community to fix bugs; you must wait for the next sync or fix them in your own fork. The license implications of the vendored code mean that any fork must preserve the notices, adding a compliance overhead.

Editorial conclusion

Grok Build is for developers who want a full-screen, mouse-interactive AI coding agent that can edit files, run shell commands, and manage long tasks from the terminal, with the option to embed it in editors via ACP. It is not for those who need a community-driven project: external contributions are not accepted, and the repository is a periodic sync from a private monorepo. Before adopting it, verify the authentication flow (first launch opens a browser), confirm that your platform is macOS or Linux (Windows builds are best-effort and untested), and check that the DotSlash tool is installed on your PATH, since builds fail without it. Also review the third-party notices, especially the in-tree ports of openai/codex and sst/opencode, to understand licensing implications. If you prefer a project with open contribution and independent releases, look elsewhere.

Official sources

1. Official README
2. Project repository