Grok CLI is xAI’s terminal-based coding agent, officially called Grok Build, which acts as an AI harness connecting the Grok models with tools, context, permissions and subagents to form a working agent. The source code is available under the Apache-2.0 licence in the official xai-org/grok-build repository; Grok Build is used as a fullscreen TUI, headlessly in scripts or in editors via the Agent Client Protocol (ACP). As of 20 September 2026.
What is Grok CLI?
The name “Grok CLI” comes from herdr’s list of agents; the vendor calls the product Grok Build, started with the grok command. xAI now appears as SpaceXAI in its documentation and repository, and announced Grok Build as an early beta on 25 May 2026. It should not be confused with the community project grok-cli by superagent-ai, whose own README states it is not affiliated with xAI.
Grok Build installs on macOS and Linux with curl -fsSL https://x.ai/cli/install.sh | bash and on Windows via irm https://x.ai/cli/install.ps1 | iex; the enterprise documentation also names npm install -g @xai-official/grok. Running grok then starts an interactive session in the project directory; a browser opens for sign-in on first launch, or the XAI_API_KEY environment variable suffices without one.
Grok CLI as an AI harness
Grok Build covers the building blocks of a harness with documented mechanisms. The agent reads project rules from AGENTS.md files from the repository root down to the working directory and from .grok/rules/; for compatibility, CLAUDE.md, .claude/rules/ and .cursor/rules/ are read as well. Tools are added through MCP servers, for example with grok mcp add or as an [mcp_servers.<name>] section in ~/.grok/config.toml.
Permissions and sandbox are separate: modes such as default (ask), acceptEdits, auto, dontAsk and bypassPermissions (always-approve) plus allow/deny rules decide whether a tool call runs; the sandbox (Landlock on Linux, Seatbelt on macOS) additionally limits what an approved call may do, enabled with grok --sandbox workspace or GROK_SANDBOX=workspace. Hooks are JSON files under ~/.grok/hooks/ or .grok/hooks/; PreToolUse, UserPromptSubmit, Stop and SubagentStop can block, and project hooks first need trust via /hooks-trust.
Subagents run as child sessions with their own context (general-purpose, explore, plan). Skills are folders with a SKILL.md; plugins bundle skills, agents, hooks and MCP/LSP servers. Sessions live under ~/.grok/sessions/; /rewind (alias /undo) rolls the conversation back a turn but leaves file changes untouched. For automation there is grok -p "…" --output-format json and the ACP interface grok agent stdio.
Models and model access
By default Grok Build works with the Grok models from xAI; our page on xAI Grok puts the model family into context. Requests run either with the xAI account session through the inference proxy or with an API key directly against the xAI API.
According to the documentation, Grok Build also supports any custom model. To do so, a [model.<name>] section with model, base_url, name and env_key is added to ~/.grok/config.toml and set as default under [models]; grok inspect shows the discovered configuration. This means Grok Build can be operated through a central, OpenAI-compatible proxy such as the AI Gateway: enter the gateway endpoint as base_url and the variable holding the gateway key as env_key. The enterprise documentation notes that such third-party endpoints keep working even when sign-in with an xAI API key is disabled.
Enterprise use: data protection and governance
xAI describes the data flow in six steps: input is assembled locally, sent over TLS 1.2/1.3 to the inference proxy cli-chat-proxy.grok.com, forwarded from there to the model, processed, streamed back over the same encrypted connection, and – unless the team has enabled Zero Data Retention – stored; tools run locally throughout. Zero Data Retention can be enabled at team level, meaning, according to the documentation, no prompts, code or responses are persisted at the inference layer. EU data residency is not publicly documented for Grok Build.
Five configuration layers govern control. Values in /etc/grok/requirements.toml cannot be overridden and can be distributed via MDM – for example a fixed sandbox profile, disable_api_key_auth for enforced SSO, or force_login_team_uuid. Enterprise OIDC connects identity providers such as Entra ID, Okta or Auth0, and the standard HTTPS_PROXY/NO_PROXY variables are honoured. Regardless, source code and prompts go to the chosen model provider and belong in your records of processing activities beforehand.
Orchestrating Grok CLI with herdr
herdr lists Grok CLI with the state authority “screen manifest” and the integration role “session”, recognising from the terminal output whether Grok Build is working, waiting or asking for approval, and providing a session identity for restore. Its manifest grok carries the alias grok-build.
Where it fits: developer harness and enterprise harness
Grok Build is a harness for developers: a repository, a terminal, an editor. Employees in business departments need a different harness – business systems as tools, company knowledge as context, roles from the directory service. That role is taken by CompanyGPT, a complement rather than a competitor. The AI Gateway serves both as a shared cost and governance layer with budgets per team, user and agent; see the overview of AI harnesses for further coding agents. We support organisations in introducing coding agents such as Grok Build in line with data protection requirements and their AI governance.