On July 15, 2026, xAI open-sourced grok-build — the Rust source for its grok terminal coding agent — under Apache 2.0. That would normally be a boring “big AI lab ships a Claude Code competitor” story. It isn’t, because the day before, developers discovered grok had been quietly uploading their entire working directories — including ~/.ssh, password-manager databases, and personal documents — to Google Cloud buckets controlled by xAI.

The open-source dump landed twenty-four hours after Simon Willison, The Decoder, and a wire-level analysis on Hacker News forced xAI to disable uploads, delete server-side data, and prove there was no telemetry left to hide. So what actually shipped? A remarkably capable coding agent with an interesting extension surface, and a governance story every self-hosted-AI shop should read carefully.

I spent two days building grok from source on macOS, wiring it up in headless mode, and comparing it against Claude Code and OpenAI’s Codex CLI on the same three refactors. This is the review.

What Grok Build actually is

Strip away the marketing at x.ai/cli and Grok Build is four things bundled into one binary:

  1. A full-screen Rust TUI (xai-grok-pager, shipped as grok) with scrollback, mouse support, modals, and a slash-command prompt — the interactive mode most developers will use.
  2. An agent runtime (xai-grok-shell) that runs the same loop three ways: interactive TUI, headless for scripting and CI, and leader/stdio so external IDEs can embed it via the Agent Client Protocol (ACP).
  3. A tool set — file edit, terminal execution, web search, workspace VCS, sandboxed exec, checkpoints — living in xai-grok-tools and xai-grok-workspace. The THIRD_PARTY_NOTICES.md confirms these are ports of openai/codex and sst/opencode tool implementations, licensed compatibly and modified per Apache §4(b).
  4. An extension system — MCP servers, skills, plugins, hooks — that reuses existing Claude Code MCP configs verbatim and follows Anthropic’s skills convention.

The design is not novel. It is deliberately conventional: xAI took the ergonomics developers already learned from Codex CLI and Claude Code, wrote them in Rust for a fast startup and single-binary distribution, and added ACP so orchestration platforms can call it as a primitive. The interesting bits are underneath: sandboxing, the plugin surface, and how honestly xAI handled the reset.

Installation and first-run reality check

The one-liner install works — curl -fsSL https://x.ai/cli/install.sh | bash — but almost nobody reading this post should be running that. The reason I gave the source install two days is that the whole point of the open-source release is verifiability. Here is the minimum you actually need to check:

git clone https://github.com/xai-org/grok-build
cd grok-build
cat SOURCE_REV                       # commit SHA in the xAI monorepo
cargo install dotslash               # required for hermetic bin/protoc
cargo build -p xai-grok-pager-bin --release
./target/release/xai-grok-pager --version

The SOURCE_REV file is xAI’s answer to “is this the same code you’re actually running in production?” — it records the monorepo commit that the public tree was synced from. This does not prove parity (you have to trust that the private monorepo doesn’t diverge silently), but it gives independent researchers a fixed reference to diff subsequent releases against. It’s the same pattern the OpenAI Codex CLI adopted after its own trust incidents.

Two friction points on macOS:

  • DotSlash is mandatory. The tree ships hermetic tool proxies under bin/ (notably bin/protoc for proto codegen). Without dotslash on your PATH, cargo build fails at proto compile time with a cryptic error. cargo install dotslash fixes it.
  • cargo test is slow because it’s monolithic. The README explicitly says “always target specific crates; full-workspace builds are slow.” Follow that advice — cargo test -p xai-grok-config finishes in seconds, cargo test from the workspace root takes minutes on an M2.

Once built, first launch pops a browser to authenticate against your xAI account. If you’re on SuperGrok or X Premium Plus, you get generous usage limits. If you’re not, grok --version still works but the agent loop errors out until you drop an API key into ~/.config/grok/config.toml.

The features that matter

I’ll skip the marketing bullets and cover only the things that changed how I worked.

Plan Mode

Grok Build’s default behavior is agentic — hand it a prompt, watch it edit files. Plan Mode (/plan slash command) flips this: the agent produces a numbered execution plan first, and edits nothing until you accept it. In practice this is the feature I used most, because it lets you preview intent on a task like “extract this component to a shared package” without gambling twelve tool calls on whether the agent understood you.

> /plan
> Extract the auth middleware into @myapp/auth, wire it back into the API app,
  and update the two integration tests that import it.

