Grok Build

Overview

Grok Build now names two related products: a coding agent that works in a repository, and a web/mobile builder that turns a conversation into an app. The CLI has a fullscreen terminal interface, headless automation, and Agent Client Protocol (ACP) integration. The in-chat builder produces previews and publishable projects without a local installation.^[1][2]

As checked September 16, 2026, Grok 4.6 is the default coding model, replacing this profile's earlier focus on grok-build-0.1. It accepts text and images, has a 500,000-token context window, and supports adjustable reasoning effort. The CLI can also use custom model endpoints.^[3][1] This places the terminal product in AI coding assistants, while the in-chat builder serves a different starting point: describing an application before choosing a repository workflow.

The useful evaluation is therefore broader than “another terminal agent.” Check the desired surface, model billing, extension compatibility, and execution controls independently. The examples below illustrate documented workflows; this review did not run the agent or reproduce its security reports.

Two surfaces, different workflows

The official CLI launch page is dated May 25, 2026 and describes early-beta access for SuperGrok and X Premium Plus subscribers.^[7] The in-chat builder followed in a July 28 Heavy-only beta.^[2] On August 19, SpaceXAI expanded the web/mobile builder to every plan. That announcement is specifically about building inside chat; it should not be read as a promise of free, unlimited CLI inference.^[6]

In the web/mobile workflow, users can publish to grok.me or a custom domain, choose private, link-accessible, or public visibility, and export the project to GitHub. Per-app SpaceXAI API access adds chat, images, or voice without manually pasting API keys; access can be revoked. The announcement also describes connectors and keeping secrets outside application code.^[6]

For a prototype, the key decision is whether chat-to-preview-to-publication is enough. For a maintained product, evaluate the exported project, deployment needs, authentication, and operating costs. GitHub export is useful portability; it does not establish a hosted pull-request agent, unlimited hosting, or a production service-level guarantee.

The CLI workflow

Install, authenticate, inspect

Official binaries support macOS, Linux, and Windows. Source builds require Rust, DotSlash, and protoc; the repository calls Windows source builds best-effort and untested in that tree.^[4] The docs provide shell and PowerShell installers. First launch opens browser authentication, while an API key can be used in a non-browser environment. Start in the project directory and run grok inspect to check the configuration and extensions discovered there.^[1]

That inspection matters when an existing repository brings its own instructions, plugins, or tool connections. Before asking for a migration, establish which model, permission rules, and repository guidance the session will actually use.

Plan and review

/plan starts planning on the next prompt; /plan <description> starts immediately. The preview supports approval, change requests, and comments on selected lines. Even auto and always-approve modes retain this plan review.^[8]

The important qualification is that plan mode gates edit tools, not every possible write. Shell commands still follow permission rules and can write through redirection. Child agents inherit permission mode, but the parent's plan-mode edit restriction does not apply to them.^[8]

For example, an authentication migration can start with a plan describing compatibility, data migration, tests, and rollback. Review those decisions before implementation, then inspect the resulting diff and test results. The plan is a coordination step; it is not a substitute for configuring the execution boundary.

Delegate and separate working copies

Subagents have their own context and return a summary. Built-in explore and plan types lack shell and edit tools; general-purpose is the full-capability child. Custom types can live in project or user agent directories.^[9]

Worktrees are optional. grok -w starts from the current HEAD including uncommitted changes; grok -w --ref main uses a clean checkout of that ref. Child agents can request their own worktrees. These checkouts prevent agents from editing the same working files, but changes still need ordinary Git integration and conflict review.^[10]

A useful split is one child tracing a failing test and another investigating the implementation, with separate worktrees for competing fixes. Do not confuse that file separation with OS-level isolation. Worktrees persist after sessions end; the documented list, remove, and garbage-collection commands make cleanup an explicit operating responsibility.^[10]

Automate with headless mode or ACP

