Gemini CLI v0.65.0 comble des lacunes de fiabilité des espaces de travail et des sessions

La version v0.65.0 de Gemini CLI de Google corrige des défaillances susceptibles d’écraser les paramètres d’un espace de travail ou de supprimer l’historique d’une conversation reprise. Publiée le 20 octobre 2026, la mise à jour cible également les réponses d’outils dupliquées, la compatibilité de l’authentification et le défilement dans le terminal. Son importance se situe dans ce qui entoure une réponse d’IA : préserver la configuration, reconstruire les actions précédentes et maintenir le contexte de travail du développeur.

La tension centrale oppose la praticité à une gestion fiable de l’état. L’état désigne les informations qu’une application conserve sur sa configuration, ses conversations et les actions effectuées. Il devient plus difficile de faire confiance à un assistant de programmation lorsque ces informations changent de façon imprévisible, même si le code généré paraît raisonnable. Cette version remet ces responsabilités moins visibles au premier plan.

Claude Code offre un point de comparaison utile, car sa documentation traite également les autorisations et les limites d’exécution comme des préoccupations explicites du produit. Cette version n’établit toutefois aucun classement concurrentiel. La pression immédiate s’exerce sur les mainteneurs de Gemini CLI et les équipes qui l’adoptent : les correctifs documentés doivent se traduire par un comportement prévisible lors des interruptions ordinaires.

Ce que change réellement Gemini CLI v0.65.0

Le thème le plus clair de la mise à jour est la préservation de l’environnement de travail du développeur lors de modifications de configuration, de la récupération de sessions et des interactions avec l’interface.

Les modifications de la version publiées signalent des correctifs pour les paramètres d’espaces de travail non approuvés, les réponses dupliquées lors de la récupération de sessions et la suppression de l’historique après une sortie rapide. Elles comprennent aussi une validation de l’authentification et la suppression inutile du terminal lors de l’extension de la sortie avec Ctrl+O.

Ces changements concernent différentes parties de l’application. La configuration détermine le comportement d’un projet. L’historique des conversations enregistre les travaux antérieurs. L’authentification relie des services externes. La sortie du terminal aide la personne qui supervise l’assistant à comprendre ce qui s’est produit.

Pour les lecteurs qui cherchent à déterminer si cette version compte, cette répartition est plus instructive que le seul numéro de version. Elle suggère une mise à jour qu’il vaut la peine d’évaluer au regard des flux de travail existants, en particulier ceux qui utilisent des conversations enregistrées et des paramètres propres à un projet.

Les notes incluent également la maintenance du journal des modifications, une hausse de version nocturne et une correction du flux de travail du dépôt. Ces entrées relèvent des opérations de publication. Elles ne doivent pas être interprétées comme des améliorations distinctes de l’intelligence de programmation ni comme la preuve de nouvelles capacités de modèle.

Un numéro de version stable et une chaîne de version nocturne décrivent aussi deux choses différentes. Le premier identifie le paquet publié dont il est question. La seconde apparaît ici comme un élément de son historique de développement.

Cette distinction compte lorsque les équipes consignent leurs décisions de mise à niveau. Une évaluation utile exige la version installée, l’environnement et le comportement vérifié. Une date d’annonce retenue de mémoire aide beaucoup moins à reproduire un problème ultérieurement.

La modification du terminal illustre pourquoi un travail d’interface apparemment mineur appartient à la même discussion. Étendre une sortie est une action d’inspection. Elle doit aider les développeurs à examiner les informations sans rendre leur position plus difficile à retrouver.

L’interprétation plus large est simple : l’utilité d’un assistant dépend de l’application qui l’entoure autant que du modèle qui répond aux prompts. Il s’agit d’une évaluation éditoriale des changements, et non de l’affirmation que Google a annoncé une nouvelle orientation stratégique.

Il existe aussi une limite pratique à ce que l’annonce établit. Une entrée de version documente une correction prévue. Elle ne mesure pas la fréquence de la défaillance d’origine chez les utilisateurs.

Les développeurs ont donc des raisons d’examiner ces correctifs sans supposer que leur propre installation a connu chacun des problèmes répertoriés. Les équipes ayant des flux de travail concernés ont une raison plus précise d’évaluer la mise à jour que les lecteurs à la recherche de meilleurs scores de génération de code.

Les changements les plus conséquents méritent une attention distincte, car leurs modes de défaillance diffèrent. La protection de l’espace de travail concerne ce que l’application est autorisée à écrire. La récupération de session concerne la survie et la restitution fidèle des travaux précédemment enregistrés.

