On July 15, 2026, xAI open-sourced Grok Build — the Rust agent loop, terminal UI, and tool layer behind its coding CLI — as roughly 844,000 lines of code under Apache 2.0. That alone made it one of the more notable coding-agent releases of the month. What’s more useful to know if you already run Claude Code: Grok Build’s own documentation states it reads Claude Code’s configuration directly, in the same repo, with no conversion step.
That’s a meaningfully different approach than the migration path other tools take — Codex CLI’s /import command, for comparison, converts CLAUDE.md into AGENTS.md, reshapes subagents into TOML, and drops a couple of things along the way. Grok Build skips the conversion step entirely and reads your existing files as-is, alongside its own.
What Grok Build discovers automatically
Per xAI’s own documentation:
“Grok automatically reads Claude Code marketplaces, plugins, skills, MCPs, agents, hooks, and instruction files alongside
.grok/.”
Specifically, that covers Claude Code’s instruction files — CLAUDE.md, Claude.md, CLAUDE.local.md, and .claude/rules/ — plus marketplaces, plugins, skills, MCP servers, subagents, and hooks. None of it requires a .grok/ equivalent to already exist. Point Grok Build at a repo that only has Claude Code configuration in it, and it picks that up on its own.
You can verify exactly what it found with:
grok inspectwhich reports config sources, instructions, skills, plugins, hooks, and MCP servers discovered in the current directory — useful for confirming it’s actually reading what you expect before you trust it with anything.
Grok Build’s own config layer
Grok Build isn’t only reading Claude Code’s files — it layers its own configuration on top, in ~/.grok/config.toml for user-level settings and a project-level .grok/config.toml scoped to MCP servers, plugins, and permissions. A minimal example from the docs:
[models]
default = "grok-build"
web_search = "grok-4.5"
[model."grok-4.5"]
model = "grok-4.5"
base_url = "https://api.x.ai/v1"
env_key = "XAI_API_KEY"
api_backend = "responses" # chat_completions | responses | messages
temperature = 0.7
context_window = 1000000
[mcp_servers.filesystem]
command = "npx"
enabled = trueGrok Build also supports its own AGENTS.md for project instructions — loaded automatically the same way Claude Code loads CLAUDE.md — and its own Skills convention: folders under .grok/skills/ (walked up to the repo root) or ~/.grok/skills/, each a SKILL.md stating trigger conditions, allowed tools, inputs/outputs, and safety boundaries. User-invocable skills show up as /<skill-name> slash commands, mirroring how Claude Code skills work.
So a repo that already has both a CLAUDE.md and a .grok/config.toml isn’t a conflict from Grok Build’s perspective — it reads both, plus whatever’s in .claude/ and .grok/ side by side.
What isn’t documented: precedence when both disagree
Here’s the honest gap. xAI’s docs describe Claude Code config and .grok/ config as coexisting — “alongside” is the word they use — but don’t specify a precedence order for what happens when the two disagree. If your CLAUDE.md says one thing about, say, when to run tests, and a .grok/-specific instruction says another, which one wins isn’t documented anywhere we could find as of this writing. If you’re running Grok Build in a repo with substantive Claude Code instructions, that’s worth testing directly with grok inspect and a real prompt rather than assuming.
The same applies to MCP servers and hooks discovered from both sources: nothing in the docs states what happens if a Claude Code hook and a Grok-native hook would fire on the same event. Treat overlapping configuration as unverified territory until you’ve checked it yourself in your actual repo.
The security angle worth thinking through
Reading someone else’s agent’s config isn’t just a convenience feature — it means a brand-new, freshly open-sourced tool with full file and shell access is executing instructions from skills and hooks you wrote for a different agent, under a different trust model. That’s not a reason to avoid Grok Build, but it is a reason to treat it like you would any new agent gaining execution access to your repo: read through .grok/config.toml’s permission settings before pointing it at anything sensitive, and don’t assume Claude Code’s permission boundaries (allow/deny/ask rules) translate their intent automatically just because the underlying CLAUDE.md got read.
Practical takeaway
If you want to try Grok Build against a codebase that already has real Claude Code investment in it — a written CLAUDE.md, a handful of skills, an MCP server or two — you can, without touching any of it. That’s the meaningful difference from a migration tool: there’s nothing to convert, nothing to verify transferred correctly, and nothing that’s a one-way door. Add a .grok/config.toml for the model provider and any Grok-specific permissions, run grok inspect to confirm what it picked up, and you’re evaluating the actual agent rather than a migrated approximation of your setup.
One Config Key, Two Agents, Zero Extra Secrets Files
Both Claude Code’s MCP servers and Grok Build’s config.toml reference API keys through environment variables (env_key in Grok’s case). Rather than keeping separate .env files per agent, 1Password CLI’s op run can inject the same managed secret into both tools’ environments at runtime — one source of truth for the API keys both your Claude Code and Grok Build setups need, with an access log for every read.
FAQ
Q: Do I need to convert my CLAUDE.md to use Grok Build?
No. Grok Build reads CLAUDE.md, Claude.md, CLAUDE.local.md, and .claude/rules/ directly, alongside its own .grok/ configuration. There’s no conversion step, unlike Codex CLI’s /import.
Q: Does Grok Build also read Claude Code’s MCP servers and hooks?
Yes, per xAI’s documentation — it discovers marketplaces, plugins, skills, MCP servers, subagents, and hooks from Claude Code installations automatically, in addition to its own .grok/ sources.
Q: What happens if my CLAUDE.md and a Grok-specific instruction file conflict?
This isn’t documented. xAI’s docs describe the two config sources as coexisting but don’t specify a precedence order. Test this directly in your own repo with grok inspect before relying on it.
Q: What’s Grok Build’s own project instruction file called?
AGENTS.md, loaded the same way Claude Code loads CLAUDE.md. A repo can have both simultaneously.
Q: How do I check what Grok Build actually discovered in my repo?
Run grok inspect. It reports config sources, instructions, skills, plugins, hooks, and MCP servers found in the current directory.
Q: Is Grok Build free and open source? The agent loop, tool layer, terminal UI, and extension system are published on GitHub under Apache 2.0. About 3% of the codebase is vendored from other sources; the rest is xAI’s own.