Headless grok -p supports plain text, a final JSON object, or newline-delimited streaming-json events. Sessions can be named, resumed, or continued, and --no-auto-update disables update checks for automation. ACP uses grok agent stdio; it exposes the agent over JSON-RPC rather than requiring a terminal UI.^[11]

For a scripted review, choose a clean checkout and a narrowly permitted task. The following illustrative invocation requests analysis without granting every tool call:

grok --no-auto-update -p "Review the API changes and report risks" \
  --permission-mode dontAsk \
  --allow 'Read' \
  --allow 'Grep' \
  --output-format json \
  --sandbox strict

dontAsk denies calls without an explicit allow rule. API-key and device-code authentication are documented for automation and remote hosts.^[12] Treat an agent's output as review input: the surrounding CI job still needs explicit success criteria, tests, and a publishing policy.

Permissions and sandbox limits

The default Ask mode prompts for calls that lack permission. Auto uses a classifier when enabled; always-approve accepts calls while retaining deny rules and blocking hooks. Explicit allow rules can authorize dangerous commands that a remembered interactive grant would still prompt about. Deny rules take precedence.^[13]

The OS sandbox is separate and off by default. Its documented enforcement uses Landlock on Linux and Seatbelt on macOS.^[14]

These profile rules come from the sandbox guide. Network blocking is a no-op on macOS for read-only and strict; in-process model API and web tools are outside that child-process restriction. Built-in profiles also do not supply permanent secret-directory denies. Custom policies can add them.^[14]

For managed installations, root-owned /etc/grok/requirements.toml can pin policy, including a sandbox profile and disabling permission bypass. The docs explicitly say Claude Code's disableBypassPermissionsMode setting is not inherited as Grok's bypass lock; Grok needs its own setting.^[12] Importing configuration is therefore not proof that another agent's security policy transfers unchanged.

Extensions and Claude Code interoperability

Skills bundle instructions and resources. Plugins can add skills, agents, hooks, MCP servers, and LSP servers. Grok discovers its own configuration and reads Claude Code instruction files and extension locations, plus user-level ~/.agents/skills/.^[15]

The compatibility claim has concrete limits: skill allowed-tools does not enforce tool permissions, and accepted model, effort, license, and compatibility fields are not applied. Review the consuming harness's behavior before treating a shared skill as an identical execution contract.^[15]

Hooks support shell commands and HTTP endpoints. Project hooks require trust. Only PreToolUse can block a tool; a timeout, crash, or malformed result fails open, while an explicit denial blocks. This makes hooks useful automation, but a failed hook is not automatically an enforcement barrier.^[16]

Calling Grok from Claude Code

SpaceXAI also publishes grok-build-plugin-cc, a Claude Code plugin that invokes the real Grok CLI for reviews, critiques, and delegated work. It requires an installed, authenticated Grok binary and Node.js. The plugin manages its own background runs, status, logs, and cancellation; it is not a second hosted Grok service.^[17]

Its current implementation is more informative than the README's example commands: review and critique request the explore agent with auto-approval and a read-only sandbox. Delegated runs also auto-approve; --write removes the bridge's explicit read-only sandbox argument. The installed CLI and managed policy still determine enforcement.^[18]

A relevant first-hand caution is kai-wedekind's August 7 Windows report, still open when checked. The author reported outside-directory reads and writes using the bridge's argument pattern with Grok CLI 1.0.0 and 0.2.118. This review did not reproduce that version-specific report; it reinforces why a plugin's “read-only” label should not be assumed to work identically on every host.^[19]

Models, access, and pricing

The default Grok 4.6 model and the CLI are separate choices. The configuration guide supports named custom models with a model ID, base URL, and credential environment variable; the July source release also describes running against local inference.^[1][20] The older grok-build-0.1 remains listed in the API price catalog; being superseded as the default does not mean that model has been retired.^[21]

Prices below were checked September 16, 2026 and are in US dollars.