[grok] Plan:
  1. Read src/middleware/auth.ts and its two imports
  2. Create packages/auth/ with a package.json + src/index.ts
  3. Move auth.ts → packages/auth/src/index.ts, keep public exports
  4. Add @myapp/auth to apps/api/package.json dependencies
  5. Rewrite the two callsites: apps/api/src/routes/*.ts
  6. Update tests: tests/auth.spec.ts, tests/session.spec.ts
  7. Run: pnpm -w test tests/auth.spec.ts tests/session.spec.ts

Accept? [y/n/edit]

You can edit the plan inline before accepting. Claude Code has a similar preview surface; Grok Build’s is cleaner because the numbered structure survives long tasks.

Parallel subagents and worktree isolation

Grok Build can spawn up to eight subagents that operate in isolated Git worktrees — real filesystem branches, not virtualized snapshots. This solves the annoying failure mode where two subagents both try to edit package.json and race each other. Each worktree gets its own copy of the working tree; the parent merges results when they finish.

The killer variant is “Arena Mode” — the same prompt handed to N subagents in parallel, then the outputs diffed and you pick the winner. I ran this on a dagger.io-style pipeline refactor with N=3 and got three meaningfully different approaches. That’s genuinely useful for exploratory refactoring where you don’t yet know the right shape.

The catch: subagents are token-expensive and, if you’re on the API rather than a subscription, wallet-expensive. Turn Arena Mode off by default for routine work.

Headless mode + ACP

The bit that actually justifies the “open source ecosystem primitive” framing is headless + ACP:

grok --headless --input-file task.md --output-file result.json

Headless mode is the piece you wire into CI — deterministic JSON in, deterministic JSON out, no TUI, no colors. Combined with ACP, an orchestration layer (VS Code extension, Cursor, JetBrains, or a custom taskflow-style scheduler) can call grok as one worker among many. Simon Willison called this “the piece that makes it interesting after the trust reset” — and he’s right. Local, verifiable, callable-from-anywhere is the profile that matters for anyone building agent infrastructure.

MCP and Claude Code compat

Grok Build reads existing Claude Code MCP server configs and skills directly. If you already have .mcp.json in a repo and a .claude/skills/ directory, grok picks them up — no re-declaration. This is smart standards-follower behavior and directly relevant to teams that don’t want to rebuild their tooling around a second vendor.

The trust incident, in one paragraph

Before recommending anyone actually run this, the July 14–15, 2026 timeline: a developer on X (@a_green_being) posted evidence that running grok in a home directory uploaded ~/.ssh keys, password databases, personal photos, and the full working tree to xAI-controlled Google Cloud buckets. A privacy toggle in settings appeared to do nothing (Tech Times). xAI initially disputed the retention framing, then within twenty-four hours: (1) disabled the upload behavior in a shipped update, (2) publicly announced deletion of already-uploaded data, and (3) open-sourced the entire client under Apache 2.0 so the wire behavior could be independently audited. The community wire-level analysis on Hacker News documented what current-version grok actually sends, and it is now dramatically narrower — LLM API traffic through an isolated HTTP proxy, no bulk workspace uploads.

Where this leaves us: the current open-source client is auditable and (per the HN wire trace) well-behaved. The prior versions were not. That is a real reason to install from source or the pinned tagged release, not from curl | bash. And if you have any regulatory obligation around code-in-cloud, the correct posture is still “route it through your MCP proxy and don’t accept the default network posture blindly.”

Community reactions

The Hacker News thread on the open-source release ran ~600 comments in three days. Rough breakdown of what developers actually cared about:

  • The wire analysis mattered more than the apology. Multiple top-voted comments explicitly said the open-source release only landed as “acceptable” because independent researchers could immediately diff the network behavior against the prior version.
  • Rust + single binary is a genuine advantage over Node-based Claude Code and Codex CLI for constrained environments (Alpine containers, air-gapped CI). Several commenters flagged this as the reason they were willing to reconsider.
  • The openai/codex and sst/opencode port disclosures got scrutiny but no complaints — the license work is clean, Apache §4(b) change notices are in place, and downstream credit is explicit. This is a small model of how “borrow from upstream, ship compliantly” should look.
  • Some skepticism about the SuperGrok/Premium Plus paywall. The client is open source; access to the actual Grok 4.5 model is not. The community-built superagent-ai/grok-cli exists specifically to route to the xAI Grok API without depending on the official client.

The r/aiagents subreddit tutorial thread has been more practical — configuration examples, MCP server integrations, and how to point grok at non-xAI backends via a proxy.

Honest limitations

Two days of use surfaced these:

  • Cold start is slow. The TUI takes ~800ms to open on my M2, versus ~200ms for Codex CLI. Rust binary size is ~65MB — the TUI dependency tree is not lean.
  • Self-verification loop costs latency. Grok Build re-reads its own edits and re-validates before returning control. This is a correctness win and a speed loss on trivial tasks. There’s no --no-verify flag as of this writing.
  • Windows support is “best effort.” The README is explicit that macOS and Linux are supported build hosts and Windows builds are “not currently tested from this tree.” WSL2 works fine; native Windows is not the target.
  • The full workspace cargo test is prohibitively slow. Contributors will hit this — the README itself flags it. Any PR pipeline needs targeted -p <crate> runs, not full workspace CI.
  • Model choice is coupled to xAI. The client is open source; the recommended model (Grok 4.5) is not. You can point it at any OpenAI-compatible endpoint, but the tool prompts and expectations are tuned for Grok. Substituting a smaller local model degrades quality more than the equivalent swap in Claude Code.
  • The paid-tier gating is confusing. Free-tier accounts can build and launch grok but the agent loop errors on the first tool call unless you’re on SuperGrok/Premium Plus or you’ve supplied an API key with billing. The error message is not great.

FAQ

Is Grok Build safe to use now, after the SSH key upload incident?

The current open-source client (post-July 15, 2026) is significantly safer than the prior closed-source grok binary. The bulk-upload behavior is removed, xAI publicly deleted server-side data, and the Hacker News wire-level analysis confirms the current network posture is narrow. However: (1) install from source or a signed release, not from curl | bash; (2) run it in a sandboxed workspace rather than your home directory; (3) if you have compliance obligations, route traffic through an MCP proxy you control.

How does Grok Build compare to Claude Code and OpenAI Codex CLI?

All three occupy the same terminal-agentic niche. Rough breakdown as of July 2026: Claude Code has the most polished skills/MCP ecosystem and the strongest default behavior on ambiguous prompts. Codex CLI is fastest cold-start and cheapest per-run. Grok Build wins on Plan Mode ergonomics, ACP-first design, parallel subagent worktrees, and the fact that it’s actually open-source under Apache 2.0. If you’re already invested in Claude Code MCP servers, Grok Build reads them without changes. If you need something a CI orchestrator can call as a primitive, Grok Build’s headless mode + ACP is the cleanest surface.

Do I need SuperGrok or Premium Plus?

To use Grok 4.5 through the official flow, yes. To use grok at all, no — you can supply any OpenAI-compatible API key and point the client at your own backend. Community builds like superagent-ai/grok-cli skip the subscription requirement entirely by talking directly to the xAI API.

Can I run Grok Build fully offline or air-gapped?

Kind of. The client itself runs offline once built — the trust reset explicitly enabled local-only operation. But the agent still needs an LLM endpoint, which almost always means a network call. If you point it at a local model (llama.cpp server, Ollama with a code-tuned model, vLLM), you can run genuinely air-gapped. Expect quality regressions versus Grok 4.5; the tool prompts weren’t tuned for smaller models.

Is the Grok Build source really xAI’s production code, or a marketing tree?

The SOURCE_REV file records the monorepo commit and the THIRD_PARTY_NOTICES file discloses vendored code (Mermaid stack, openai/codex port, sst/opencode port). Nothing about the tree looks like a marketing subset — the crate graph is full and functional. The honest answer is: it’s the actual source, but you’re trusting xAI to keep the public tree in sync with what runs in production. Diffing successive SOURCE_REV snapshots is the current best defense.

Should you use it?

If you’re already on Claude Code or Codex CLI and happy, there is no urgent reason to switch. If you’re evaluating a terminal-native agent for CI orchestration, ACP-based tool integration, or you specifically need an open-source, single-binary, Rust agent that can read existing MCP configs — Grok Build earns a serious look. Build from source, pin to a tagged release, keep it in a sandboxed workspace, and treat the July 14 incident as the reminder it is: default network postures on AI coding agents deserve the same scrutiny as any other daemon you install with sudo.

Sources