Grok Build Open Source: SpaceXAI Publishes the Rust Coding Agent Harness

In the early hours of July 16, 2026 (UTC), SpaceXAI posted that it had open-sourced Grok Build and reset usage limits for all users. The announcement landed four days after the repository-upload privacy crisis — wire tests that captured full Git bundles, a server-side mitigation, Musk's deletion pledge, and a July 12 policy change that disabled default data retention.

The product page is live at x.ai/news/grok-build-open-source. The code is at github.com/xai-org/grok-build. This is not a README drop: the tree is a ~1 million-line Rust workspace (51M+ bytes of Rust per GitHub's language breakdown) shipping the same grok CLI that powers Grok 4.5's agentic coding stack.

"We've open-sourced Grok Build and have reset usage limits for all users. Open sourcing Grok Build allows anyone to support making a reliable and robust harness." — SpaceXAI, July 16, 2026

For developers asking "is this real open source or a publicity dump?" — the license is Apache 2.0, the agent loop is readable, and local-first inference is documented. For developers asking "can I fork and PR fixes?" — no. External contributions are explicitly rejected, and GitHub issues are disabled. Those two facts define what this release actually is: source transparency, not a community-governed project like OpenCode or Kimi K2.7-Code.

TL;DR: What People Are Asking

What Grok Build Is (and What the grok CLI Is)

Grok Build is SpaceXAI's terminal-native agent harness — the scaffolding that wraps a model with tool execution, context assembly, session state, sandboxing, and a fullscreen mouse-interactive TUI. The README describes it as:

"SpaceXAI's terminal-based AI coding agent. It runs as a full-screen TUI that understands your codebase, edits files, executes shell commands, searches the web, and manages long-running tasks — interactively, headlessly for scripting/CI, or embedded in editors via the Agent Client Protocol (ACP)."

The grok command is the user-facing CLI binary. Official installs ship the compiled artifact xai-grok-pager as grok. There is no separate "Grok CLI" product line in the published tree — Grok Build is the harness behind that binary.

That distinction matters when comparing to OpenAI Codex (plain text — no outbound link). Codex is OpenAI's proprietary coding agent with its own CLI, OAuth, and plugin ecosystem. Grok Build is xAI's harness, trained against Grok 4.5 and documented in the private beta harness notes. They solve the same job — agentic coding in a terminal — but ship from different vendors with different trust postures.

Repository Structure at a Glance

SpaceXAI's published layout maps cleanly onto standard harness components:

The root Cargo.toml is generated and read-only — SpaceXAI develops in an internal monorepo and syncs this public mirror periodically. That is closer to Google's occasional OSS dumps than to OpenClaw's community fork culture, though Apache 2.0 still lets you inspect, compile, and run locally.

Install and Build Commands

Released binary (recommended for most users)

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

Then start an interactive session:

cd your-project
grok

First launch opens a browser for authentication. For CI or headless environments:

export XAI_API_KEY="xai-..."
grok -p "Explain this codebase"

Full setup docs: docs.x.ai/build/overview.

Build from source

Requirements: Rust (pinned in rust-toolchain.toml), protoc (bundled via dotslash or $PATH).

git clone https://github.com/xai-org/grok-build.git
cd grok-build
cargo run -p xai-grok-pager-bin              # build + launch TUI
cargo build -p xai-grok-pager-bin --release  # release binary
cargo check -p xai-grok-pager-bin            # fast validation
cargo clippy -p xai-grok-pager-bin           # lint
cargo fmt --all                              # format

Development guidance in the README warns that full-workspace builds are slow — target specific crates with -p.

Local-First: Point Grok at Your Own Model

SpaceXAI's open-source announcement emphasizes local-first operation: compile the harness yourself, configure a custom endpoint, and drive inference without the default cloud path.

Add a model block to ~/.grok/config.toml (Windows: %USERPROFILE%\.grok\config.toml):

[model.my-local]
model = "model-id"
base_url = "https://api.example.com/v1"
name = "My Local Model"
env_key = "API_KEY"

[models]
default = "my-local"

Then verify discovery and run headless:

grok inspect
grok -p "Hello" -m my-local

This is the same pattern we document for running OSS models in Codex and OpenCode local stacks — bring your own weights, keep the harness. Pair with open-weight models like Kimi K2.7-Code if you want a fully auditable pipeline.

Caveat: local inference removes xAI's server from the model path, but does not automatically eliminate every telemetry or auth channel in a given build. Read the source, run grok inspect, and packet-capture before putting regulated data through any agent — the lesson from July's upload scandal applies to every harness in our MCP security guide.

The Codex and OpenCode Ports (Verified, Not Rumor)

X threads claimed Grok Build "uses Codex code." The repo answers that question directly in THIRD_PARTY_NOTICES.md:

From OpenAI Codex (Apache 2.0) — Rust ports under src/implementations/codex/:

• apply_patch
• grep_files
• list_dir
• read_file

From sst/opencode (MIT) — ports under src/implementations/opencode/:

• bash, edit, glob, grep, read, skill, todowrite, write

SpaceXAI documents these as modified ports with Apache §4(b) change notices — standard practice when borrowing battle-tested tool handlers. It does not mean Grok Build is a wholesale Codex fork; the TUI, agent loop, workspace layer, and xAI-specific integrations are first-party Rust. It does mean anyone auditing Grok Build should read both the harness architecture and the ported tool paths — the same diligence we recommend for system prompt leaks and third-party agent tools like OpenClaw.

Why Issues and PRs Are Disabled

GitHub's API confirms:

• has_issues: false
• has_pull_requests: false
• pull_request_creation_policy: collaborators_only

CONTRIBUTING.md is explicit:

"This repository does not accept external pull requests or unsolicited patches. SpaceXAI develops this software internally. The public tree is published for source transparency and local builds."

Security reports route through HackerOne per SECURITY.md — not public GitHub issues.

Practical implications:

If you need a community-mergeable harness, OpenCode, Pi, or DeerFlow 2 remain the explainx.ai defaults. Grok Build's value is inspecting a frontier-lab harness that ships with Grok 4.5 — not co-maintaining it.

Privacy, Retention, and Trust Recovery

Open-sourcing arrived in the same week SpaceXAI addressed the repository-upload backlash. In follow-up posts summarized across X and press coverage, SpaceXAI stated:

1. ZDR was always respected when users disabled upload — including for API-key sessions.
2. Early beta enabled retention by default for non-ZDR users; that changed after feedback.
3. July 12, 2026: default retention disabled for all users.
4. Deletion underway for previously retained coding data.
5. Open source + local-first lets teams verify behavior instead of trusting marketing copy.

That is a stronger remediation arc than most closed-source agents offer — but it is still trust recovery, not a cryptographic proof. Musk pledged total deletion of pre-July-14 uploads; independent audit certificates have not been published. Run /privacy in the CLI, capture output for compliance records, and keep proprietary repos off unverified consumer sessions until you have packet-level confirmation on your account.

The usage-limit reset is a separate goodwill gesture — reportedly correcting prompt-cache regressions that burned quotas faster than users expected. Reset limits do not fix privacy; open source does not fix quotas on cloud auth paths. Treat each announcement on its own merits.

Grok Build vs Other Open Agent Harnesses

For harness engineering theory — why the scaffolding matters as much as the model — see What Is an Agent Harness and Terminal-Bench harness patterns. SpaceXAI's own framing matches that thesis: open-sourcing makes the harness "reliable and robust" through inspectability, not through star count.

What to Do Today

If you already use Grok Build: limits are reset — check the Usage tab in settings. Run /privacy before returning sensitive repos. Update to the latest release via the install script.

If you want to audit before trusting: clone xai-org/grok-build, read xai-grok-shell and xai-grok-tools, and diff the Codex/OpenCode ports. Build locally and point at a test endpoint.

If you need community governance: fork under Apache 2.0 is legal; upstream merge is not. Evaluate OpenCode or Chinese open-agent stacks like Kimi K2.7 instead.

If you report security issues: use HackerOne xAI — not GitHub.

SpaceXAI joining the open-harness club is a meaningful shift for a lab that also ships Grok weights on Hugging Face. The release is best read as verification infrastructure after a brutal July — source you can compile, policies you can test, and a harness you can study even if you never send SpaceXAI another private repository.

Related on explainx.ai

• Grok Build Mode — prompt-to-app (Jul 28, 2026)
• Limit reset day — Cursor doubles Grok 4.5 included usage (Jul 16)
• Grok Build repository upload: evidence, ZDR, and mitigation
• Grok 4.5 launch, benchmarks, and coding stack
• What is an agent harness?
• OpenCode: open-source model-agnostic harness
• Kimi K2.7-Code open-weight coding model
• Codex with open-source models (Ollama, OSS mode)
• MCP security guide: trust boundaries for agent tools
• xAI Grok open weights on Hugging Face

Primary sources: xAI Grok Build open-source announcement · github.com/xai-org/grok-build · Grok Build documentation · CONTRIBUTING.md · THIRD_PARTY_NOTICES.md · HackerOne xAI · Grok Build changelog

This article reflects the public repository and official announcements as of July 16, 2026. Star counts, quota policies, and retention behavior change frequently — verify on GitHub and in your own /privacy output before deploying on sensitive codebases.