Grok CLI ist der terminalbasierte Coding-Agent von xAI, offiziell Grok Build genannt, der als AI Harness die Grok-Modelle mit Werkzeugen, Kontext, Rechten und Sub-Agenten zu einem arbeitsfähigen Agenten verbindet. Der Quellcode liegt unter der Apache-2.0-Lizenz im offiziellen Repository xai-org/grok-build vor; Grok Build wird als vollbildschirmfähige TUI, headless in Skripten oder in Editoren über das Agent Client Protocol (ACP) genutzt. Stand: 20. September 2026.
Was ist Grok CLI?
Die Bezeichnung „Grok CLI“ stammt aus der Agentenliste von herdr; der Anbieter selbst nennt das Produkt Grok Build, der Befehl lautet grok. xAI tritt in Dokumentation und Repository inzwischen unter dem Namen SpaceXAI auf und kündigte Grok Build am 25. Mai 2026 als frühe Betaversion an. Das Produkt ist nicht mit dem Community-Projekt grok-cli von superagent-ai zu verwechseln, das im eigenen README festhält, nicht mit xAI verbunden zu sein.
Installiert wird Grok Build unter macOS und Linux mit curl -fsSL https://x.ai/cli/install.sh | bash, unter Windows per PowerShell mit irm https://x.ai/cli/install.ps1 | iex; die Enterprise-Dokumentation nennt zusätzlich npm install -g @xai-official/grok. Danach startet grok eine interaktive Sitzung im Projektverzeichnis. Beim ersten Start öffnet sich ein Browser zur Anmeldung; in Umgebungen ohne Browser genügt die Umgebungsvariable XAI_API_KEY.
Grok CLI als AI Harness
Grok Build deckt die Bausteine eines Harness mit dokumentierten Mechanismen ab. Der Agent liest Projektregeln aus AGENTS.md-Dateien vom Repository-Stamm bis zum Arbeitsverzeichnis sowie aus .grok/rules/; zur Kompatibilität werden auch CLAUDE.md, .claude/rules/ und .cursor/rules/ gelesen. Werkzeuge kommen über MCP-Server hinzu, etwa mit grok mcp add oder als Abschnitt [mcp_servers.<name>] in ~/.grok/config.toml.
Rechte und Sandbox sind getrennt: Modi wie default (Ask), acceptEdits, auto, dontAsk und bypassPermissions (Always-approve) entscheiden zusammen mit Allow- und Deny-Regeln, ob ein Werkzeugaufruf läuft; die Sandbox (Landlock unter Linux, Seatbelt unter macOS) grenzt zusätzlich ein, was ein freigegebener Aufruf darf. Aktiviert wird sie etwa mit grok --sandbox workspace oder GROK_SANDBOX=workspace. Hooks liegen als JSON-Dateien unter ~/.grok/hooks/ oder .grok/hooks/; blockierend sind laut Dokumentation PreToolUse, UserPromptSubmit, Stop und SubagentStop, Projekt-Hooks müssen zunächst über /hooks-trust freigegeben werden.
Sub-Agenten laufen als Kindsitzungen mit eigenem Kontext (general-purpose, explore, plan). Skills sind Ordner mit einer SKILL.md; Plugins bündeln Skills, Agenten, Hooks sowie MCP- und LSP-Server. Sitzungen werden unter ~/.grok/sessions/ gespeichert; /rewind (Alias /undo) setzt den Gesprächsverlauf auf einen früheren Zug zurück, lässt laut Dokumentation bereits vorgenommene Dateiänderungen aber unangetastet. Für Automatisierung stehen grok -p "…" --output-format json und die ACP-Schnittstelle grok agent stdio bereit.
Modelle und Modellzugang
Standardmäßig arbeitet Grok Build mit den Grok-Modellen von xAI. Anfragen laufen entweder über die xAI-Kontositzung durch den Inferenz-Proxy oder mit einem API-Key direkt gegen die xAI-API.
Laut Dokumentation unterstützt Grok Build zusätzlich beliebige benutzerdefinierte Modelle. Dazu wird in ~/.grok/config.toml ein Abschnitt [model.<name>] mit model, base_url, name und env_key angelegt und unter [models] als default gesetzt; grok inspect zeigt die erkannte Konfiguration. Damit lässt sich Grok Build über einen zentralen, OpenAI-kompatiblen Proxy wie das AI Gateway von innFactory betreiben: Als base_url wird der Gateway-Endpunkt eingetragen, als env_key die Variable mit dem Gateway-Schlüssel. Die Enterprise-Dokumentation vermerkt, dass solche Drittanbieter-Endpunkte auch dann weiterlaufen, wenn die Anmeldung per xAI-API-Key deaktiviert ist.
Einsatz im Unternehmen: Datenschutz und Governance
xAI beschreibt den Datenfluss in sechs Phasen: Eingaben werden lokal zusammengestellt, per TLS 1.2/1.3 an den Inferenz-Proxy cli-chat-proxy.grok.com gesendet und von dort an das Modell weitergereicht; Werkzeuge laufen lokal. Zero Data Retention lässt sich auf Team-Ebene aktivieren, dann werden laut Dokumentation auf der Inferenzebene keine Prompts, kein Code und keine Antworten gespeichert. Eine EU-Datenresidenz ist für Grok Build nicht öffentlich dokumentiert.
Für die Steuerung gibt es fünf Konfigurationsebenen. Laut Dokumentation lassen sich Werte in /etc/grok/requirements.toml nicht überschreiben und per MDM verteilen – etwa ein fest vorgegebenes Sandbox-Profil, disable_api_key_auth für erzwungenes SSO, force_login_team_uuid oder disable_bypass_permissions_mode. Enterprise-OIDC bindet Identitätsanbieter wie Entra ID, Okta oder Auth0 an; die Proxy-Variablen HTTPS_PROXY und NO_PROXY werden beachtet. Unabhängig davon gehen Quellcode und Prompts an den gewählten Modellanbieter – das ist vorab im Verarbeitungsverzeichnis der Verarbeitungstätigkeiten abzubilden.
Grok CLI mit herdr orchestrieren
herdr führt Grok CLI in seiner Liste unterstützter Agenten mit der State Authority „Screen-Manifest“ und der Integrationsrolle „Session“. herdr erkennt damit aus der Terminal-Ausgabe, ob Grok Build arbeitet, wartet oder eine Freigabe verlangt, und liefert eine Sitzungsidentität zur Wiederherstellung. Das zugehörige Manifest grok trägt den Alias grok-build.
Einordnung: Entwickler-Harness und Unternehmens-Harness
Grok Build ist ein Harness für Entwickler: ein Repository, ein Terminal, ein Editor. Mitarbeitende in Fachabteilungen brauchen einen anderen Harness – mit Fachsystemen als Werkzeugen, Unternehmenswissen als Kontext und Rollen aus dem Verzeichnisdienst. Diese Rolle übernimmt CompanyGPT, als Ergänzung statt als Konkurrenz. Das AI Gateway dient beiden als gemeinsame Kosten- und Governance-Schicht mit Budgets pro Team, Nutzer und Agent. Weitere Coding-Agenten finden Sie in der Übersicht der AI Harnesses. Wir unterstützen Sie dabei, Coding-Agenten wie Grok Build datenschutzkonform einzuführen und in Ihre KI-Governance einzubinden.