Do not convert an API token price into a subscription allowance. The public plan cards do not provide a stable task count, and this review did not verify an account's live CLI quota. Heavy and other tiers appear in the comparison matrix without a dollar figure on those public cards. The August web/mobile availability expansion also does not make every plan's limits identical.^[22]

For budgeting, measure a representative task through completion: repeated context, output, tool use, and parallel children matter more than the price of one prompt. No current independent end-to-end cost or quality benchmark was established in this review, so the old “cheapest model” and “15× entry price” rankings have been removed.

Open source and the July privacy incident

SpaceXAI published the CLI source on July 15, 2026, including the agent loop, tools, terminal UI, and extensions.^[20] The Apache 2.0 client is open source; its public repository is periodically synchronized from an internal monorepo. SOURCE_REV identifies the corresponding internal revision, while external pull requests and unsolicited patches are not accepted.^[4][23]

Licensing and contribution governance are separate: teams can inspect or modify the client while upstream development remains centralized. The tool notices also document modified ports from Codex and OpenCode. Those notices establish provenance; they do not by themselves establish comparative agent quality.^[24]

The incident preceding publication remains important:

• July 13 report: CEREBLAB captured Grok Build 0.2.93 sending a Git bundle containing repository files and history despite a prompt that asked it not to open files. The researcher reconstructed the bundle and found that switching off “Improve the model” did not stop it.^[25]
• Observed change: The report says a server-side disable_codebase_upload flag stopped the upload on July 13, with subsequent retests through 0.2.106 on July 22. It distinguishes that change from the /privacy retention preference, which did not prevent ordinary model requests and traces from leaving the machine.^[25]
• Company response: Simon Willison's July 15 source inspection records SpaceXAI's statement that default retention had been disabled starting July 12 and retained coding data was being deleted. He also identified disabled upload code in that initial public release. These are dated observations and an attributed company commitment, not independent proof of server-side deletion.^[26]

Current enterprise documentation describes prompts and file content traveling to inference, team-level zero-data-retention handling, and local session history under ~/.grok/.^[12] Retention and transmission remain different questions. The practical evaluation is to check the deployed version, authentication path, endpoint, retention agreement, and network behavior. Open source makes inspection possible; it does not replace that inspection or certify every distributed binary.

Where Tembo complements Grok Build

Disclosure: I am Tembo's CEO and co-founder.

Tembo addresses operating coding agents across a team: cloud environments, shared session visibility, connected repository and work-tracking context, and reviewable output. Its current website explicitly lists Grok Build among the available agent choices.^[27] That is a complementary role to the local CLI, rather than a claim that Tembo replaces Grok's model, skill loader, or terminal interface.

Tembo's agent documentation describes scheduled and event-triggered work, including GitHub events, Linear changes, Slack mentions, and webhooks. Agents run with repository access and configured MCP connections.^[28] A team evaluating a recurring repository-maintenance workflow should therefore compare running Grok headlessly in its own CI with using a platform for triggers, execution, and review.

There is a documentation boundary: the detailed Tembo harness list checked for this report does not enumerate Grok Build, even though the product site does. That leaves Grok-specific authentication, model selection, and feature parity to verify before deployment.^[27][28] The platform relationship is relevant; it is not evidence that every local Grok configuration works unchanged in a hosted session.

Who should evaluate it

The CLI fits developers who want a configurable coding harness, terminal and automation workflows, parallel investigation, or an inspectable implementation. The web/mobile builder fits users who want a short path from an idea to an interactive preview and a published project. These are different evaluations, even when both use the Grok Build name.

For team adoption, prioritize an ordinary maintenance task over a polished demo. Measure whether the agent understands repository conventions, produces a correct patch, passes the project's actual checks, and remains within the selected permissions. Then repeat with the model, host OS, and extensions the team intends to deploy.

The evidence supports a broader, more configurable product than the early CLI profile described. The remaining diligence is concrete: subscription quotas, platform-specific enforcement, bridge behavior, and the difference between a documented privacy policy and independently observed data handling.

---

Research by Ry Walker