xAI a publié sous licence Apache 2.0 le code source complet de Grok Build, son agent de codage en ligne de commande. La démarche n'a rien d'un geste militant : elle intervient après la découverte, par un chercheur du collectif Cereblab, que l'outil transférait des dépôts Git entiers vers un bucket Google Cloud de xAI. Le code désormais public offre une occasion rare de disséquer le fonctionnement interne d'un agent de codage — de sa boucle de raisonnement à ses outils, en passant par son interface terminal — tout en éclairant, en creux, le problème de confiance qui a précédé son ouverture.

De la fuite à l'ouverture du code

L'affaire commence à la mi-juillet 2026. Un chercheur publiant sous le pseudonyme Cereblab intercepte le trafic réseau de Grok Build (aussi appelé Grok CLI ou Grok Code) à l'aide de mitmproxy, en routant la version 0.2.93 du client à travers un proxy muni d'un certificat de confiance. L'analyse au niveau du fil, sur macOS, révèle deux canaux distincts vers xAI : les échanges « vivants » avec le modèle via POST /v1/responses, et un canal d'archivage moins documenté via POST /v1/storage.

Le constat est brutal. L'outil ne remonte pas seulement les fichiers que l'agent lit réellement : il téléverse le dépôt Git dans son intégralité. Sur un projet de 12 Go, le chercheur mesure environ 5,1 Gio expédiés en 73 morceaux d'environ 75 Mo, quand le modèle n'a traité que 192 Ko — un écart d'un facteur d'environ 27 800. Pour le prouver, il plante un fichier canari, src/_probe/never_read_canary.txt, explicitement jamais ouvert par l'agent, et le récupère intact dans un bundle Git capturé. Pire : des fichiers .env contenant clés d'API et mots de passe de base de données apparaissent en clair dans les corps de requêtes, non expurgés. La destination est un bucket Google Cloud Storage nommé grok-code-session-traces, l'analyse binaire faisant même remonter des chaînes du type « Uploading bytes to GCS via proxy ». On retrouve tous les détails de cette exfiltration dans notre article dédié.

xAI a réagi par un kill switch côté serveur, sans mise à jour du client : dès le 13 juillet, les réponses serveur basculent sur disable_codebase_upload: true et trace_upload_enabled: false, et l'outil cesse d'émettre des requêtes de stockage. Elon Musk a promis que les données déjà téléversées seraient « complètement et totalement supprimées », et annoncé l'open-sourcing du projet après un audit de sécurité, selon The Hacker News. Le chercheur relève toutefois une faille de conception dans les contrôles utilisateur : le bouton « Improve the model » ne gouvernait que l'entraînement, pas la transmission du dépôt — deux mécanismes séparés dont un seul était exposé.

Une architecture Rust en monorepo

Le dépôt officiel xai-org/grok-build, publié sous licence Apache 2.0, contient environ 844 000 lignes de Rust, d'après DevOps.com. Le projet n'est pas un dépôt communautaire au sens classique : xAI précise qu'il est synchronisé périodiquement depuis son monorepo interne, qu'un fichier SOURCE_REV enregistre le SHA du commit correspondant, et que les contributions externes ne sont pas acceptées.

Le binaire, nommé en interne xai-grok-pager mais distribué sous la commande grok, s'articule autour de plusieurs crates du workspace, organisées sous crates/codegen/. La séparation des responsabilités y est nette :

  • xai-grok-pager : l'implémentation de la TUI (rendu, scrollback, modales, saisie).
  • xai-grok-shell : le runtime de l'agent et ses points d'entrée — mode leader, stdio et headless.
  • xai-grok-tools : l'implémentation des outils (édition de fichiers, terminal, recherche).
  • xai-grok-workspace : la couche système de fichiers, VCS, exécution et checkpoints.

Le Cargo.toml racine est généré et en lecture seule, et la chaîne d'outils est figée via rust-toolchain.toml. Le support vise macOS et Linux, Windows restant « best-effort ».

