Repo del giorno: Grok Build, il coding agent di xAI ora open source

🔍 Cos'è Grok Build

Grok Build è il coding agent da terminale di xAI: una TUI fullscreen, interattiva anche col mouse, che legge il codebase, modifica i file con revisione dei diff, esegue comandi shell, cerca sul web e gestisce task lunghi. Lanciato in beta a maggio 2026 e pensato per chi lavora su codebase grandi, funziona in tre modalità: interattiva nel terminale, headless per script e pipeline CI, e dentro gli editor tramite l'Agent Client Protocol (ACP), lo stesso meccanismo con cui altri agenti si integrano negli IDE.

Il repository pubblicato contiene il sorgente Rust (99,6% del codice) della CLI/TUI e del runtime dell'agente. Il codice di prima parte è sotto Apache 2.0; le parti di terzi restano sotto le licenze originali. Un dettaglio che dice molto sullo stato dell'ecosistema: fra le notice di terze parti ci sono port in-tree delle implementazioni dei tool di openai/codex e di sst/opencode — gli harness open source si stanno letteralmente scambiando i pezzi.

repo       xai-org/grok-build
cosa       coding agent da terminale (harness + TUI) di xAI, ora open source
come       Rust 99,6% · binario `grok` · TUI, headless o editor via ACP
estensioni skill, plugin, hook, server MCP, subagent
extra      local-first: compilalo tu e punta alla tua inference da config.toml
licenza    Apache 2.0 (prima parte) · ~19.600 stelle · sync dal monorepo

⚙️ Come si prova: binario o compilazione dal sorgente

La via rapida è il binario precompilato, pubblicato per macOS, Linux e Windows: uno script di installazione e il comando grok è pronto; al primo avvio apre il browser per l'autenticazione. È il percorso per chi vuole usare l'agente, non studiarlo.

La via interessante per chi legge questo articolo è la seconda: compilare dal sorgente con Cargo. Servono la toolchain Rust (bloccata da rust-toolchain.toml, la installa rustup alla prima build), DotSlash per scaricare gli strumenti ermetici in bin/ (in particolare protoc per la generazione del codice dai proto) e poco altro. Il binario prodotto si chiama xai-grok-pager; le installazioni ufficiali lo distribuiscono come grok. macOS e Linux sono i sistemi di build supportati, Windows è best-effort.

# Via rapida: binario ufficiale (macOS / Linux / Git Bash)
curl -fsSL https://x.ai/cli/install.sh | bash
grok --version

# Via studio: compilazione dal sorgente
cargo install dotslash          # prerequisito per bin/protoc
git clone https://github.com/xai-org/grok-build && cd grok-build
cargo run -p xai-grok-pager-bin              # build + avvio della TUI
cargo build -p xai-grok-pager-bin --release  # binario di release

🧩 L'anatomia dell'harness: i crate che contano

La parte che rende il repository una lettura preziosa è la separazione dei crate, perché rispecchia l'architettura tipica di un coding agent moderno. xai-grok-pager è la TUI — scrollback, prompt, modali, rendering. xai-grok-shell è il runtime dell'agente, con gli entry point leader, stdio e headless. xai-grok-tools implementa i tool veri e propri: terminale, modifica dei file, ricerca. xai-grok-workspace gestisce filesystem, version control, esecuzione e checkpoint. Attorno, i crate di contorno: configurazione, MCP, markdown, sandbox.

È esattamente la mappa che serve a chi vuole capire come funziona un agente: l'annuncio di xAI dichiara che il sorgente pubblicato copre il loop dell'agente (come si assembla il contesto, come si interpretano le risposte del modello, come si smistano le tool call), i tool, la UI del terminale con il diff viewer inline, e il sistema di estensioni. Se lavori con skill, plugin, hook o server MCP su un qualunque agente, qui vedi nero su bianco come vengono caricati e invocati.

🏠 Local-first: il tuo binario, la tua inference

Il punto più concreto dell'apertura del sorgente è che Grok Build ora può girare completamente local-first: lo compili tu, lo punti alla tua inference — anche un modello servito in locale — e governi tutto dal config.toml. Per chi ha vincoli di riservatezza sul codice, è la differenza fra «mi fido della pipeline del vendor» e «so esattamente che cosa esce dalla mia macchina, perché posso leggerlo nel sorgente».

