Grok Build vs Claude Code: What Each Can Actually See

Grok Build vs Claude Code is now a genuine apples-to-apples comparison: two terminal-first coding harnesses that run against your own repository, take permission-gated tool actions, and ship enterprise lockdown mechanisms. What most head-to-head takes get wrong is the security framing — because on the axis everyone leads with, the two tools are identical, and their own documentation says so.

Both ship their bash sandbox off by default. xAI’s sandbox page states it plainly, and Anthropic’s settings reference lists sandbox.enabled with a default of false. The popular framing — Grok Build wide open, Claude Code locked down — does not survive a direct read of either vendor’s docs. Neither harness protects you until you configure it.

So this comparison drops the default-posture axis and works the differences that are actually checkable: what each sandbox restricts once you turn it on, an interop layer that runs in exactly one direction, licensing, model freedom, and what each vendor is willing to publish about data use. Every cell in every table below traces to a vendor page we fetched directly.

xAI’s own overview describes Grok Build as “a powerful and extensible coding agent” you can use “via an interactive TUI, headlessly in scripts or bots, or through the Agent Client Protocol (ACP) in other apps.” That is a functional description of Claude Code’s territory: an agent in your terminal, operating on your working tree, with hooks, skills, MCP servers and enterprise policy. Grok Build reached 1.0.0 on August 7, 2026, installs with a one-line script on macOS and Linux (PowerShell on Windows), ships as the grok binary, and authenticates through the browser on first launch with an XAI_API_KEY environment-variable fallback.

We compared harnesses in this class before — see our last three-way harness matrix and Grok Build’s original launch coverage. What has changed since is that the two tools now share a config surface: Grok Build reads Claude Code’s settings and sessions directly, which settles the “are they really substitutes” question in the most concrete way possible. More on that in section 04.

Start with the claim that anchors most comparisons of these two tools: that Claude Code is the sandboxed, safe one and Grok Build is the wide-open one. The first half is false as a statement about defaults, and Anthropic’s own settings reference is the source. The sandbox.enabled setting — “Enable bash sandboxing (macOS, Linux, and WSL2)” — carries an explicit Default: false. Until you turn it on, Bash commands run with no sandbox-imposed restriction at all.

Grok Build’s posture is the same, and xAI is equally direct about it: “The sandbox is off by default, allowing unrestricted filesystem access and network connectivity without restrictions.” Two vendors, two sentences, one identical default. Whatever protection either harness offers is opt-in, on both sides.

This matters beyond pedantry. A team can choose a harness — or wave one through security review — on the strength of a sandbox that was never actually on. The honest comparison is not “which tool is sandboxed” but “what does each sandbox restrict once you enable it, and what does the vendor admit it cannot do.” That comparison is next, and it cuts in a less flattering, more useful direction than the myth.

Enabled, the two sandboxes take different shapes. Grok Build offers five graded profiles — off, workspace, devbox, read-only and strict — with ~/.grok/ deliberately kept writable under sandboxed profiles so sessions persist. Claude Code offers a single sandbox with configurable read, write and network rules: writes confined to the working directory plus the session temp directory, and a default-deny network where no domains are pre-allowed and the first use of a new domain prompts for approval.

Both vendors also document what their sandbox does not do — and the admissions rhyme. xAI: built-ins “do not permanently protect paths such as” ~/.ssh; use a custom deny list. Anthropic: the default read policy grants “read access to the entire computer, except certain denied directories,” and “this default still allows reading credential files such as ~/.aws/credentials and ~/.ssh/” unless you set sandbox.credentials or add the paths to denyRead. The credential gap the conventional wisdom treats as a Grok-only weakness is documented on both sides.

Sources for every cell: xAI’s Grok Build sandbox and enterprise documentation, and Anthropic’s Claude Code sandboxing and settings references — all read directly at the time of writing. Neither column relies on third-party coverage.