La confiance de l’espace de travail doit aussi régir les écritures de configuration

Une limite de confiance est incomplète lorsqu’elle désactive les paramètres du projet tout en autorisant des écritures destructrices via leur emplacement de fichier enregistré.

Un espace de travail est le répertoire de projet dans lequel l’assistant opère. La confiance de l’espace de travail détermine si l’application considère la configuration locale de ce projet comme approuvée.

Selon le correctif des paramètres d’espace de travail, un projet non approuvé recevait une représentation de configuration vide en mémoire. Cette représentation conservait l’emplacement du fichier de paramètres et restait accessible en écriture.

Une commande de configuration limitée à l’espace de travail pouvait ainsi enregistrer la représentation vide par-dessus les paramètres existants. Le correctif rend cette représentation en lecture seule et bloque les écritures concernées avant toute modification de la configuration.

Le contributeur décrit également des tests couvrant le rejet des mutations au niveau du projet et la préservation du fichier existant. Les paramètres au niveau de l’utilisateur restent opérationnels, tandis que l’établissement de la confiance restaure l’accès en écriture normal de l’espace de travail.

La distinction importante est celle entre ignorer une configuration et la préserver. Ces responsabilités sont liées, mais elles ne sont pas interchangeables. Un logiciel peut à juste titre refuser d’activer un fichier tout en le traitant mal lors d’une opération ultérieure.

Prenons le cas hypothétique d’un développeur qui examine un dépôt inconnu. Il n’a pas approuvé sa configuration et tente de modifier un paramètre d’intégration au niveau du projet. Il peut raisonnablement s’attendre à un refus explicite ou à une décision délibérée d’accorder la confiance.

Le remplacement silencieux de paramètres sans lien violerait cette attente. La commande du développeur exprime une intention limitée, tandis que la modification résultante du fichier aurait un effet bien plus étendu.

Cet exemple explique les enjeux sans affirmer que chaque dépôt inconnu contient une configuration nuisible. La préoccupation porte sur un comportement d’application prévisible dans des conditions restreintes.

Une erreur explicite introduit de la friction, mais elle identifie aussi une décision que le développeur doit prendre. Ce projet doit-il devenir approuvé ? Le changement doit-il s’appliquer à l’utilisateur à la place ? La configuration doit-elle rester intacte ?

Ces choix reviennent à la personne qui utilise l’assistant. Une représentation temporaire vide ne devrait pas y répondre indirectement par l’écrasement inattendu d’un fichier.

Pour les équipes de plateforme, l’implication s’étend à la conception de l’évaluation. Un outil devrait être évalué lorsqu’il refuse une opération, et pas seulement lorsqu’il accomplit une tâche approuvée.

Un refus réussi possède des propriétés observables. Les données existantes restent intactes. La raison est compréhensible. L’application ne laisse pas derrière elle une modification de configuration partiellement appliquée.

Il s’agit de critères d’acceptation proposés, plutôt que d’affirmations supplémentaires sur la version. Ils donnent aux équipes une manière concrète d’interpréter le correctif documenté dans leur propre environnement.

Le même raisonnement s’applique à la documentation interne. Un guide de déploiement devrait expliquer la relation entre la confiance d’un projet et la portée de la configuration, au lieu de simplement demander à chacun d’accepter une invite.

Les équipes qui maintiennent ce contexte peuvent conserver leurs décisions dans une base de connaissances consultable. Un enregistrement utile explique pourquoi une limite existe et quel flux de travail en dépend.

Cette documentation ne peut pas imposer des autorisations. Elle peut toutefois aider les réviseurs à distinguer un refus attendu d’une régression lorsque le comportement change après une mise à niveau.

La récupération de session pose des problèmes distincts d’exactitude et de préservation

Une conversation récupérée doit à la fois survivre sur le disque et reconstruire l’activité antérieure des outils sans ajouter de réponses dupliquées.

Le correctif de reconstruction de session traite les réponses d’outils dupliquées lorsque des conversations enregistrées reprennent. Une réponse d’outil est le résultat renvoyé après que l’assistant a demandé une opération externe.

Selon le contributeur, la récupération pouvait rejouer une réponse déjà enregistrée tout en générant une autre réponse à partir des résultats d’appels d’outils sauvegardés. La modification vérifie l’existence de réponses avant d’en générer des remplacements.

Elle filtre aussi les identifiants de réponse dupliqués au sein d’un échange et conserve un comportement de repli pour les enregistrements plus anciens. Les tests décrits couvrent les enregistrements modernes, les formats anciens, les appels parallèles et le filtrage des doublons.

