Grok Build Open Source: What It Actually Means for You

Two days ago, xAI open-sourced Grok Build – their terminal coding agent. On paper, it’s a normal open-source announcement. In context, it’s damage control.

A week earlier, security researchers found that Grok Build had been uploading tracked Git repositories and full commit history to xAI storage by default, including unredacted .env secrets. Not snippets. Whole repos. Sam Altman called it “concerning.” Musk’s response was to publish the source code so you can audit – and better yet, run – the tool without xAI’s servers in the loop at all.

This tutorial shows you what to actually do with that: compile it yourself, point it at your own inference, and understand what changed. If you’ve been holding off on Grok Build because of the privacy story, this is the version to try.

What actually shipped when Grok Build went open source

The repo lives at github.com/xai-org/grok-build. It’s Rust. According to the xAI announcement, the published source includes the agent loop (context assembly, response parsing, tool-call dispatch), the tools (reading, editing, searching code, running commands), the terminal UI (rendering, plan review, inline diff viewer), and the extension system for skills, plugins, hooks, MCP servers, and subagents.

What it does not include: the Grok 4.5 model weights. This is an agent runtime wrapper release, not a model release. You can compile the agent and run it against xAI’s API, a proxy, or any OpenAI-compatible endpoint – but the intelligence still has to come from somewhere.

Before you touch the source, check the license file. First-party code is Apache 2.0, but external contributions are not accepted – see CONTRIBUTING.md. It’s open source you can fork and run, not open source you can collaborate on. Practical difference: bug fixes stay in your fork.

Building Grok Build from source (the real reason this matters)

Skip the curl installer everyone’s blogging about. If you’re reading this, you want the local-first path. Here’s the minimum viable build.

# 1. Clone the repo
git clone https://github.com/xai-org/grok-build.git
cd grok-build

# 2. Rustup handles the toolchain automatically
# (rust-toolchain.toml is pinned in the repo)

# 3. Build the release binary
cargo build -p xai-grok-pager-bin --release

# 4. The binary is at target/release/xai-grok-pager
# Alias it as `grok` so docs work
sudo ln -s $(pwd)/target/release/xai-grok-pager /usr/local/bin/grok

Gotcha worth knowing: the binary artifact is named xai-grok-pager; official installs ship it as grok. If you skip the symlink and later run which grok, you’ll get nothing and assume the build failed. It didn’t – you just haven’t renamed it.

Second gotcha, buried in the README: macOS and Linux are supported build hosts; Windows builds are best-effort and not currently tested from this tree. The PowerShell installer for the prebuilt binary works fine on Windows, but compiling from source is a different animal. If you’re on Windows and want the audited local build, WSL2 is the sane path.

Pointing it at your own inference

This is the part that makes open-sourcing meaningful. Compile the binary, point it at a local inference server, and the agent runs without touching xAI’s infrastructure. Configuration lives at ~/.grok/config.toml (or %USERPROFILE%.grokconfig.toml on Windows). The $GROK_HOME environment variable overrides the default location if you need to manage multiple configs.

Here’s a working config that routes Grok Build to a local Ollama server instead of xAI:

[models]
default = "local-coder"

[model.local-coder]
model = "qwen2.5-coder:14b"
base_url = "http://localhost:11434/v1"
name = "Local Qwen Coder"
env_key = "OLLAMA_API_KEY" # any non-empty value works
api_backend = "chat_completions"
context_window = 32768

Then export OLLAMA_API_KEY=local, launch grok, and run grok inspect to confirm it worked. Per the official docs, grok inspect shows what Grok discovered in the current directory, including config sources, instructions, skills, plugins, hooks, and MCP servers. If the model line doesn’t say “local-coder,” your TOML is wrong.

Common pitfalls to avoid

Open-sourcing the agent runtime wrapper does not open-source Grok 4.5. That’s the first confusion to shake: you still need an API key or a local model to do actual work – the repo is the agent loop, not the brain.

If you used Grok Build before July 15, your repos were on xAI storage. xAI says all previously uploaded user data has been permanently deleted and data retention disabled going forward (as of July 15, 2026) – but that’s their word, and it doesn’t undo what already made it into logs or backups elsewhere. Rotate any secrets that lived in .env files. Don’t skip this step on the assumption the deletion was complete.

The contributions clause will catch you if you fork to fix a bug expecting to send a PR. It won’t be accepted – your fix lives in your fork. Plan accordingly: document your patches clearly so you can rebase them when upstream ships a new version.

What the source actually reveals

Reading the codebase is the closest thing to a real audit. The interesting file is the agent loop – it shows exactly how context gets assembled before it hits the model. That’s where the repository-upload behavior lived. If xAI ever ships a hook that quietly re-enables cloud sync, you’ll be able to see it in the diff.

That’s the honest value proposition of this release. It’s not that you’ll read 100,000 lines of Rust for fun. It’s that someone will, and now they can.

When NOT to bother with the open-source build

If you’re writing greenfield code with no secrets in the tree, the prebuilt installer is faster and the auto-updates are convenient. The compile-from-source path makes sense when you need to run against non-xAI inference, when compliance rules make cloud coding agents a non-starter, or when you want to inspect the tool call surface before letting an agent touch production code. Outside those cases, the prebuilt binary and the source build do the same thing – one just takes ten minutes longer to set up.

FAQ

Is Grok Build really open source or just source-available?

Technically open source – it’s Apache 2.0. In spirit, source-available. You can read it, fork it, run it, and modify it for your own use. You just can’t contribute back.

Can I run Grok Build entirely offline with a local model?

Yes, once you’ve compiled the binary. Point base_url in your config.toml at a local Ollama or llama.cpp server and the agent will run without touching xAI’s infrastructure. Keep in mind: the agent loop is only as capable as the model behind it. Community reports suggest coding-tuned models perform better than general-purpose ones for this use case, though your mileage will vary by task and hardware.

Should I switch from Claude Code to Grok Build now that it’s open?

The switching cost is genuinely low – the docs indicate Grok Build reads standard agent instruction files, so your existing project instructions may carry over. Whether it’s better is a different question and depends on the model you point it at more than the agent itself. Try it for a week on a side project before migrating anything you care about.

Next step: Clone the repo, run cargo build -p xai-grok-pager-bin --release, and read the docs/ directory in the repo. That’s where the actual answers live – not in blog posts, including this one.