Two Claude Code specifics are worth pulling out. First, subagents “run in the same process as the parent session and use the same sandbox configuration” — so an enabled sandbox covers delegated work too. By default a subagent can spawn subagents “up to three layers below the main conversation,” configurable via CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH; a five-layer, unconfigurable default applied only to versions v2.1.172 through v2.1.216 and has been superseded. Second, the fail-open default deserves attention in threat models: on a Linux box missing bubblewrap, the sandbox you believe is on quietly isn’t, unless you also pinned failIfUnavailable. For how a third harness handles the same sandbox-and-approval tradeoffs, see our Muse Code comparison.

The strongest evidence that these tools are direct substitutes is not a benchmark — it’s that one of them was engineered to slot into the other’s fleet. xAI documents that Grok Build reads a subset of Claude Code’s managed-settings.json: permission rules, MCP server allowlists, a few telemetry and feedback settings, and marketplace restrictions. Its docs go further: “Grok is fully compatible with Claude Code with zero configuration needed,” automatically reading Claude Code marketplaces, plugins, skills, MCPs, agents, hooks and instruction files — CLAUDE.md, CLAUDE.local.md, .claude/rules/ — alongside its own .grok/ directory.

The changelog shows the same intent shipping feature by feature: v0.2.100 (July 12, 2026) added a session picker that resumes recent Claude Code, Codex and Cursor sessions, and disables a source tool’s hooks at Grok session start when they are disabled in that tool’s config; v0.2.101 (July 13, 2026) added grok inspect, which shows the effective compatibility settings for Cursor, Claude and Codex sessions.

“Not documented” here means exactly that: no equivalent capability appears on Claude Code’s sandboxing, sub-agents, data-usage or settings pages, all checked directly at the time of writing — nothing in them mentions Grok Build, Codex or Cursor session or config compatibility. The asymmetry is the point: one harness was built to inherit the other’s fleet with zero switching cost; the reverse path does not exist.

There is a second, quieter piece of evidence in Grok Build’s own repository. Its THIRD-PARTY-NOTICES file discloses in-tree ports of tool implementations from openai/codex and sst/opencode, adapted into Grok Build’s Rust codebase under Apache change-notice terms. That is the license-compliant, fully-disclosed way to build on rival open-source work — not a gotcha — but it does confirm how deliberately Grok Build was assembled to occupy the same niche as the incumbents it borrows from.

The sandbox comparison needs hedging; this one does not. Grok Build is genuinely open source: the xai-org/grok-build repository — opened mid-July 2026 and synced periodically from the SpaceXAI monorepo — carries a standard Apache License 2.0, is almost entirely Rust, and had drawn more than 24,000 GitHub stars at the time of writing. Any developer can read the code their agent executes. The story of how that repository came to be public is its own post — the 72-hour open-sourcing sequence — and we won’t retell it here.

Claude Code also has a public GitHub repository, which is where the confusion starts. Its LICENSE.md reads “© Anthropic PBC. All rights reserved,” with use subject to Anthropic’s Commercial Terms of Service, and GitHub’s API reports no recognized open-source license for the repo. The repository is real and useful — issue tracker, changelog, example plugins, docs configuration — but the CLI’s core is proprietary. Public is not the same as open.

Why this axis matters practically: if your security review process requires auditing the tool that holds shell access to your repositories, only one of these two harnesses permits it. If your review instead leans on vendor attestations, contractual terms and published policy, the next two sections are where Claude Code makes its counter-argument.

Grok Build defaults to grok-4.6 and switches models with /model — but the config schema is the real story. [model.<id>] blocks in ~/.grok/config.toml accept a base_url, an api_backend and an env_key, which means arbitrary custom endpoints — including local inference. xAI’s own documented use case is pointing base_url at a local Ollama server, so that “the agent will run without touching xAI’s infrastructure” at all. The supported backends are OpenAI Chat Completions, OpenAI Responses — and Anthropic’s Messages protocol, meaning Grok Build’s config schema natively speaks the API dialect of the rival it interoperates with. We’ll note the irony and leave it there; nothing suggests xAI endorses or tests that pairing.