Il s’agit de reconstruction, et non de la preuve qu’une commande externe a nécessairement été exécutée deux fois. Répéter une réponse historique dans le contexte de l’assistant diffère de l’exécution à nouveau de l’action sous-jacente.

Cette distinction est essentielle pour interpréter le correctif. Un historique de conversation inexact peut créer de la confusion sans prouver que l’application a dupliqué des modifications du système de fichiers ou des requêtes externes.

La préservation est un problème distinct. Le correctif de préservation de l’historique décrit la suppression de conversations enregistrées après que des utilisateurs les avaient reprises puis avaient quitté rapidement avant de soumettre un autre prompt.

Le contributeur identifie le suivi des sessions reprises et la coordination avec l’initialisation comme faisant partie du correctif. L’initialisation est le processus de démarrage qui prépare les données de travail de l’application.

La modification décrit aussi la vérification des données sauvegardées lorsque la mémoire ne contient pas encore d’informations de conversation fiables. Ces mécanismes ciblent la différence entre une nouvelle session vide et une session existante encore en cours de chargement.

Un scénario hypothétique du matin rend cette différence concrète. Un développeur ouvre la conversation d’hier pour vérifier son sujet, réalise qu’il a sélectionné la mauvaise, puis la ferme immédiatement.

Cette action ne devrait pas impliquer l’autorisation de supprimer le travail d’hier. Ouvrir puis quitter un enregistrement est différent de créer un enregistrement vide qui n’a jamais contenu de contenu utile.

L’exactitude compte aussi d’une autre manière. Un développeur qui reprend une enquête doit distinguer les actions proposées, les actions effectuées et les résultats produits par ces actions.

Imaginez une conversation contenant une vérification échouée suivie d’une correction réussie. Si la récupération déforme la relation entre les demandes et les résultats, la recommandation suivante devient plus difficile à évaluer.

Il s’agit d’une conséquence analytique d’enregistrements peu fiables, et non d’un résultat mesuré de la version. Les éléments disponibles ne quantifient ni la qualité des réponses en aval ni le temps économisé.

La leçon pour l’évaluation est néanmoins claire. Les équipes devraient examiner les éléments récupérés, plutôt que de juger la récupération uniquement selon l’ouverture de la fenêtre de conversation.

Elles devraient aussi éviter de considérer l’historique des conversations comme un registre d’audit complet. Un échange sauvegardé peut fournir un contexte utile tout en nécessitant une confirmation à partir des modifications de code et des résultats réels des commandes.

Pour Gemini CLI v0.65.0, ces correctifs font de la gestion des interruptions un sujet concret à examiner. La question pertinente est de savoir si un travail familier revient intact et reste compréhensible.

La compatibilité de l’authentification exige une validation précise

Une exigence d’authentification peut rejeter des connexions légitimes lorsque le client l’applique plus largement que ne le permettent les capacités déclarées du serveur.

OAuth, un cadre d’autorisation, permet aux applications d’obtenir un accès sans collecter directement le mot de passe d’un utilisateur. Sa réponse de redirection peut inclure iss, une valeur qui identifie le serveur d’autorisation.

La modification de validation de l’émetteur rend ce paramètre de réponse obligatoire uniquement lorsque les métadonnées du serveur déclarent explicitement sa prise en charge. Les métadonnées sont des informations lisibles par machine décrivant les capacités du serveur.

Selon le contributeur, Gemini CLI continue de valider l’émetteur chaque fois que la réponse l’inclut. La correction distingue donc une valeur facultative absente d’une valeur fournie qui doit correspondre aux attentes.

La pull request cite l’authentification Notion MCP comme exemple concerné. MCP, le Model Context Protocol, offre aux assistants une manière commune de se connecter à des outils et données externes.

Son auteur décrit des échecs lorsqu’un serveur publiait un émetteur sans déclarer la prise en charge du renvoi du paramètre d’émetteur. Cet exemple explique le problème de compatibilité sans établir combien d’utilisateurs l’ont rencontré.

La leçon pour le produit est qu’un comportement plus strict exige une définition précise. Exiger davantage d’informations n’est pas automatiquement préférable lorsque le protocole applicable considère ces informations comme facultatives.

Inversement, accepter l’absence d’un champ facultatif ne signifie pas accepter un champ incorrect. Présence, absence et non-correspondance représentent des conditions différentes.

Cette distinction donne aux responsables d’intégration une meilleure question à poser lors de la revue. De quelle capacité serveur le client dépend-il, et quels éléments déterminent si une réponse doit être acceptée ?

