Grok Build is a mirror of SpaceXAI's monorepo, and it does not take patches

The tree is synced, and CONTRIBUTING.md is where you learn that

The README states the arrangement in three sentences. This repository contains the Rust source for the `grok` CLI and TUI and its agent runtime, it is synced periodically from the SpaceXAI monorepo, and a small `SOURCE_REV` file at the root records the full monorepo commit SHA for the version of the code in the tree.

Then the contributing section, which is one note long: external contributions are not accepted, with a pointer to `CONTRIBUTING.md`.

Those two facts together determine how to treat the repository. It is a read-and-build mirror, not a development surface, and `SOURCE_REV` is the file that lets you map any file you are reading back to a commit in a history you cannot see. GitHub reports no releases for the project, and the release channel is a changelog on the vendor's own site.

The repository is not archived and the last push was on 2026-09-29, so the mirror is current, and that is exactly why the provenance matters: the code is fresh and the fix path does not run through you.

The artifact is xai-grok-pager and the command is grok

The install is a script from the vendor's site, one line per platform, followed by a version check:

curl -fsSL https://x.ai/cli/install.sh | bash   # macOS / Linux / Git Bash
irm https://x.ai/cli/install.ps1 | iex          # Windows PowerShell
grok --version

Both prebuilt binaries are published for macOS, Linux and Windows, and the same script line covers macOS, Linux and Git Bash, with a separate PowerShell form for Windows.

The naming is worth noting because it is confusing at first. The crate that builds the binary is `xai-grok-pager-bin`, the artifact it produces is `xai-grok-pager`, and the installed command is `grok`. The README says so explicitly: official installs ship it as `grok`. So a bug report or a build script that mentions `xai-grok-pager` is referring to the same program you run as `grok`.

One more runtime detail, and it is the first thing a new user meets: on first launch it opens your browser to authenticate, with the authentication guide in the user guide directory.

DotSlash has to be on your PATH before the first cargo command

The build requirements are ordered, and the order matters. Rust is pinned by `rust-toolchain.toml` and `rustup` installs it automatically on the first build, so that part needs no action. DotSlash does need action, because the hermetic tools under `bin/`, notably `bin/protoc`, download and run through it, and the instruction is to install it and ensure `dotslash` is on your `PATH` before building.

cargo install dotslash
# or: prebuilt packages — https://dotslash-cli.com/docs/installation/
/usr/bin/env dotslash --help   # sanity check

That sanity check line is the project's own advice for confirming the step worked.

`protoc` itself is resolved with a fallback: the proto codegen resolves `bin/protoc` via DotSlash, or falls back to a `protoc` on your `PATH` or in `$PROTOC`. Platforms are stated with the same precision. macOS and Linux are supported build hosts, and Windows builds are best-effort and not currently tested from this tree, which is a different statement from unsupported and a useful one to quote in a procurement conversation.

The TUI, the runtime and the tools are three different crates

The repository layout table is the architecture, and it has four rows that matter. `crates/codegen/xai-grok-pager-bin` is the composition root and builds the binary. `crates/codegen/xai-grok-pager` is the TUI itself: scrollback, prompt, modals and rendering. `crates/codegen/xai-grok-shell` is the agent runtime with leader, stdio and headless entry points. `crates/codegen/xai-grok-tools` holds the tool implementations, terminal, file edit and search among them, and `crates/codegen/xai-grok-workspace` owns the host filesystem, version control, execution and checkpoints.

The rest of the closure, the table says, is config, MCP, markdown and sandbox, with small shared leaf crates under `crates/common/`, `crates/build/` and `prod/mc/`, and a vendored upstream stack under `third_party/`.

One consequence is worth drawing out, because it is the difference between a TUI and a harness. The README's layout table puts the leader, stdio and headless entry points on the shell crate, not on the TUI crate. So driving the agent from a script does not mean scripting the interface, which is the property you need before you build CI on it.

Full-workspace builds are slow, and the README tells you to avoid them

The development section is four commands and a warning, and the warning is the useful part: always target specific crates, because full-workspace builds are slow.

cargo check -p <crate>        # always target specific crates; full-workspace builds are slow
cargo test -p xai-grok-config # per-crate tests
cargo clippy -p <crate>       # lint config: clippy.toml at the repo root
cargo fmt --all               # rustfmt.toml at the repo root

The build commands above it are the same idea for the binary: `cargo run -p xai-grok-pager-bin` to build and launch the TUI, `cargo build -p xai-grok-pager-bin --release` for a release binary at `target/release/xai-grok-pager`, and `cargo check -p xai-grok-pager-bin` as the fast validation pass.

The workspace member list explains why the warning exists. It is long, one entry per concern, including crates named for the code tasks they perform: `xai-codebase-graph`, `xai-compaction-transcript`, `xai-fuzzy-file-search`, `xai-fast-worktree`, `xai-gix-status`, `xai-grok-hooks`, `xai-fsnotify`, `xai-crash-handler`, `xai-grok-egress-proxy`, `xai-grok-diag-server`, `xai-grok-dashboard-store`, and a `ptyctl` pair. A reader trying to understand the agent from the directory names alone gets a surprisingly accurate map of what it does.

The root Cargo.toml is generated, and one dependency is a pinned fork

The README marks its own manifest with an IMPORTANT block: the root `Cargo.toml`, covering workspace members, dependency versions, lints and profiles, is generated, should be treated as read-only, and the recommendation is to edit per-crate `Cargo.toml` files instead. The file agrees, opening with a comment saying it is auto-generated.

The generated root is also where the dependency policy is visible, and one line is worth reading twice. Under `[patch.crates-io]`, the `async-openai` crate is redirected to a fork hosted at `our-forks/async-openai`, pinned to a specific revision SHA.

So a build of this tree fetches a particular commit of somebody else's repository, chosen by the vendor, and you cannot change that from the root manifest because the root manifest is generated. For anyone vendoring the code, that is the line to audit, along with the `Cargo.lock` and the `.cargo/` configuration directory at the root. The workspace also declares resolver 2, which is worth knowing if you are comparing build behaviour against an older checkout of the same code.

The notices name two other agents' tool implementations

Licensing here is layered, and the layering is documented rather than assumed. First-party code is under the Apache License 2.0 with the `LICENSE` file at the root, and third-party and vendored code remains under its original licences.

Then three notice files, each with a stated scope. `THIRD-PARTY-NOTICES` covers crates.io and git dependencies, bundled UI themes, and in-tree source ports, naming openai/codex and sst/opencode tool implementations among them. `crates/codegen/xai-grok-tools/THIRD_PARTY_NOTICES.md` is the crate-local notice for the codex and opencode ports, holding licence texts and an Apache section 4(b) change notice. `third_party/NOTICE` indexes the vendored Mermaid diagram stack.

The section 4(b) mention is the detail that matters for a reader auditing the tree. A change notice is what a port of someone else's code is required to carry, so its presence in the tools crate is the signal that those files are adapted rather than original, and the notice file is where you find the licence text for each one.

For a project that has absorbed parts of two other coding agents, that documentation is the part to read before deciding how much of it you want to build on.

Editorial conclusion

Grok Build fits someone who wants to read, build or vendor a Rust coding agent harness, or who wants the documented headless and Agent Client Protocol entry points rather than a hosted product. It does not fit anyone planning to contribute, because the repository states that external contributions are not accepted, and it does not fit a Windows team that needs a supported source build, since that is described as best-effort and untested from this tree. Before building, install DotSlash so `bin/protoc` can resolve, and read SOURCE_REV, because a change you make here is not a change upstream.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases