Grok Build ahora es código abierto: qué cambia de verdad

En pocas palabras: xAI liberó el código de Grok Build bajo licencia Apache 2.0 el 15 de julio de 2026, dos días después de apagar la función que subía repositorios Git completos, con todo el historial, al bucket grok-code-session-traces de Google Cloud. El repositorio ya está en GitHub: xai-org/grok-build.

xAI publicó el código de Grok Build bajo licencia Apache 2.0 el 15 de julio de 2026, dos días después de apagar la función que subía repositorios Git completos a un bucket de Google Cloud. El repositorio ya está en GitHub. Grok Build código abierto es la respuesta al incidente, aunque no lo resuelve del todo.

Grok Build es el agente de codificación de terminal de xAI: una interfaz de texto a pantalla completa que lee tu código, edita archivos, ejecuta comandos de shell, busca en la web y maneja tareas largas. Corre en macOS, Linux y Windows, tiene modo headless para CI y desde el 15 de julio de 2026 su código fuente es público bajo licencia Apache 2.0 en el repositorio xai-org/grok-build.

¿Qué es Grok Build y qué puede hacer?

Grok Build es un agente de codificación que vive en la terminal, no en el editor. Según la documentación del propio repositorio, es un TUI a pantalla completa, con soporte de mouse, que entiende tu codebase, edita archivos, ejecuta comandos de shell, busca en la web y sostiene tareas de larga duración. Se instala con un script (curl -fsSL https://x.ai/cli/install.sh | bash en Bash, irm https://x.ai/cli/install.ps1 | iex en PowerShell) y hay binarios precompilados para las tres plataformas grandes.

Tiene dos cosas que lo diferencian del resto: un modo headless pensado para scripting y pipelines de CI, y soporte de Agent Client Protocol, así lo enchufás a otras herramientas sin escribir un wrapper. Sobre el papel, es una propuesta sólida.

El problema nunca estuvo en lo que hacía de cara al usuario.

¿Qué pasó exactamente con los repositorios y el bucket de Google Cloud?

Un investigador que publica como cereblab capturó el tráfico de red de Grok Build 0.2.93 y encontró que el cliente empaquetaba el repositorio rastreado completo, historial de Git incluido, y lo subía a un bucket de Google Cloud Storage llamado grok-code-session-traces. No los archivos que el modelo leía. Todo. Para más detalles técnicos, mirá infraestructura de Google Cloud.

La comparación que ordena todo el caso: sobre un repositorio de 12 GB, el tráfico de turnos de modelo hacia /v1/responses fue mínimo, mientras que el canal de storage hacia /v1/storage movió el bundle entero, según el análisis de cereblab reportado por The Hacker News. Ponele que le pedís al agente que te arregle un typo en un README: se lleva el repo entero igual.

¿Cómo se prueba que el modelo no lo estaba leyendo? Con un canario. Los investigadores plantaron un archivo src/_probe/never_read_canary.txt con un marcador único, el agente nunca lo abrió, y el archivo apareció igual dentro del bundle interceptado en las requests de storage. Prueba limpia, difícil de discutir.

Lo más feo viene acá. Cuando Grok leía archivos con secretos, esos secretos salían de la máquina sin enmascarar: un .env de prueba con una API key canario y una contraseña de base de datos apareció en texto plano, sin redactar, tanto en el procesamiento del modelo como en el archivo de storage. Y el toggle de privacidad no hacía nada: con “Improve the model” apagado, el servidor seguía respondiendo trace_upload_enabled: true. Ahí está el truco de fondo, y es importante entenderlo: un toggle controlaba el consentimiento para entrenar, otro controlaba si el código se iba de tu máquina, y vos solo veías el primero.

En el mismo test comparativo, Claude Code y Codex no enviaron ningún bundle de repositorio. Grok Build era el outlier.

¿Por qué xAI abrió el código bajo licencia Apache 2.0?

Porque era la única jugada que quedaba. El 13 de julio xAI apagó las subidas desde el servidor, el 14 estalló la cobertura, y el 15 publicaron el código bajo Apache 2.0. La secuencia habla sola. La postura oficial es de transparencia: si el código es auditable, cualquiera puede verificar qué se manda y qué no, en vez de creerle a un toggle. Cubrimos ese tema en detalle en cómo Google implementa IA en búsqueda.

Desde la cuenta oficial de xAI aclararon que los equipos enterprise con zero data retention nunca tuvieron código ni trazas almacenadas, que el uso por API-key respeta esas políticas, y que los suscriptores individuales pueden correr /privacy en el CLI para desactivar la retención y borrar lo ya sincronizado.

Cómo se implementa eso, no lo dijeron.

¿Grok Build código abierto significa que tu código ya no sale de tu máquina?

No. Y este es el punto que más se está malinterpretando esta semana. Lo que xAI liberó es el cliente, no el modelo. Grok Build compilado en tu notebook sigue llamando a la API de x.ai para cada turno de inferencia, así que tu código sigue viajando: ese era, justamente, el canal del modelo. Lo que cambia no es el destino, es la visibilidad.

Y esa visibilidad no es poco. Con el fuente en la mano podés leer exactamente qué se empaqueta y bajo qué condición, compilar un binario del que sabés qué hace, y detectar si el código de upload se reactiva. Porque sigue ahí: un análisis posterior encontró que la lógica de subida persiste en el binario, dormida únicamente por el flag del servidor. Traducido: xAI puede volver a prenderla sin publicar ninguna actualización.

Así que la “solución estructural” que están vendiendo varios medios es, en rigor, una solución de auditoría. Útil, necesaria, pero no es lo mismo. Si querés un agente donde el código no salga nunca de la máquina, necesitás pesos abiertos corriendo en hardware propio, y eso no es lo que se publicó el 15 de julio.

¿Cómo instalar Grok Build y compilarlo desde el fuente?

Para la versión precompilada, el script oficial de x.ai resuelve la instalación en macOS, Linux y Windows. Para la versión auditable, cloná xai-org/grok-build desde GitHub y compilá desde el fuente siguiendo el README del repo, que es la referencia que se mantiene actualizada. El primer código propio va bajo Apache 2.0; las dependencias de terceros conservan sus licencias originales, detalladas en el archivo THIRD-PARTY-NOTICES.

• Compilar no te desconecta de x.ai. Vas a necesitar tu API key igual, porque la inferencia es remota.
• Revisá el flag del servidor. Hoy devuelve disable_codebase_upload: true y trace_upload_enabled: false, pero es una configuración remota, no una garantía del binario.
• Apache 2.0 te habilita a forkear. Podés arrancar la ruta de storage de raíz y compilar tu propia versión, que es probablemente lo que va a hacer la comunidad en las próximas semanas.

¿Qué alternativas hay a Grok Build y cómo se portaron en el test?

El test de cereblab de julio de 2026 midió a los cuatro agentes de terminal más usados con el mismo criterio: cuánto sale de la máquina más allá de lo que el modelo necesita. Grok Build fue el único que mandaba bundles del repositorio completo. En herramientas de desarrollo asistidas por IA profundizamos sobre esto.

Herramienta	¿Enviaba el repo entero?	Detalle del test (jul 2026)
Grok Build 0.2.93	Sí	Bundle completo a storage, órdenes de magnitud por encima del tráfico al modelo, sobre un repo de 12 GB
Claude Code	No	Sin bundles de repositorio
Codex	No	Sin bundles de repositorio
Gemini CLI	Sin bundles en reposo	El test con tareas reales quedó bloqueado por cuota

Ojo con leer esta tabla como un ranking definitivo. Mide una cosa sola, en un momento puntual, con la metodología de un investigador. Que Gemini CLI no haya podido completar el test con carga real deja un hueco honesto.

Qué está confirmado y qué no

Confirmado:

• El upload existió y era masivo. Bucket grok-code-session-traces, verificado con archivo canario.
• Los secretos salían sin enmascarar. El .env de prueba viajó en texto plano.
• Apagaron desde el servidor el 13 de julio. cereblab retesteó y no volvió a ver subidas a /v1/storage, y el desarrollador Peter Dedene reportó los mismos flags en su cuenta.
• El código es Apache 2.0 desde el 15 de julio de 2026. Está en el repo oficial.

No confirmado:

• Cuántos usuarios se vieron afectados. xAI no publicó ningún número.
• Cuánto tiempo se retuvieron los datos. Tampoco lo dijeron.
• Si el borrado ya ocurrió. Hay una postura oficial, no hay evidencia técnica ni auditoría de terceros.
• Por qué se subían repos completos por defecto. Sin explicación oficial hasta hoy.

Errores comunes al reaccionar a este incidente

Creer que desinstalar alcanza. No. Si corriste Grok Build sobre un repo con secretos, esos secretos ya salieron. Desinstalar no los trae de vuelta. Lo que corresponde es rotar: cualquier credencial que el agente pudo leer, cualquier archivo rastreado, y los secretos que estén en el historial de commits. Si en ese .env estaban las claves del panel de tu hosting o de tu base, entran en la lista igual; en donweb.com, por ejemplo, regenerás las credenciales del panel y de la base sin tocar el resto de la infra.

Pensar que borrar el secreto del repo lo saca del bundle. Acá está el error más caro. El bundle incluía el historial completo, así que una API key que commiteaste en marzo y borraste en abril viajó igual. Los archivos en .gitignore quedaron afuera; los commiteados, no, sin importar que después los hayas eliminado.

Confiar en el toggle de privacidad como control técnico. Esa es la lección transferible, y va más allá de Grok. Un toggle es una promesa en la UI, no una garantía en la red. Si el dato importa, la única verificación que vale es capturar el tráfico o leer el código.

Asumir que “ahora es open source” equivale a “ahora es local”. Ya lo dijimos arriba, pero es el malentendido que más circula. Compilar el cliente no muda el modelo a tu máquina. Relacionado: competencia entre modelos de IA.

Esto tiene más sentido si leés nuestro artículo sobre Grok Build open source.

Preguntas Frecuentes

¿Qué es Grok Build?

Grok Build es el agente de codificación de terminal de xAI: un TUI a pantalla completa que entiende tu codebase, edita archivos, ejecuta comandos de shell y busca en la web. Corre en macOS, Linux y Windows, tiene modo headless para CI e integración vía Agent Client Protocol.

¿Bajo qué licencia se publicó Grok Build?

Apache License 2.0, desde el 15 de julio de 2026, en el repositorio xai-org/grok-build de GitHub. Aplica al código propio de xAI; las dependencias de terceros mantienen sus licencias originales. Apache 2.0 permite uso comercial, modificación, distribución y forks, e incluye una concesión explícita de patentes.

¿Es seguro usar Grok Build ahora?

Las subidas de repositorios están apagadas desde el 13 de julio de 2026 y cereblab verificó que dejaron de aparecer requests a /v1/storage. El matiz es que el código de upload sigue presente en el binario, desactivado solo por un flag del servidor, así que xAI podría reactivarlo sin publicar una actualización.

¿Puedo correr Grok Build sin que mi código llegue a xAI?

No con la release del 15 de julio. Lo que se abrió es el cliente, no los pesos del modelo: la inferencia sigue ocurriendo en la infraestructura de xAI y el contexto que el agente usa viaja a la API de x.ai. Compilar desde el fuente te da auditabilidad sobre cuánto se envía, no ejecución local.

¿Qué credenciales tengo que rotar si usé Grok Build?

Todas las que el agente pudo alcanzar: las de archivos que leyó, las de cualquier archivo rastreado por Git, y las que aparezcan en el historial de commits aunque las hayas borrado después. Los archivos en .gitignore quedaron fuera de los bundles.

Conclusión

Lo que cambió el 15 de julio es el nivel de confianza que Grok Build te exige. Antes tenías que creerle a un toggle que mentía. Ahora podés leer el código, compilarlo y verificar. Es una mejora real y hay que reconocerla, sobre todo por la velocidad: 48 horas entre la denuncia y la publicación del fuente es una reacción rápida para cualquier empresa.

Dicho esto, no es la solución que están titulando. La lógica de upload sigue viva en el binario, apagada por un flag remoto, y xAI todavía no dijo cuántos usuarios afectó, cuánto tiempo guardó los datos ni por qué el default era subir todo. Esas tres respuestas valen más que el repositorio.

Si usaste la herramienta antes del 13 de julio, tu tarea de esta semana es una sola: rotar credenciales, incluidas las que creías borradas del historial. Si estás evaluando agentes de terminal para tu equipo, agregá una prueba al checklist de compra, capturá el tráfico durante una hora de uso real y compará lo que sale contra lo que la tarea necesitaba. Esa desproporción no la encontró una auditoría de compliance ni un pentest contratado: la encontró alguien mirando la red.

Fuentes

• xai-org/grok-build en GitHub – Repositorio oficial, licencia Apache 2.0 y documentación de instalación
• The Hacker News – El análisis de cereblab: bucket, archivo canario y toggle inefectivo
• TechTimes – Cobertura del incidente y del toggle de privacidad que no hacía nada
• WinBuzzer – El código de upload persiste en el binario, dormido por el flag del servidor
• Basenor – Qué implica la apertura del código de Grok Build