La documentazione utente, inclusa nel repository e pubblicata su docs.x.ai, copre il resto della superficie: scorciatoie da tastiera, slash command, configurazione, theming, server MCP, skill, plugin, hook, modalità headless e sandboxing. Sono gli stessi concetti che chi usa Claude Code o Codex CLI già conosce — cambiano i nomi dei file, non le idee.

🏢 Perché è interessante, per sviluppatori e PMI

Per chi sviluppa, il valore non è (solo) un altro agente da provare: è un testo di riferimento. Le domande che ci facciamo configurando un agente — perché la skill non viene caricata? come vengono passati i risultati dei tool al modello? cosa entra davvero nel contesto? — qui hanno una risposta leggibile nel sorgente, in un linguaggio, Rust, che rende espliciti confini e responsabilità dei moduli. Anche solo confrontare come Grok Build, Codex e opencode implementano lo stesso tool di modifica file è una lezione di progettazione; i port in-tree dimostrano che le implementazioni sono ormai un patrimonio condiviso fra harness.

Per una PMI che sta introducendo agenti nei processi di sviluppo, il segnale è la maturazione dell'infrastruttura: i coding agent stanno convergendo su primitive comuni — skill, plugin, hook, MCP, subagent, sandboxing — e diventano componenti ispezionabili, non servizi opachi. La possibilità di compilare l'harness e tenere l'inference in casa apre scenari per chi ha requisiti stretti su dove passa il codice sorgente. Resta una valutazione da fare caso per caso: l'uso di default resta legato ai modelli e all'account xAI, e la governance va ragionata come per qualunque agente.

⚠️ Limiti e cautele prima di adottarlo

Qualche onestà. Il primo limite è di natura: è codice aperto, non un progetto di comunità. Le contribuzioni esterne non sono accettate, il repository è un mirror sincronizzato periodicamente dal monorepo interno (la storia pubblica parte con una manciata di commit e un file SOURCE_REV che registra lo SHA di origine), e il Cargo.toml di radice è generato e va trattato come read-only. Leggere sì, forkarlo anche, farci accettare una PR no.

Sul piano pratico: la build richiede prerequisiti non banali per chi non mastica Rust (DotSlash, protoc via strumenti ermetici), Windows come host di build è dichiaratamente best-effort, e l'esperienza «ufficiale» — autenticazione, modelli, changelog — resta agganciata all'ecosistema xAI. Infine, la fotografia delle stelle è di questi giorni e il progetto è giovane come open source: struttura dei crate e superficie di configurazione possono cambiare a ogni sync.

• Niente contribuzioni esterne: repository in sola lettura per la comunità, sync periodico dal monorepo.
• Cargo.toml di radice generato: si modificano i Cargo.toml per-crate, non quello globale.
• Build con prerequisiti: toolchain Rust bloccata, DotSlash e protoc; Windows best-effort.
• Default legato a xAI: senza configurazione local-first, autenticazione e inference passano dai servizi Grok.
• Progetto giovane come open source: struttura e config possono cambiare fra un sync e l'altro.

✅ Da dove partire

Il percorso che suggerisco parte dalla lettura, non dall'uso: clona il repository e apri crates/codegen/xai-grok-tools per vedere come sono implementati i tool di modifica file e terminale, poi xai-grok-shell per il loop dell'agente. Se usi già un altro agente, confronta le implementazioni con quello che conosci: è il modo più rapido per capire cosa fa davvero il tuo strumento quotidiano. Come secondo passo, prova la build con Cargo e lancia la TUI; come terzo, sperimenta la configurazione local-first puntando a una inference tua.

Il segnale più ampio è la direzione dell'ecosistema: dopo Codex e opencode, anche xAI ha messo il proprio harness sul tavolo, con tanto di port dichiarati delle implementazioni altrui. Gli harness agentici stanno diventando infrastruttura comune e leggibile — e per chi costruisce software con gli agenti, saperli leggere sta diventando una competenza di base.