Un échec de connexion générique masque ces détails. Il laisse le développeur se demander si le problème concerne l’accès au compte, la disponibilité du service ou des hypothèses d’implémentation incompatibles.

Une connexion réussie ne constitue également qu’une partie de l’évaluation. Les équipes doivent vérifier que la connexion atteint le service attendu et accorde l’accès prévu.

Il s’agit de priorités de revue suggérées. Les sources de la version ne fournissent ni évaluation de sécurité indépendante ni enquête de compatibilité exhaustive couvrant les services externes.

Le lien avec la confiance dans l’espace de travail est conceptuel plutôt que mécanique. Les deux changements reposent sur la traduction d’une condition déclarée en comportement applicatif correct.

Pour un espace de travail, la condition déclarée est de savoir si le projet est fiable. Pour l’autorisation, il s’agit de savoir si le serveur annonce une capacité de réponse particulière.

Les difficultés surviennent lorsqu’un logiciel traite une représentation incomplète comme une instruction complète. Une configuration vide peut devenir un remplacement involontaire. Une déclaration d’émetteur peut devenir une exigence de rappel excessivement large.

Cette comparaison aide à expliquer la version sans fusionner des mécanismes sans rapport dans une seule affirmation technique. Les correctifs opèrent dans des chemins de code distincts et nécessitent des validations distinctes.

Pour les équipes qui s’appuient sur des services connectés, l’implication immédiate est une évaluation ciblée. Un flux d’autorisation qui échouait auparavant mérite un nouvel examen, avec sa configuration de service et les autorisations attendues consignées.

Affirmer plus largement que l’authentification est désormais universellement fiable dépasserait les éléments disponibles. La modification documentée étaye une conclusion plus restreinte et plus utile concernant une règle de validation précise.

La fiabilité est une question concurrentielle, sans classement

Les équipes qui choisissent un assistant de programmation ont besoin d’éléments sur les interruptions, les autorisations et la reprise, en plus des éléments concernant le code généré.

L’architecture des autorisations d’Anthropic offre un contexte concurrentiel pertinent. Sa documentation décrit des modes d’autorisation configurables ainsi qu’une isolation du système de fichiers et du réseau par sandboxing.

Le sandboxing consiste à restreindre l’accès d’un processus aux ressources situées en dehors de limites définies. Les contrôles d’autorisation déterminent quelles opérations nécessitent une approbation dans la configuration sélectionnée.

Il s’agit de fonctionnalités documentées par le fournisseur, et non d’une preuve indépendante que Claude Code empêche toute action indésirable. Elles établissent que les limites d’exécution constituent une partie explicite de la conception d’un produit concurrent.

La comparaison est délibérément limitée. La correction des paramètres d’espace de travail de Gemini CLI ne correspond pas directement à chaque réglage d’autorisation de Claude Code.

Les sources n’établissent pas non plus quel assistant présente moins de défauts, une meilleure reprise ou une charge opérationnelle moindre. Ces jugements exigeraient des tests comparables entre différentes versions et différents environnements.

Une comparaison équitable exposerait chaque outil au même flux de travail pertinent. Cela comprend le projet inspecté, les opérations autorisées, les services connectés et l’interruption introduite.

Le résultat devrait inclure davantage que la simple réalisation d’une tâche. Les évaluateurs doivent comprendre ce qui a changé, ce qui est resté sauvegardé et ce que l’opérateur a dû résoudre ensuite.

Cela oriente la conversation d’achat vers un travail qu’une équipe peut observer. Un outil qui produit un correctif acceptable doit toujours correspondre aux attentes de l’organisation concernant les fichiers locaux et le contexte conservé.

La pression est particulièrement concrète pour les responsables d’ingénierie chargés de paramètres par défaut partagés. Leur décision affecte des collègues qui ne liront peut-être jamais une note de version ni une discussion d’implémentation.

Ces responsables ont besoin d’une explication du comportement attendu qui résiste aux transmissions. Une limite documentée aide le support à distinguer une confusion de l’utilisateur d’un problème de produit.

Les développeurs individuels font face à une version plus réduite de la même responsabilité. Ils décident s’ils doivent faire confiance à un projet, reprendre une ancienne investigation ou connecter un autre service.

Un assistant prévisible réduit l’ambiguïté autour de ces décisions. La prévisibilité désigne ici un comportement correspondant à une règle explicite et pouvant être vérifié après coup.

Une lecture sceptique de Gemini CLI Release v0.65.0 reste nécessaire. Des correctifs détaillés montrent que les mainteneurs traitent des problèmes identifiés ; ils n’établissent pas l’absence de problèmes connexes.

