Gemini CLI 0.67 : lister les modèles et relier l'éditeur au bac à sable

Gemini CLI est l'agent de code de Google qui s'utilise dans le terminal. Sa version 0.67.0, publiée le 4 novembre sur GitHub, contient surtout des corrections, mais deux nouveautés intéressent directement les équipes qui l'automatisent ou qui l'isolent dans un conteneur.

Savoir quels modèles sont disponibles

La version 0.67.0 ajoute deux moyens équivalents de demander à l'outil la liste des modèles utilisables :

gemini models
gemini --list-models

La forme gemini models list fonctionne aussi. L'option --list-models s'exécute sans interface interactive et se termine avant toute mise en place du bac à sable.

Pour un script, la sortie existe en JSON :

gemini models -o json

Chaque entrée comporte l'identifiant du modèle, son nom affiché, une description et ses limites de contexte en jetons d'entrée et de sortie. D'après la demande de fusion, les messages qui ne sont pas du JSON partent sur la sortie d'erreur et la commande renvoie un code de sortie non nul en cas d'échec. La sortie peut donc être envoyée telle quelle à un outil comme jq.

L'éditeur retrouve l'agent dans son conteneur

Gemini CLI peut s'exécuter dans un bac à sable, c'est-à-dire un conteneur qui limite ce que l'agent peut toucher sur la machine. Le problème : dans cette configuration, l'intégration avec l'éditeur (fichiers ouverts transmis comme contexte, différentiels affichés dans l'éditeur) ne fonctionnait pas. L'extension compagnon n'écoute que sur la machine hôte et exige un jeton que le lanceur ne transmettait pas au conteneur.

La version 0.67.0 installe un relais. Le lanceur, côté hôte, se connecte à l'extension et fait passer les échanges vers le conteneur, sans jamais y envoyer le jeton. La demande de fusion décrit plusieurs garde-fous :

• seules les opérations d'ouverture et de fermeture de différentiel, et les notifications de l'éditeur, sont relayées ;
• le chemin d'un fichier doit se trouver dans un dossier de l'espace de travail de l'éditeur, vérification faite côté hôte ;
• le relais ne vit que le temps de la session et n'écoute sur aucune interface réseau.

Aucune nouvelle option n'est à activer. Il suffit de lancer l'outil depuis le terminal intégré de l'éditeur avec un bac à sable défini, par exemple GEMINI_SANDBOX=docker gemini, puis de vérifier avec /ide status.

Les limites

• Docker, Podman et gVisor sont visés, mais l'auteur indique n'avoir testé en conditions réelles que Docker. Podman n'est couvert que par des tests unitaires.
• node doit être présent dans l'image du conteneur.
• Les hôtes Windows et LXC sont hors périmètre.
• Après un redémarrage de l'éditeur, il faut relancer /ide enable pour reconnecter.

Des corrections à noter

Parmi la vingtaine de correctifs : en mode non interactif, l'outil gère désormais les signaux d'arrêt et n'exécute plus d'outil après une annulation. Les erreurs de plafond de dépenses d'un projet sont classées comme des erreurs de quota définitives. Les demandes de permission transmises via le protocole ACP indiquent le serveur MCP et l'outil concernés.

Notre lecture

Pour une petite équipe, la commande models règle un problème banal mais réel : un script qui cible un modèle retiré échoue sans explication claire. Une vérification en début de pipeline suffit maintenant à l'éviter. Le relais vers l'éditeur, lui, supprime une raison fréquente de désactiver le bac à sable par commodité. Si vous aviez fait ce choix, c'est le moment de le réactiver, d'abord sur Docker, la seule configuration réellement éprouvée par l'auteur.