La boucle de l'agent : contexte, parsing, routage

Le cœur du système est une boucle interactive qui enchaîne trois opérations, celles que l'on retrouve dans tout agent de codage moderne. D'abord la constitution du contexte : l'agent agrège l'état du workspace — arborescence, fichiers pertinents, historique VCS — pour composer l'invite envoyée au modèle. Ensuite le parsing des réponses : la sortie du modèle est interprétée pour en extraire les actions à mener, notamment les appels d'outils. Enfin le routage des appels : chaque appel est dispatché vers l'implémentation adéquate dans xai-grok-tools, dont le résultat est réinjecté dans le contexte au tour suivant.

C'est précisément à ce niveau que se logeait le problème de confiance. La boucle qui remonte le contexte au modèle est une chose ; le canal d'archivage session_state, qui empaquetait et expédiait le dépôt entier vers GCS, en était une autre, largement invisible pour l'utilisateur. Lire le code, c'est pouvoir vérifier ce qui, dans le contexte assemblé, part réellement sur le réseau — l'argument de transparence que xAI met désormais en avant.

Les outils : lire, éditer, chercher, exécuter

L'agent dispose d'un jeu d'outils classique pour un assistant de codage : lecture, édition et recherche dans le code, ainsi qu'exécution de commandes shell. La crate xai-grok-workspace encapsule les accès disque, le contrôle de version et l'exécution, avec un système de checkpoints permettant de matérialiser et, au besoin, d'annuler les modifications. S'y ajoutent des outils tournés vers le temps réel : search_web et search_x interrogent respectivement le web et les publications de la plateforme X, tandis que des outils generate_image et generate_video ouvrent la porte à des flux texte-vers-image et texte-vers-vidéo directement depuis l'agent.

Cette conception modulaire — chaque capacité isolée dans une fonction outil au contrat explicite — est la norme des agents actuels. Elle facilite l'audit : c'est en inspectant l'outil de lecture de fichiers, et en constatant l'écart entre ce qu'il traite et ce qui sort de la machine, que Cereblab a pu chiffrer l'anomalie.

L'interface terminal : rendu, saisie, révision des plans

La couche xai-grok-pager fournit une TUI plein écran, interactive à la souris et scriptable. Elle gère le rendu du scrollback, les boîtes de dialogue modales, les raccourcis clavier et les commandes slash, ainsi qu'un flux de révision des plans : avant d'appliquer une série d'actions, l'agent peut soumettre son plan à la validation de l'utilisateur. Au-delà du mode interactif, deux autres régimes coexistent — un mode headless pour l'automatisation et l'intégration continue, et une prise en charge du protocole Agent Client Protocol (ACP) pour l'embarquer dans des éditeurs.

Ce point de contrôle humain — la révision des plans — est central dans le débat de confiance ouvert par l'affaire. Un agent peut demander l'aval de l'utilisateur avant d'éditer ou d'exécuter, mais rien de tel n'encadrait le téléversement silencieux du dépôt : l'action invisible échappait, par construction, au consentement affiché à l'écran.

Un précédent qui dépasse Grok

L'épisode illustre une tension propre à la génération actuelle d'agents de codage : pour être utiles, ils réclament un accès très large au poste de travail — code, secrets, historique — et la frontière entre « contexte envoyé au modèle » et « données archivées côté fournisseur » reste opaque pour l'utilisateur final. Publier le code ne répare pas rétroactivement la fuite, mais il transforme une promesse (« nous avons tout supprimé ») en quelque chose de vérifiable, du moins pour la partie cliente.

L'ironie n'échappera à personne alors que Musk vante régulièrement la supériorité de ses modèles, y compris en interne chez Tesla et SpaceX : la confiance dans un agent de codage ne se décrète pas depuis un compte X, elle se lit dans le code. Grok Build vient d'en administrer la démonstration, à ses dépens.