// you commented GROK
Every coding agent ships the same black box: the bit that reads your codebase, edits your files and runs your shell. You pay per token for the privilege of not seeing it.
Grok Build ships that bit as Rust anyone can read. Below: what the install actually does to your machine, the real config file, and the one line that points it at a model on your own hardware — the line their own documentation leaves out.
What it is — the harness, not the model
Grok Build (grok) is SpaceXAI's coding agent harness and TUI. Full-screen terminal app: reads your codebase, edits files, runs your shell, searches the web, holds long jobs. Also runs headless for CI, or inside your editor over ACP.
Rust. Apache-2.0 on the first-party code. 23,888 stars and 4,537 forks nineteen days after it went up, last pushed 31 July, stable at 0.2.118. Repo: github.com/xai-org/grok-build
What it is not: the model. The weights aren't in there. That's the point — you bring your own. One naming note so you don't think you're in the wrong place: the org is xai-org, but every word of branding in the README says SpaceXAI.
1. Install — and what the one-liner actually does
The reel only showed the curl one. PowerShell is a different command:
# macOS / Linux / Git Bash
curl -fsSL https://x.ai/cli/install.sh | bash
# Windows PowerShell
irm https://x.ai/cli/install.ps1 | iex
# pin a version instead of taking latest
curl -fsSL https://x.ai/cli/install.sh | bash -s 0.2.118Here's what didn't fit in the reel. The script is 447 lines of readable bash, no sudo, and everything lands in $HOME. What it touches:
Downloads the binary to
~/.grok/downloads/, then runs--versionon it before installing. If it doesn't run, it deletes it and keeps your existing install.Symlinks two commands, not one:
grokandagent, same binary. Checkagentisn't shadowing something you already run.Creates
~/.grok/config.tomlcontaining only[cli] installer = "internal". That line is normal, not a leftover.Appends a marked block to your shell rc, backing it up first as
<rc>.bak.<timestamp>. Plus shell completions for bash, zsh and fish.
The installer itself is a plain file you can open first. If piping a shell script from an AI lab into bash bothers you, don't pipe it — open it. Then check it worked with grok --version and grok models.
And the undo, because there is no grok uninstall. The only uninstall in the CLI is for plugins. Worth knowing before you run anything:
rm -f ~/.grok/bin/{grok,agent} ~/.local/bin/{grok,agent}
rm -f /usr/local/bin/{grok,agent}
rm -rf ~/.grok/downloads ~/.grok/completions
rm -f ~/.config/fish/completions/grok.fish
# then delete the marked block from your shell rc
rm -rf ~/.grok # full wipe: also sessions + credentials2. The real ~/.grok/config.toml
The file doesn't exist until you or the installer make it. Missing file means built-in defaults, so you only write what you want to change. Precedence, highest wins: CLI flags, then environment variables, then this file, then managed config, then defaults. That order matters in a minute.
There are 24 sections in the shipped docs. These are the six lines worth having:
[cli]
auto_update = true
[models]
default = "grok-4.5"
[features]
telemetry = false
remote_fetch = false
[session]
auto_compact_threshold_percent = 85path | what's in it |
|---|---|
| main config |
| credentials, 0600, auto-managed |
| saved sessions |
| internal logs |
| per-project MCP servers, plugins, permissions |
3. The local model — the bit you commented for
Ollama. This is their documented example, with the one field their example leaves out:
[model.local]
model = "codellama"
base_url = "http://localhost:11434/v1"
name = "CodeLlama (local)"
api_key = "local"
context_window = 128000
[models]
default = "local"The whole trick is the api_key line.
Leave api_key out and Grok still throws you at the grok.com login screen on first launch. Not a bug: a model with no credential of its own isn't classified as bring-your-own, so session auth still governs it.
Put it in and two things flip at once. The login screen goes — Grok advertises the API-key auth method first, and the TUI reads that first entry to decide whether to prompt you. And your session token stops being attached to that endpoint at all: there's a gate in the auth code saying a bring-your-own model cannot leak to a third-party BYOK endpoint. The source's words, not mine. There's even a regression-guard comment in that file, because an earlier version got the ordering wrong and "made the pager send per-model-key users to the login screen".
Your local server never checks that key. Any non-empty string works. It's a flag to Grok, not a credential for your machine.
Any other OpenAI-compatible server — llama.cpp, vLLM, LM Studio — is the same shape, just a different base_url and model. Then:
grok models # confirm it's listed
grok -m local # or /model local inside the TUITwo things that will bite you. Set context_window to whatever your model actually has — leave it out and Grok assumes 200,000 tokens and mis-times auto-compaction. You don't need api_backend: it defaults to chat_completions, which is exactly what Ollama and llama.cpp speak.
Does it actually stop phoning home?
Fair question, and the honest answer has an asterisk.
Telemetry is off by default — but the default is the last link in the chain. Resolution order is: requirements pin, environment variable, your config file, remote settings, built-in default. A remote settings fetch sits above that default, so it can turn telemetry on. Your config sits above remote. So don't lean on the default. Pin it:
[features]
telemetry = false # pins it above anything remote
remote_fetch = false # no remote policy can arrive at all
[telemetry]
trace_upload = false # session traces are a separate switchEnv equivalent is GROK_TELEMETRY_ENABLED. OpenTelemetry to your own collector is a third, independent switch, off by default, double opt-in.
And your session token is never attached to a BYOK endpoint — that's the gate from the last section, enforced in the harness, not promised in a README. Which is the real value of a readable agent: you don't have to take my word for any of this.
Also worth knowing
Headless for CI with grok -p and JSON output. Editor embedding over ACP. MCP servers, subagents, skills, hooks and sandboxing, configurable per project.
The one that matters if you're coming from Claude Code: it reads AGENTS.md, and it reads CLAUDE.md too, for compatibility. Your existing project rules just work. Nothing to port.
Two limits. External contributions aren't accepted and GitHub Issues are disabled — you can read it and fork it, you can't patch it upstream. And building from source is a separate path wanting DotSlash and protoc; you don't need it. The released binary does every single thing on this page.
I read the source so you get the config that works, not the one from the README. Point it at something tonight and reply with which model you ran — I want to know what holds up locally.
Talk soon,
Mike
PS — this is the kind of build I wire into businesses at optimax-ai.com.