Claude Code runs Anthropic models only. Its aliases — opus, sonnet, haiku, fable, plus long-context variants — resolve to Anthropic models across every documented hosting route (the Anthropic API, Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, Claude Platform on AWS). No third-party or local-model endpoint is documented. Which model you get by default is account-type-dependent: the special value default “reverts to the recommended model for your account type,” or to an organization default when an admin sets one. One specific worth knowing: Fable 5 is never the default on any tier — you select it explicitly with /model fable, and depending on plan it can bill against separate usage credits, with a consent prompt in interactive sessions.

The trade is clean. Grok Build treats the model as a swappable component — useful for sovereignty requirements, offline work, or routing different repos to different providers. Claude Code treats the model roster as part of the product — one vendor’s models, multiple certified hosting routes, and a single accountable data policy across them, which is exactly what the next section is about.

Anthropic maintains a dedicated data-usage page for Claude Code with explicit per-tier terms. Consumer accounts (Free, Pro, Max) choose whether their data may be used to improve future models — with retention of five years if they opt in and 30 days if they do not. Commercial tiers (Team, Enterprise, API and third-party platforms) get a stronger default: no training on code or prompts under commercial terms, unless an organization admin opts in to the Developer Partner Program, which is only available on Anthropic’s first-party API. Zero data retention exists for Claude for Enterprise but is not part of the standard Enterprise plan — it is enabled per organization after an eligibility check.

Two practical details from the same page: local session transcripts sit in plaintext under ~/.claude/projects/ for 30 days by default (tunable via cleanupPeriodDays), independent of server-side retention; and sending /feedback, /bug or /share uploads a copy of your conversation history including code, which is retained for up to five years — opt out with DISABLE_FEEDBACK_COMMAND=1 if that is unacceptable in your environment.

Grok Build’s public documentation is thinner on this axis. It documents zero data retention at the team level, keeps local history under ~/.grok/, and routes inference through a proxy at cli-chat-proxy.grok.com — but the Build docs pages we checked (overview, sandbox, permissions, enterprise) do not state consumer-tier training or retention terms for code at all. That documentation-depth asymmetry is itself a finding: one vendor publishes a per-tier policy you can cite in a review; the other currently asks individual users to proceed without one.

Pricing transparency follows the same pattern. Anthropic’s pricing page puts numbers on every tier that includes Claude Code — Free at $0, Pro at $17 per month billed annually ($20 monthly), Max from $100 per month, Team Standard seats at $20-25, Enterprise at $20/seat with usage-scaled costs — while stating “Usage limits apply” without numeric limits. Grok Build itself has no published price and no published usage allowance on the pages we checked; it rides on xAI’s metered API and subscription tiers. You can budget a Claude Code seat from public information; a Grok Build seat you estimate from your own metering.

One axis remains: trust posture. Grok Build’s short history includes a serious privacy incident — a covert whole-repository upload through a separate storage channel, disclosed by outside analysis in mid-July 2026 and fixed server-side, with xAI never acknowledging it in its own channels. We covered what actually fixed it in detail, and the open-sourcing that followed in the companion post linked above — read both before extending production trust. As sections 02 and 03 showed, Claude Code’s protections are opt-in too, and its fail-open sandbox default rewards teams that verify rather than assume. Trust, for both tools, is something you configure.

Whichever harness wins your review, remember that harness choice is the smaller half of agent reliability. The discipline that actually moves outcomes is giving the agent a definition of done and a check it can run — the subject of our companion piece on acceptance-criteria prompts, published alongside this one. And if you are standing up agentic development across a team — harness selection, sandbox policy, data-terms review, mixed-fleet lockdown — that is precisely the kind of engagement our AI transformation service runs end to end.