Les descriptions des contributeurs et les tests ciblés constituent des éléments utiles concernant l’intention et la couverture. Ils ne remplacent pas l’observation du paquet publié dans l’environnement où il sera utilisé.

Rien ne permet non plus ici d’attribuer un pourcentage de productivité à la mise à jour. Éviter la perte d’une conversation a une valeur pratique évidente, mais son impact global n’a pas été mesuré.

La conclusion appropriée est plus restreinte qu’un verdict de marché. Cette version donne aux utilisateurs de Gemini CLI des changements précis de fiabilité à évaluer et fournit aux outils concurrents une norme de comparaison cohérente.

À surveiller après la mise à jour

Les éléments de suivi les plus solides viendront de comportements reproductibles, de dossiers préservés et d’une gestion claire des conditions visées par ces correctifs.

Le premier signal à surveiller est de savoir si la configuration de l’espace de travail reste intacte lorsqu’une opération restreinte est rejetée. Cela teste directement la limite décrite dans la correction des paramètres.

Pour une évaluation d’équipe, une reproduction documentée doit capturer la configuration d’origine, l’état de confiance, l’opération tentée et le fichier résultant. Cela rend le résultat vérifiable.

Si l’opération s’arrête proprement et préserve les paramètres non concernés, cela étaye le comportement prévu. Si la configuration change toujours de manière inattendue, l’ampleur du problème nécessite une investigation supplémentaire.

Le deuxième signal est de savoir si les conversations reprises restent disponibles et cohérentes malgré les interruptions. Disponibilité et cohérence doivent être examinées séparément, car elles répondent à des questions différentes.

Un enregistrement sauvegardé qui survit mais se reconstitue incorrectement crée toujours de l’incertitude. Un échange parfaitement reconstitué est tout aussi inutile si une sortie rapide ultérieure efface son historique sauvegardé.

Les rapports de suivi utiles décriraient donc à la fois ce qui est resté sur le disque et ce qui est apparu après la récupération. Une vague affirmation selon laquelle la reprise « a fonctionné » laisse des comportements importants inexpliqués.

Si les flux de travail pertinents restent stables, la confiance dans l’adoption de la version augmente. Des échecs reproductibles impliquant d’anciens enregistrements ou des sorties rapides affaibliraient cette évaluation.

Le troisième signal est de savoir si les flux d’autorisation externes concernés réussissent selon les capacités réellement annoncées par le serveur. Cela maintient l’évaluation liée au problème de compatibilité documenté.

Un résultat positif doit préserver la limite d’accès prévue tout en permettant une connexion prise en charge. Une réussite obtenue par une modification d’autorisation sans rapport répondrait à une autre question.

Les rapports doivent également distinguer l’authentification du comportement ultérieur des outils. Se connecter à un service n’établit pas que chaque opération exposée par ce service fonctionne correctement.

Au cours des prochains mois, les correctifs ultérieurs et les rapports détaillés des utilisateurs pourront aider à clarifier la portée restante. Les rapports les plus utiles identifieront les versions et les conditions plutôt que d’offrir une approbation ou une critique générale.

Ces points d’observation sont des critères d’évaluation proposés, et non des jalons promis par Google. Leur objectif est de transformer une annonce de version en questions aux réponses observables.

Ils aident également les équipes à éviter de réagir de façon excessive dans un sens comme dans l’autre. Un rapport de défaut n’établit pas un échec universel, tandis qu’une démonstration réussie n’établit pas une fiabilité universelle.

Pour les utilisateurs existants, la mise à jour est surtout pertinente là où ses corrections documentées recoupent le travail quotidien. Les investigations sauvegardées, la configuration du projet et les services connectés offrent des points concrets pour l’évaluer.

Commencez par le flux de travail dont votre équipe dépend le plus, puis consignez ce qui se produit avant et après l’adoption de Gemini CLI Release v0.65.0. Gardez la configuration du projet, les autorisations attendues et la conversation sauvegardée disponibles à des fins de comparaison. Demandez à un collègue de revoir le résultat sans s’appuyer sur votre souvenir de la session. Si une limite bloque une opération, vérifiez que l’explication est cohérente et que les informations existantes restent intactes. Si une conversation reprend, comparez ses actions enregistrées avec le travail sous-jacent. Utilisez ces observations pour déterminer si la mise à jour convient à votre environnement. Quelle interruption serait la plus coûteuse à récupérer pour votre équipe, et le paquet publié la gère-t-il de manière prévisible ?