Grok Build

Grok Build is SpaceXAI’s coding agent for the terminal, and the repository is the agent itself rather than a wrapper around one: 107 workspace members and 4,487 files of Rust that build a single binary, xai-grok-pager, shipped to users as grok. The interactive surface is a full-screen TUI with scrollback, a prompt widget, modal dialogs, a slash-command registry and a status line; the rest is the harness — tool implementations, an agent builder that reads Markdown agent definitions, session storage, a codebase graph, sandboxing, an egress proxy, worktree management with copy-on-write and snapshot support, and headless entry points. Hooks, plugins with their own marketplace, skills and MCP servers extend it, and it reads the Claude Code, Cursor and Codex configuration a project already has. Its public shape is the unusual part: 27,172 stars, 5,112 forks, 241 watchers, and no issues, no pull requests, no discussions and one bot contributor.

Who built itThe repository belongs to an Organization account, and it publishes exactly one contributor and 51 commits. Every one of them — author and committer both — is a GitHub App named grokkybara, which renders in the log as grokkybara[bot] with the noreply address 304785771+grokkybara[bot]@users.noreply.github.com and an app page at github.com/apps/grokkybara. Not a single commit carries a human name, and there are no co-author trailers. The commits are sync manifests rather than authored changes: each is titled “Synced from monorepo” and carries a bullet list of one-line changes plus a Source-Revision trailer naming the monorepo commit, which the 41-byte SOURCE_REV file at the root repeats.

1. 01

   Twenty-seven thousand stars, fifty-one commits, and the same bot in both fields

   The repository was created on 2026-07-14 and pushed to last on 2026-09-29, and in that window it collected 27,172 stars, 5,112 forks and 241 watchers while accumulating 51 commits — 17 in July, 24 in August, 10 in September. The first is titled “Publish harness and TUI open-source” on 2026-07-16; every one after it is titled “Synced from monorepo”. The most valuable thing in that log is who wrote it, and the answer is nobody visible: the API returns grokkybara[bot] as both author and committer for all 51, with the address 304785771+grokkybara[bot]@users.noreply.github.com and a GitHub App page at github.com/apps/grokkybara, and the contributor list has exactly one entry, the same app. Zero commits carry a co-author trailer, so nothing in the published history is attributed to a person, and nothing is attributed to a model by name either. The messages are release manifests: a “Changes:” list of one-line entries — 11 in the newest, and between 11 and 69 across the sixteen most recent — followed by a “Source-Revision:” trailer naming the monorepo commit, which the 41-byte SOURCE_REV file repeats verbatim. Releases and tags are both empty; the version history lives in 166 changelog files with 166 JSON sidecars, running 0.2.0 to 1.0.45 with 0.2.48 skipped, and dated 0.2.120 on 2026-08-03, 1.0.0 on 2026-08-07 and 1.0.45 on 2026-09-29.

2. 02

   A repository with 5,112 forks and nowhere to send a patch

   The community surface is closed on purpose and the closing is documented in a 688-byte file. CONTRIBUTING.md states that the repository does not accept external pull requests or unsolicited patches, that SpaceXAI develops the software internally, and that the public tree is published for source transparency and local builds under Apache-2.0; it adds that no contributor license agreement is offered because external contributions are not accepted. The API agrees with the prose: issues, pull requests, discussions, wikis, pages and the download tab are all disabled, and the pull-request policy is set to collaborators only, so the fork count of 5,112 can only ever produce local copies. Security has its own route out — SECURITY.md, 166 bytes, points vulnerability reports at the company HackerOne program and asks people not to open public issues. The only in-product channel found in the sources points inward as well: the TUI has a feedback modal whose reports are wired through to Slack, including image attachments sent from the terminal, and one sync list mentions recovering timed-out git tags from a Slack prompt. What remains public is documentation at docs.x.ai/build/overview, a changelog page, and a repository that has never recorded a user question.

3. 03

   A TUI that gives the terminal its scrollback back

   The interface is one process with a deliberately boring shape — the pager crate documents an Elm-style loop where input becomes an Action, a dispatcher turns it into an Effect and the Effect updates state, with an AppView owning the welcome screen and sessions and one AgentView per session owning the prompt, scrollback, tool panes and modals — but it makes one choice that dictates the rest of its rendering code. It prints into the normal screen instead of taking over the terminal, keeping a viewport pinned at the bottom so that all the content above it lands in the terminal’s own scrollback and the user scrolls with the terminal, not with the application. To do that the project vendors a fork of ratatui, because the published Terminal API does not expose the viewport position, the back buffer or the resize internals; the fork also enables DCS synchronized output so a batch of updates reaches the screen as one frame. Resize is the visible cost: the code clears the screen, clears the scrollback and re-emits the whole history rather than trusting the terminal to reflow, and it avoids RIS specifically because that escape does not clear scrollback in iTerm and Terminal.app. The same care shows in the key table, which states that Esc never cancels a turn and that mid-turn it only reminds the user about Ctrl+C — and in a test suite that drives a real pseudo-terminal: 301 files under the pager test harness, 218 of them end-to-end, plus 45 scenario definitions in YAML and per-platform frame-time baselines whose continuous integration fails a scenario when p99 grows past 15 percent.

4. 04

   Adopting the rivals’ configuration instead of asking for a migration

   Extensions are grouped behind one modal with three tabs — hooks, plugins and marketplace — and each tab is file-driven: hooks come from a global directory, a project directory, a plugin or a path; plugins are directories bundling skills, agents, hooks and MCP servers, scoped to a user, a project, a command line or a marketplace source; marketplaces are added as a git URL, an owner-slash-repo shorthand or a local path. Then comes the part worth recording, because it is a competitive decision rather than a technical one. The agent reads the configuration of the tools it is up against: Claude Code skills, agents, plugins, installed-plugin and marketplace indexes, project rules and even permissions from the settings files; Cursor rules, skills and MCP configuration; and the AGENTS.md convention shared with Codex, with one-step helpers to import settings and to resume sessions left behind in those tools, and separate compatibility sections in the configuration to switch each source off. The shell documentation devotes a full section to the Claude Code compatibility table, the code carries crates for foreign sessions and external agent migration, and the tool implementations are partly in-tree ports of another agent’s tools with the change notices the licence requires. A project already configured for a competitor therefore needs no migration at all, which is a cheaper acquisition path than an importer.

5. 05

   What the documentation admits, and where it disagrees with itself

   The files are unusually willing to say what does not work. The sandbox chapter lists two limitations in its own words: enforcement uses Landlock on Linux and Seatbelt on macOS, and if the sandbox cannot be applied — an old kernel, missing entitlements — Grok logs a warning and continues without enforcement; and network restriction is only partial, because profiles block network in child processes while in-process HTTP for web search and the model API is untouched, since the agent needs that network to function. The crash handler documents that frame capture is best-effort and may be empty in release builds where the compiler omits frame pointers, and that its alternate signal stack is installed per thread so Tokio workers are not protected. The root README says macOS and Linux are the supported build hosts and Windows builds are best-effort and not tested from this tree, and marks the root Cargo.toml as generated and read-only. The generated manifest itself allows a lint with a note explaining that the project has no merge queue, so violations from other people’s merged code reach main and break the build for everyone. Two smaller disagreements exist between the tree and its own documentation: the third-party index lists six vendored crates including an NFS server and a FUSE client, but only four vendored directories exist, and the npm package documents four supported platforms while the tree ships six per-platform packages.