⏱️ Lectura: 9 min
xAI uploaded the complete code of Grok Build to GitHub, the terminal code agent that runs behind the grok command, under the Apache 2.0 license. The repository already has nearly 3,900 stars and confirms something striking: a good part of its editing and search tools are ported directly from openai/codex and sst/opencode.
📑 En este artículo
The release comes at a time when nearly every major lab (Anthropic with Claude Code, OpenAI with Codex CLI, and now xAI with Grok Build) is competing over the same format: a terminal agent that reads, edits, and runs code in the user’s project.
TL;DR
- xAI published Grok Build’s code, the CLI/TUI behind the grok command, under the Apache 2.0 license.
- The repository has accumulated nearly 3,900 stars, 570 forks, and 31 watchers on GitHub.
- It is written in Rust and installs with curl -fsSL https://x.ai/cli/install.sh | bash.
- The compiled binary is called xai-grok-pager and ships officially as the grok command.
- The THIRD-PARTY-NOTICES confirms that it ports tools from openai/codex and sst/opencode.
- It supports headless mode for CI/scripting and the ACP protocol for integrating into editors.
- The full documentation lives at docs.x.ai/build/overview.
- xAI does not accept external contributions: the repo is synced from its internal monorepo.
Introduction
Grok Build is the name of the repository; the binary it installs is called xai-grok-pager and ships officially as the grok command. According to the project’s documentation, it works as a full-screen TUI (terminal interface), interactive with the mouse, that understands the code of the repository where it runs, edits files, executes shell commands, and searches the web.
It can also run headless for scripting or CI integration, or embedded inside editors via the Agent Client Protocol (ACP), the same type of protocol other code agents use to connect to IDEs without relying on a proprietary extension.
What Happened
The xai-org/grok-build repository went public on GitHub with the Rust source code of the CLI and its agent runtime. As of this article, it has accumulated nearly 3,900 stars, 570 forks, and 31 watchers.
The project is not an active repository in the traditional open source style: xAI clarifies in the README that it is periodically synced from the SpaceXAI monorepo and that external contributions are not accepted (as the CONTRIBUTING.md file specifies). The root Cargo.toml file, which defines the workspace members and dependency versions, is generated automatically: the project asks you to treat it as read-only and instead edit the Cargo.toml of each crate.
Context and History
Grok Build enters already-occupied territory. Anthropic’s Claude Code, OpenAI’s Codex CLI, and SST’s opencode compete to solve the same problem: giving a language model direct access to a repository, with permissions to read, write, and run commands.
What sets this release apart is the transparency about its origin. The repository’s THIRD-PARTY-NOTICES file details that the tool implementations inside crates/codegen/xai-grok-tools include ports of code from openai/codex and sst/opencode, with the change notices required by section 4(b) of the Apache 2.0 license. In other words: xAI did not rewrite from scratch how an agent edits a file or runs a terminal command, it adapted implementations that already existed in two competing projects, both also open source.
💭 Key point: the fact that Grok Build reuses pieces of Codex and opencode under Apache 2.0 is not a legal problem, the license explicitly permits it. But it is a signal that the how of these agents (editing files, running commands, showing diffs) is already standardizing across different labs.
Grok Build’s Technical Details and Performance
The project is written in Rust, with the toolchain version pinned in rust-toolchain.toml (rustup installs it automatically on the first build). It also needs protoc for protobuf code generation: the build first resolves bin/protoc (a dotslash launcher) and, if it doesn’t find it, falls back to a protoc available on PATH or in the $PROTOC variable.
The architecture is organized into crates separated by responsibility:
| Crate | Contents |
|---|---|
xai-grok-pager-bin |
Root composition package; builds the xai-grok-pager binary |
xai-grok-pager |
The TUI: scrollback, prompt, modals, rendering |
xai-grok-shell |
Agent runtime and the leader/stdio/headless entry points |
xai-grok-tools |
Tool implementations: terminal, file editing, search |
xai-grok-workspace |
Host filesystem, VCS, execution, checkpoints |
third_party |
Vendored third-party code (the Mermaid diagram stack) |
macOS and Linux are the supported build hosts; Windows is best effort, and the repository itself clarifies that it is not actively tested from that source tree.
On top of those pieces, the runtime adds features that are already standard in this category of tools: MCP servers, skills, plugins, hooks, visual themes, and sandboxing to limit what the agent can execute. The full guide to all these pieces lives in crates/codegen/xai-grok-pager/docs/user-guide/ within the repository itself, and also at docs.x.ai/build/overview.
flowchart TD
A["Terminal TUI"] --> B["xai-grok-shell: runtime del agente"]
B --> C["xai-grok-tools: edicion, terminal, busqueda"]
C --> D[("xai-grok-workspace: filesystem, VCS, checkpoints")]
B --> E["ACP: integracion con editores"]
subgraph Agente
B
C
end
How to Get Started (or Try It)
Installing the precompiled binary is a one-liner, with variants for each operating system:
# macOS / Linux / Git Bash
curl -fsSL https://x.ai/cli/install.sh | bash
# Windows PowerShell
irm https://x.ai/cli/install.ps1 | iex
# Verify installation
grok --version
That last command confirms the installation worked and which version is active. To build from source, the flow declared in the README is this:
# build + launch the TUI
cargo run -p xai-grok-pager-bin
# release binary
cargo build -p xai-grok-pager-bin --release
# lands in target/release/xai-grok-pager
# quick validation without generating a binary
cargo check -p xai-grok-pager-bin
To work inside a specific crate during development, the repository recommends not building the full workspace (it’s slow) and instead targeting the specific crate:
cargo check -p <crate>
cargo test -p xai-grok-config
cargo clippy -p <crate>
cargo fmt --all
💡 Tip: if you’re going to touch workspace dependencies or versions, edit the
Cargo.tomlof the specific crate, not the root one: that one is generated and the project itself asks you to treat it as read-only.
On first launch, grok opens the browser to authenticate the session before letting you use the agent.
Impact and Analysis
The most direct comparison is with the other agent terminals that already have traction among developers. None solves exactly the same thing, and choosing one depends more on the ecosystem you already work in than on a dramatic technical difference:
| Option | When to use it | Advantage | Limitation |
|---|---|---|---|
| Grok Build (xAI) | You already use Grok models or want a Rust CLI with native ACP | Open source, Rust TUI, sandboxing, and headless mode | Doesn’t accept external contributions, undocumented sync cadence |
| Codex CLI (OpenAI) | OpenAI ecosystem, ChatGPT integration | Wide adoption, same lineage as the tools Grok Build ports | Tied to OpenAI’s model catalog |
| opencode (SST) | You prefer a model-provider-agnostic project | Supports multiple LLM providers from the same CLI | Smaller community, fewer native integrations |
| Claude Code (Anthropic) | You already use Claude models in your workflow | Deep integration with the Claude family, mature skills and hooks | Designed primarily for the Anthropic ecosystem |
The most relevant fact for developers is not about performance (the repository publishes no benchmarks), it’s about design: the fact that Grok Build shares a tool base with Codex and opencode suggests that the layer of how an agent touches a repository (reading a diff, applying a patch, running a test) is becoming a shared standard, while the real competition shifts to the model that orchestrates those tools.
⚠️ Heads up: Windows support is marked as best effort and without active tests from this source tree: if your team relies on Windows in CI, it’s better to validate it before adopting it in production.
What’s Next
The README points to a changelog for the detail of fixes and features per version, but it doesn’t set a public cadence for releases or for syncing with xAI’s internal monorepo. Nor is there, in the published material, a roadmap with dates.
What’s verifiable today is the repository’s governance structure: xAI keeps development purely internal (no external pull requests) and releases snapshots of the code under Apache 2.0, a pattern different from opencode’s, which does accept community contributions. For developers who want to follow the changes closely, the most reliable route is to watch the repository’s commits and the documentation at docs.x.ai/build/overview.
📖 Summary on Telegram: View summary
Try it yourself: run curl -fsSL https://x.ai/cli/install.sh | bash and then grok --version to see if the agent starts up in your own terminal.
Frequently Asked Questions
What is Grok Build?
It’s the open source repository that contains the Rust code of the grok CLI: the terminal interface, the agent runtime, and the tools it uses to read, edit, and run code in a project.
Is it the same as the Grok language model?
No. Grok Build is the tool (the terminal client and its agent runtime); the language model that responds inside that terminal is a separate xAI product.
Can I submit a pull request to the repository?
No. The project’s own CONTRIBUTING.md states that external contributions are not accepted: the code is periodically synced from SpaceXAI’s internal monorepo.
Which operating systems does it run on?
The installed binary ships for macOS, Linux, and Windows. As a build host from source, macOS and Linux are supported; Windows is best effort and not actively tested.
Under what license was the code published?
xAI’s own code in this repository uses the Apache 2.0 license. The vendored or ported third-party code (like the pieces from Codex and opencode) keeps its original license, detailed in THIRD-PARTY-NOTICES.
Why does the code reuse parts of Codex and opencode?
Because both projects already solved, in open source, the problem of how an agent edits files and runs commands safely. xAI adapted those implementations inside xai-grok-tools instead of rewriting them from scratch, complying with the change notices required by the Apache 2.0 license.
References
- github.com/xai-org/grok-build: official repository with the source code, the README, and the THIRD-PARTY-NOTICES.
- docs.x.ai/build/overview: official Grok Build documentation, with the complete user guide.
- x.ai/cli: official product page where xAI presents the
grokCLI. - github.com/openai/codex: one of the projects Grok Build ports tool implementations from.
- github.com/sst/opencode: the other open source project whose tools were adapted inside Grok Build.
📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion
Imagen destacada: Foto de Mohammad Rahmani en Unsplash
0 Comments