Gemini CLI Release v0.65.0 corrige brechas de fiabilidad en el espacio de trabajo y las sesiones
Google’s Gemini CLI Release v0.65.0 aborda fallos que podían sobrescribir la configuración del espacio de trabajo o eliminar el historial de conversaciones reanudadas. Publicada el 20 de octubre de 2026, la actualización también se centra en respuestas de herramientas duplicadas, compatibilidad de autenticación y desplazamiento en la terminal. Su relevancia reside en el trabajo que rodea una respuesta de IA: preservar la configuración, reconstruir acciones previas y mantener intacto el contexto de trabajo de un desarrollador.
La tensión central es la comodidad frente a una gestión fiable del estado. El estado es la información que una aplicación conserva sobre su configuración, conversaciones y acciones completadas. Es más difícil confiar en un asistente de programación cuando esa información cambia de forma inesperada, incluso si el código que genera parece razonable. La versión pone el foco en esas responsabilidades menos visibles.
Claude Code ofrece una comparación útil porque su documentación también trata los permisos y los límites de ejecución como preocupaciones explícitas del producto. Sin embargo, esta versión no establece una clasificación competitiva. La presión inmediata recae sobre los responsables de Gemini CLI y los equipos que lo adoptan: las correcciones documentadas deben traducirse en un comportamiento predecible durante las interrupciones habituales.
Qué cambia realmente Gemini CLI Release v0.65.0
El tema más claro de la actualización es preservar el entorno de trabajo del desarrollador ante cambios de configuración, recuperación de sesiones e interacciones con la interfaz.
Los cambios de la versión publicados identifican correcciones para configuraciones de espacios de trabajo no confiables, respuestas duplicadas durante la recuperación de sesiones y eliminación del historial tras una salida rápida. También incluyen validación de autenticación y la limpieza innecesaria de la terminal al expandir la salida con Ctrl+O.
Estos cambios afectan a distintas partes de la aplicación. La configuración determina cómo se comporta un proyecto. El historial de conversaciones registra el trabajo anterior. La autenticación conecta servicios externos. La salida de la terminal ayuda a la persona que supervisa al asistente a entender qué ocurrió.
Para quienes deciden si la versión es relevante, esa distribución aporta más información que el número de versión por sí solo. Sugiere una actualización que merece evaluarse frente a los flujos de trabajo existentes, especialmente los que implican conversaciones guardadas y configuraciones específicas del proyecto.
Las notas también incluyen mantenimiento del registro de cambios, un incremento de versión nocturna y una corrección del flujo de trabajo del repositorio. Esas entradas pertenecen a las operaciones de lanzamiento. No deben interpretarse como mejoras independientes de la inteligencia para programar ni como evidencia de nuevas capacidades del modelo.
Un número de versión estable y una cadena de versión nocturna también describen cosas distintas. El primero identifica el paquete publicado que se está analizando. La segunda aparece aquí como un elemento de su historial de desarrollo.
Esta distinción importa cuando los equipos registran decisiones de actualización. Una evaluación útil necesita la versión instalada, el entorno y el comportamiento que se está comprobando. Recordar una fecha de anuncio ofrece mucha menos ayuda al reproducir un problema más adelante.
El cambio en la terminal ilustra por qué un trabajo de interfaz aparentemente menor pertenece a la misma conversación. Expandir la salida es una acción de inspección. Debe ayudar a los desarrolladores a revisar información sin dificultar la recuperación de su posición.
La interpretación más amplia es directa: la utilidad de un asistente depende de la aplicación que lo rodea, además del modelo que responde a las indicaciones. Esta es una evaluación editorial de los cambios, no una afirmación de que Google haya anunciado una nueva dirección estratégica.
También existe un límite práctico respecto a lo que establece el anuncio. Una entrada de versión documenta una corrección prevista. No mide la frecuencia del fallo original entre los usuarios.
Por tanto, los desarrolladores tienen motivos para examinar estas correcciones sin asumir que su propia instalación experimentó todos los problemas enumerados. Los equipos con flujos de trabajo relevantes tienen una razón más específica para evaluar la actualización que quienes buscan mejores puntuaciones de generación de código.
Los cambios más relevantes merecen atención por separado porque sus modos de fallo difieren. La protección del espacio de trabajo se refiere a lo que la aplicación puede escribir. La recuperación de sesiones se refiere a si el trabajo guardado previamente sobrevive y se recupera con precisión.
La confianza en el espacio de trabajo también debe regir las escrituras de configuración
Un límite de confianza está incompleto cuando desactiva la configuración del proyecto pero aún permite escrituras destructivas mediante la ubicación de su archivo guardado.
Un espacio de trabajo es el directorio del proyecto en el que opera el asistente. La confianza en el espacio de trabajo determina si la aplicación trata la configuración local de ese proyecto como aprobada.
Según la corrección de configuración del espacio de trabajo, un proyecto no confiable recibía una representación vacía de la configuración en memoria. Esa representación conservaba la ubicación del archivo de configuración y seguía siendo editable.
Como consecuencia, un comando de configuración con ámbito de espacio de trabajo podía guardar la representación vacía sobre los ajustes existentes. La corrección hace que esa representación sea de solo lectura y bloquea las escrituras afectadas antes de que se produzcan cambios de configuración.
El colaborador también describe pruebas que cubren mutaciones de nivel de proyecto rechazadas y la preservación del archivo existente. Los ajustes con ámbito de usuario siguen funcionando, mientras que establecer la confianza restaura la capacidad normal de escritura del espacio de trabajo.
La distinción importante está entre ignorar la configuración y preservarla. Estas responsabilidades están relacionadas, pero no son intercambiables. Un software puede negarse correctamente a activar un archivo y, aun así, gestionar mal ese archivo durante una operación posterior.
Consideremos a un desarrollador hipotético que inspecciona un repositorio desconocido. No ha aprobado su configuración e intenta cambiar un ajuste de integración de nivel de proyecto. Su expectativa razonable es un rechazo explícito o una decisión deliberada de confianza.
Sustituir silenciosamente ajustes no relacionados violaría esa expectativa. El comando del desarrollador expresa una intención limitada, mientras que el cambio resultante en el archivo tendría un efecto mucho más amplio.
Este ejemplo explica lo que está en juego sin afirmar que todos los repositorios desconocidos contengan configuraciones perjudiciales. La preocupación es un comportamiento predecible de la aplicación bajo condiciones restringidas.
Un error explícito introduce fricción, pero también identifica una decisión que el desarrollador debe tomar. ¿Debe este proyecto pasar a ser confiable? ¿Debe aplicarse el cambio al usuario en su lugar? ¿Debe dejarse intacta la configuración?
Esas decisiones corresponden a la persona que opera el asistente. Una representación temporal vacía no debería responderlas indirectamente mediante una sobrescritura inesperada del archivo.
Para los equipos de plataforma, la implicación se extiende al diseño de evaluaciones. Una herramienta debe evaluarse mientras rechaza una operación, no solo mientras completa una tarea aprobada.
Un rechazo satisfactorio tiene propiedades observables. Los datos existentes permanecen intactos. El motivo es comprensible. La aplicación no deja tras de sí un cambio de configuración aplicado parcialmente.
Estos son criterios de aceptación propuestos, no afirmaciones adicionales sobre la versión. Ofrecen a los equipos una forma concreta de interpretar la corrección documentada dentro de su propio entorno.
El mismo razonamiento se aplica a la documentación interna. Una guía de despliegue debe explicar la relación entre la confianza del proyecto y el ámbito de configuración, en lugar de limitarse a indicar a todos que acepten un aviso.
Los equipos que mantienen ese contexto pueden conservar las decisiones en una base de conocimientos consultable. El registro útil explica por qué existe un límite y qué flujo de trabajo depende de él.
Esa documentación no puede aplicar permisos. Sin embargo, puede ayudar a los revisores a distinguir un rechazo esperado de una regresión cuando el comportamiento cambia tras una actualización.
La recuperación de sesiones presenta problemas distintos de precisión y preservación
Una conversación recuperada debe sobrevivir en el disco y reconstruir la actividad anterior de las herramientas sin añadir respuestas duplicadas.
La corrección de reconstrucción de sesiones aborda las respuestas de herramientas duplicadas cuando se reanudan conversaciones registradas. Una respuesta de herramienta es el resultado devuelto después de que el asistente solicita una operación externa.
Según el colaborador, la recuperación podía reproducir una respuesta ya registrada y, al mismo tiempo, generar otra respuesta a partir de los resultados guardados de llamadas a herramientas. El cambio comprueba las respuestas existentes antes de generar sustituciones.
También filtra identificadores de respuesta duplicados dentro de un intercambio y conserva un comportamiento de respaldo para registros antiguos. Las pruebas descritas cubren registros modernos, formatos antiguos, llamadas paralelas y filtrado de duplicados.
Esto se refiere a la reconstrucción, no a la evidencia de que un comando externo necesariamente se ejecutara dos veces. Repetir una respuesta histórica en el contexto del asistente es distinto de ejecutar nuevamente la acción subyacente.
Esta distinción es esencial para interpretar la corrección. Un registro inexacto de la conversación puede generar confusión sin demostrar que la aplicación duplicó cambios en el sistema de archivos o solicitudes externas.
La preservación es un problema independiente. La corrección de preservación del historial describe conversaciones guardadas que se eliminaban después de que los usuarios las reanudaran y salieran rápidamente antes de enviar otra indicación.
El colaborador identifica el seguimiento de sesiones reanudadas y la coordinación con la inicialización como parte de la corrección. La inicialización es el proceso de arranque que prepara los datos de trabajo de la aplicación.
El cambio también describe la comprobación de datos guardados cuando la memoria aún no contiene información fiable sobre la conversación. Estos mecanismos abordan la diferencia entre una sesión nueva vacía y una sesión existente que todavía se está cargando.
Un flujo de trabajo matutino hipotético hace concreta esa diferencia. Un desarrollador abre la conversación de ayer para comprobar su asunto, se da cuenta de que seleccionó la incorrecta y la cierra de inmediato.
Esa acción no debería implicar permiso para descartar el trabajo de ayer. Abrir y abandonar un registro es distinto de crear un registro vacío que nunca contuvo contenido útil.
La precisión importa de otra manera. Un desarrollador que retoma una investigación necesita distinguir las acciones propuestas, las acciones completadas y los resultados que dichas acciones produjeron.
Imaginemos una conversación que contiene una comprobación fallida seguida de una corrección satisfactoria. Si la recuperación distorsiona la relación entre solicitudes y resultados, la siguiente recomendación será más difícil de evaluar.
Esta es una consecuencia analítica de los registros poco fiables, no un resultado medido de la versión. El material disponible no cuantifica la calidad posterior de las respuestas ni el tiempo ahorrado.
No obstante, la lección para la evaluación es clara. Los equipos deben examinar las evidencias recuperadas, en lugar de juzgar la recuperación únicamente por si se abre la ventana de conversación.
También deben evitar tratar el historial de conversaciones como un registro de auditoría completo. Un intercambio guardado puede aportar contexto útil y, aun así, requerir confirmación frente a cambios de código y resultados reales de comandos.
Para Gemini CLI Release v0.65.0, estas correcciones hacen que la gestión de interrupciones sea un tema concreto de revisión. La pregunta relevante es si el trabajo conocido regresa intacto y sigue siendo comprensible.
La compatibilidad de autenticación requiere una validación precisa
Un requisito de autenticación puede rechazar conexiones legítimas cuando el cliente lo aplica de forma más amplia de lo que admiten las capacidades declaradas por el servidor.
OAuth, un marco de autorización, permite que las aplicaciones obtengan acceso sin recopilar directamente la contraseña de un usuario. Su respuesta de redirección puede incluir iss, un valor que identifica al servidor de autorización.
El cambio de validación del emisor hace obligatorio ese parámetro de respuesta solo cuando los metadatos del servidor declaran explícitamente que se admite. Los metadatos son información legible por máquinas que describe las capacidades del servidor.
Según el colaborador, Gemini CLI sigue validando el emisor siempre que la respuesta lo incluya. Por lo tanto, la corrección distingue entre un valor opcional ausente y un valor proporcionado que debe coincidir con lo esperado.
La solicitud de incorporación de cambios identifica la autenticación MCP de Notion como un ejemplo afectado. MCP, el Model Context Protocol, proporciona una forma común para que los asistentes se conecten con herramientas y datos externos.
Su autor describe fallos cuando un servidor publicaba un emisor, pero no declaraba que admitiera devolver el parámetro de emisor. Ese ejemplo explica el problema de compatibilidad sin establecer cuántos usuarios lo encontraron.
La lección para el producto es que un comportamiento más estricto necesita una definición precisa. Exigir más información no es automáticamente mejor cuando el protocolo aplicable trata esa información como opcional.
A la inversa, aceptar la ausencia de un campo opcional no implica aceptar un campo incorrecto. La presencia, la ausencia y la falta de coincidencia representan condiciones diferentes.
Esa distinción ofrece a los responsables de integraciones una mejor pregunta durante la revisión. ¿De qué capacidad del servidor depende el cliente y qué evidencia determina si una respuesta debe aceptarse?
Un fallo genérico de inicio de sesión oculta esos detalles. Deja al desarrollador preguntándose si el problema se refiere al acceso a la cuenta, la disponibilidad del servicio o supuestos de implementación incompatibles.
Una conexión exitosa también es solo una parte de la evaluación. Los equipos deben confirmar que la conexión llega al servicio esperado y concede el acceso previsto.
Estas son prioridades de revisión sugeridas. Las fuentes del lanzamiento no ofrecen una evaluación de seguridad independiente ni un estudio exhaustivo de compatibilidad entre servicios externos.
La conexión con la confianza del espacio de trabajo es conceptual, no mecánica. Ambos cambios dependen de traducir una condición declarada en el comportamiento correcto de la aplicación.
Para un espacio de trabajo, la condición declarada es si se confía en el proyecto. Para la autorización, es si el servidor anuncia una capacidad de respuesta concreta.
Los problemas surgen cuando el software trata una representación incompleta como una instrucción completa. Una configuración vacía puede convertirse en un reemplazo no intencionado. Una declaración de emisor puede convertirse en un requisito de devolución de llamada excesivamente amplio.
Esa comparación ayuda a explicar el lanzamiento sin combinar mecanismos no relacionados en una única afirmación técnica. Las correcciones operan en rutas de código separadas y requieren validación independiente.
Para los equipos que dependen de servicios conectados, la implicación inmediata es una evaluación específica. Un flujo de autorización que antes fallaba merece una nueva revisión, registrando su configuración de servicio y los permisos esperados.
Una afirmación más amplia de que la autenticación ahora es universalmente fiable excedería la evidencia. El cambio documentado respalda una conclusión más acotada y útil sobre una regla de validación específica.
La fiabilidad es una cuestión competitiva, sin clasificación
Los equipos que eligen un asistente de programación necesitan evidencia sobre interrupciones, permisos y recuperación, además de evidencia sobre el código generado.
La arquitectura de permisos de Anthropic ofrece un contexto competitivo relevante. Su documentación describe modos de permisos configurables y aislamiento del sistema de archivos y de la red mediante sandboxing.
El sandboxing consiste en restringir el acceso de un proceso a recursos fuera de límites definidos. Los controles de permisos determinan qué operaciones reciben aprobación con la configuración seleccionada.
Estas son funciones documentadas por el proveedor, no pruebas independientes de que Claude Code evite todas las acciones no deseadas. Establecen que los límites de ejecución son una parte explícita del diseño de un producto competidor.
La comparación es deliberadamente limitada. La corrección de la configuración del espacio de trabajo de Gemini CLI no se corresponde directamente con todos los ajustes de permisos de Claude Code.
Las fuentes tampoco establecen qué asistente tiene menos defectos, mejor recuperación o menor sobrecarga operativa. Esos juicios requerirían pruebas comparables entre versiones y entornos.
Una comparación justa expondría cada herramienta al mismo flujo de trabajo relevante. Eso incluye el proyecto que se inspecciona, las operaciones permitidas, los servicios conectados y la interrupción introducida.
El resultado debería incluir más que si una tarea se completó. Los revisores deben entender qué cambió, qué permaneció guardado y qué tuvo que resolver el operador posteriormente.
Esto desplaza la conversación de compra hacia un trabajo que el equipo puede observar. Una herramienta que produce un parche aceptable aún debe ajustarse a las expectativas de la organización sobre archivos locales y contexto conservado.
La presión es especialmente concreta para los responsables de ingeniería encargados de valores predeterminados compartidos. Su decisión afecta a colegas que quizá nunca lean una nota de lanzamiento ni revisen una discusión de implementación.
Esos responsables necesitan una explicación del comportamiento esperado que sobreviva a los traspasos. Un límite documentado ayuda al personal de soporte a distinguir la confusión del usuario de un problema del producto.
Los desarrolladores individuales enfrentan una versión menor de la misma responsabilidad. Deciden si confiar en un proyecto, retomar una investigación anterior o conectar otro servicio.
Un asistente predecible reduce la ambigüedad que rodea esas decisiones. Aquí, previsibilidad significa un comportamiento que coincide con una regla explícita y puede comprobarse después.
Sigue siendo necesaria una lectura escéptica de Gemini CLI Release v0.65.0. Las correcciones detalladas muestran que los mantenedores abordan problemas identificados; no establecen la ausencia de problemas relacionados.
Las descripciones de los colaboradores y las pruebas específicas son evidencia útil sobre intención y cobertura. No sustituyen la observación del paquete publicado en el entorno donde se utilizará.
Tampoco hay base aquí para atribuir un porcentaje de productividad a la actualización. Evitar una conversación perdida tiene un valor práctico evidente, pero no se ha medido su impacto agregado.
La conclusión apropiada es más limitada que un veredicto de mercado. Este lanzamiento ofrece a los usuarios de Gemini CLI cambios específicos de fiabilidad que evaluar y proporciona a las herramientas competidoras un estándar de comparación coherente.
Qué vigilar después de la actualización
La evidencia de seguimiento más sólida provendrá de un comportamiento reproducible, registros conservados y un manejo claro de las condiciones a las que se dirigen estas correcciones.
La primera señal que se debe vigilar es si la configuración del espacio de trabajo permanece intacta cuando se rechaza una operación restringida. Esto prueba directamente el límite descrito en la corrección de configuración.
Para una evaluación de equipo, una reproducción documentada debe capturar la configuración original, el estado de confianza, la operación intentada y el archivo resultante. Eso hace que el resultado sea revisable.
Si la operación se detiene limpiamente y conserva configuraciones no relacionadas, respalda el comportamiento previsto. Si la configuración sigue cambiando de forma inesperada, el alcance del problema necesita más investigación.
La segunda señal es si las conversaciones reanudadas siguen disponibles y coherentes tras las interrupciones. La disponibilidad y la coherencia deben considerarse por separado porque responden a preguntas diferentes.
Un registro guardado que sobrevive pero se reconstruye incorrectamente sigue generando incertidumbre. Un intercambio reconstruido a la perfección resulta igualmente poco útil si una salida rápida posterior elimina su historial guardado.
Por lo tanto, los informes de seguimiento útiles describirían tanto lo que permaneció en el disco como lo que apareció tras la recuperación. Una afirmación vaga de que reanudar “funcionó” deja sin explicar comportamientos importantes.
Si los flujos de trabajo relevantes permanecen estables, aumenta la confianza para adoptar el lanzamiento. Los fallos reproducibles relacionados con registros antiguos o salidas rápidas debilitarían esa evaluación.
La tercera señal es si los flujos de autorización externos afectados tienen éxito conforme a las capacidades del servidor que realmente anuncian. Esto mantiene la evaluación vinculada al problema de compatibilidad documentado.
Un resultado satisfactorio debe preservar el límite de acceso previsto y permitir una conexión compatible. El éxito logrado mediante un cambio de permisos no relacionado respondería a una pregunta diferente.
Los informes también deben distinguir la autenticación del comportamiento posterior de las herramientas. Conectarse a un servicio no establece que todas las operaciones expuestas por ese servicio funcionen correctamente.
En los próximos meses, las correcciones posteriores y los informes detallados de usuarios pueden ayudar a aclarar el alcance restante. Los informes más útiles identificarán versiones y condiciones, en lugar de ofrecer aprobación o crítica general.
Estos puntos de observación son criterios de evaluación propuestos, no hitos prometidos por Google. Su propósito es convertir un anuncio de lanzamiento en preguntas con respuestas observables.
También ayudan a los equipos a evitar reacciones excesivas en cualquier dirección. Un informe de defecto no establece un fallo universal, mientras que una demostración exitosa no establece una fiabilidad universal.
Para los usuarios existentes, la actualización es más relevante allí donde sus correcciones documentadas se superponen con el trabajo diario. Las investigaciones guardadas, la configuración del proyecto y los servicios conectados ofrecen lugares concretos para evaluarla.
Comience por el flujo de trabajo del que más depende su equipo y, después, registre lo que ocurre antes y después de adoptar Gemini CLI Release v0.65.0. Mantenga disponibles para la comparación la configuración del proyecto, los permisos esperados y la conversación guardada. Pida a un colega que revise el resultado sin depender de su recuerdo de la sesión. Si un límite detiene una operación, confirme que la explicación tenga sentido y que la información existente permanezca intacta. Si se reanuda una conversación, compare sus acciones registradas con el trabajo subyacente. Use esas observaciones para decidir si la actualización se ajusta a su entorno. ¿Qué interrupción sería más costosa de recuperar para su equipo y el paquete publicado la gestiona de forma predecible?
