⏱️ Lectura: 9 min
xAI uploaded the complete source code of Grok Build, the terminal coding agent behind the grok command, to GitHub under the Apache 2.0 license. The repository has already gathered nearly 3,900 stars and confirms something notable: 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, xAI now with Grok Build) is competing for the same format: a terminal agent that reads, edits, and runs code in the user’s project.
TL;DR
- xAI published Grok Build’s source code, the CLI/TUI behind the grok command, under the Apache 2.0 license.
- The repository has gathered nearly 3,900 stars, 570 forks, and 31 watchers on GitHub.
- It’s written in Rust and installs with curl -fsSL https://x.ai/cli/install.sh | bash.
- The compiled binary is called xai-grok-pager and is officially distributed as the grok command.
- The THIRD-PARTY-NOTICES file confirms it ports tools from openai/codex and sst/opencode.
- It supports a headless mode for CI/scripting and the ACP protocol for integrating with editors.
- The full documentation lives at docs.x.ai/build/overview.
- xAI doesn’t 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 is officially distributed as the grok command. According to the project’s documentation, it works as a full-screen TUI (terminal user interface) with mouse interaction, that understands the code in 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 within editors through the Agent Client Protocol (ACP), the same type of protocol other coding 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 for the CLI and its agent runtime. As of this writing, it has gathered nearly 3,900 stars, 570 forks, and 31 watchers.
The project isn’t an actively maintained repository in the traditional open source sense: xAI clarifies in the README that it’s periodically synced from the SpaceXAI monorepo and that external contributions aren’t accepted (as specified in the CONTRIBUTING.md file). The root Cargo.toml file, which defines the workspace members and dependency versions, is auto-generated: the project asks that it be treated as read-only and that each crate’s own Cargo.toml be edited instead.
Context and background
Grok Build enters already-crowded territory. Anthropic’s Claude Code, OpenAI’s Codex CLI, and SST’s opencode all compete to solve the same problem: giving a language model direct access to a repository, with permissions to read, write, and execute 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 code ports 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 didn’t 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: that Grok Build reuses pieces of Codex and opencode under Apache 2.0 isn’t a legal problem, the license explicitly allows it. But it is a sign that the how of these agents (editing files, running commands, showing diffs) is already becoming standardized 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 can’t find it, falls back to a protoc available in PATH or 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 it isn’t actively tested from that code tree.
On top of these 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 at 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: agent runtime"]
B --> C["xai-grok-tools: editing, terminal, search"]
C --> D[("xai-grok-workspace: filesystem, VCS, checkpoints")]
B --> E["ACP: editor integration"]
subgraph Agent
B
C
endHow to get started (or try it)
Installing the pre-compiled 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 --versionThat last command confirms the installation worked and which version is active. To build from source, the workflow stated 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
# ends up in target/release/xai-grok-pager
# quick validation without generating a binary
cargo check -p xai-grok-pager-binTo work within a specific crate during development, the repository recommends not building the entire 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 specific crate’s
Cargo.toml, not the root one: that one is generated and the project itself asks that it be treated 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 of them solve exactly the same problem, and choosing one depends more on the ecosystem you’re already working 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, sync cadence undocumented |
| 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 data point for developers isn’t about performance (the repository doesn’t publish benchmarks), it’s about design: 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 orchestrating those tools.
⚠️ Heads up: Windows support is marked as best effort with no active tests from this code tree: if your team relies on Windows in CI, validate it before adopting it in production.
What’s next
The README points to a changelog for details on fixes and features per version, but doesn’t set a public cadence for releases or syncing with xAI’s internal monorepo. There’s also no dated roadmap in the published material.
What’s verifiable today is the repository’s governance structure: xAI keeps development purely internal (no external pull requests) and releases code snapshots under Apache 2.0, a different pattern from opencode, which does accept community contributions. For developers who want to closely follow changes, the most reliable way 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 containing the Rust code for the grok CLI: the terminal interface, the agent runtime, and the tools it uses to read, edit, and execute 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 within 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 aren’t accepted: the code is periodically synced from SpaceXAI’s internal monorepo.
What operating systems does it run on?
The installed binary is distributed for macOS, Linux, and Windows. As a build host for compiling from source, macOS and Linux are supported; Windows is best effort and isn’t actively tested.
Under what license was the code published?
xAI’s own code in this repository uses the Apache 2.0 license. 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 safely edits files and runs commands. 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, README, and THIRD-PARTY-NOTICES.
- docs.x.ai/build/overview: official Grok Build documentation, with the full user guide.
- x.ai/cli: official product page where xAI introduces 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.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Featured image: Photo by Mohammad Rahmani on Unsplash
0 Comments