Gemini CLI Release v0.65.0 corrige lacunas de confiabilidade em espaços de trabalho e sessões
A Gemini CLI Release v0.65.0, do Google, corrige falhas que podiam sobrescrever configurações de espaço de trabalho ou apagar o histórico de conversas retomadas. Publicada em 20 de outubro de 2026, a atualização também aborda respostas duplicadas de ferramentas, compatibilidade de autenticação e rolagem no terminal. Sua importância está no trabalho que envolve uma resposta de IA: preservar configurações, reconstruir ações anteriores e manter intacto o contexto de trabalho do desenvolvedor.
A tensão central é entre conveniência e gestão confiável de estado. Estado é a informação que um aplicativo retém sobre suas configurações, conversas e ações concluídas. Torna-se mais difícil confiar em um assistente de programação quando essas informações mudam de forma inesperada, mesmo que o código gerado pareça razoável. A versão coloca essas responsabilidades menos visíveis em evidência.
Claude Code oferece uma comparação útil porque sua documentação também trata permissões e limites de execução como preocupações explícitas do produto. No entanto, esta versão não estabelece um ranking competitivo. A pressão imediata recai sobre os mantenedores do Gemini CLI e as equipes que o adotam: as correções documentadas precisam se traduzir em comportamento previsível durante interrupções comuns.
O que a Gemini CLI Release v0.65.0 realmente muda
O tema mais claro da atualização é preservar o ambiente de trabalho do desenvolvedor durante alterações de configuração, recuperação de sessões e interações com a interface.
As alterações da versão publicadas identificam correções para configurações de espaços de trabalho não confiáveis, respostas duplicadas durante a recuperação de sessões e exclusão de histórico após uma saída rápida. Elas também incluem validação de autenticação e limpeza desnecessária do terminal ao expandir a saída com Ctrl+O.
Essas mudanças afetam diferentes partes do aplicativo. A configuração determina como um projeto se comporta. O histórico de conversas registra trabalhos anteriores. A autenticação conecta serviços externos. A saída do terminal ajuda a pessoa que supervisiona o assistente a entender o que aconteceu.
Para leitores que decidem se a versão importa, essa distribuição é mais informativa do que o número da versão por si só. Ela sugere uma atualização que vale avaliar em relação aos fluxos de trabalho existentes, especialmente aqueles que envolvem conversas salvas e configurações específicas do projeto.
As notas também contêm manutenção do changelog, uma atualização de versão nightly e uma correção no fluxo de trabalho do repositório. Esses itens pertencem às operações de lançamento. Não devem ser interpretados como melhorias separadas na inteligência de programação ou como evidência de novos recursos de modelo.
Um número de versão estável e uma string de versão nightly também descrevem coisas diferentes. O primeiro identifica o pacote publicado em discussão. A segunda aparece aqui como um item em seu histórico de desenvolvimento.
Essa distinção importa quando equipes registram decisões de atualização. Uma avaliação útil exige a versão instalada, o ambiente e o comportamento que está sendo verificado. Uma data de anúncio lembrada oferece muito menos ajuda ao reproduzir um problema posteriormente.
A mudança no terminal ilustra por que um trabalho de interface aparentemente menor pertence à mesma conversa. Expandir a saída é uma ação de inspeção. Ela deve ajudar desenvolvedores a revisar informações sem tornar mais difícil recuperar sua posição.
A interpretação mais ampla é simples: a utilidade de um assistente depende do aplicativo ao redor, assim como do modelo que responde aos prompts. Esta é uma avaliação editorial das mudanças, e não uma afirmação de que o Google anunciou uma nova direção estratégica.
Também há um limite prático para o que o anúncio estabelece. Uma entrada de versão documenta uma correção pretendida. Ela não mede a frequência da falha original entre os usuários.
Portanto, desenvolvedores têm motivos para inspecionar essas correções sem presumir que sua própria instalação apresentou todos os problemas listados. Equipes com fluxos de trabalho relevantes têm uma razão mais específica para avaliar a atualização do que leitores em busca de melhores pontuações de geração de código.
As mudanças mais consequentes merecem atenção separada porque seus modos de falha são diferentes. A proteção do espaço de trabalho diz respeito ao que o aplicativo tem permissão para gravar. A recuperação de sessões diz respeito a se o trabalho salvo anteriormente sobrevive e retorna com precisão.
A confiança no espaço de trabalho também deve governar gravações de configuração
Um limite de confiança é incompleto quando desativa configurações do projeto, mas ainda permite gravações destrutivas por meio do local de arquivo em que elas estão salvas.
Um espaço de trabalho é o diretório de projeto em que o assistente opera. A confiança no espaço de trabalho determina se o aplicativo trata a configuração local desse projeto como aprovada.
Segundo a correção das configurações de espaço de trabalho, um projeto não confiável recebia uma representação vazia da configuração na memória. Essa representação mantinha o local do arquivo de configurações e permanecia gravável.
Como consequência, um comando de configuração com escopo de espaço de trabalho poderia salvar a representação vazia sobre configurações existentes. A correção torna essa representação somente leitura e bloqueia as gravações afetadas antes que ocorram alterações de configuração.
O colaborador também descreve testes que cobrem mutações rejeitadas no nível do projeto e a preservação do arquivo existente. As configurações no escopo do usuário permanecem operacionais, enquanto estabelecer confiança restaura a capacidade normal de gravação no espaço de trabalho.
A distinção importante é entre ignorar uma configuração e preservá-la. Essas responsabilidades estão relacionadas, mas não são intercambiáveis. Um software pode recusar corretamente ativar um arquivo e ainda assim lidar incorretamente com esse arquivo em uma operação posterior.
Considere um desenvolvedor hipotético inspecionando um repositório desconhecido. Ele não aprovou sua configuração e tenta alterar uma definição de integração no nível do projeto. Sua expectativa razoável é uma recusa explícita ou uma decisão deliberada de confiança.
Substituir silenciosamente configurações não relacionadas violaria essa expectativa. O comando do desenvolvedor expressa uma intenção limitada, enquanto a alteração resultante no arquivo teria um efeito muito mais amplo.
Esse exemplo explica o que está em jogo sem afirmar que todo repositório desconhecido contém configuração prejudicial. A preocupação é o comportamento previsível do aplicativo sob condições restritas.
Um erro explícito introduz atrito, mas também identifica uma decisão que o desenvolvedor precisa tomar. Este projeto deve se tornar confiável? A alteração deve ser aplicada ao usuário? A configuração deve permanecer intocada?
Essas escolhas pertencem à pessoa que opera o assistente. Uma representação temporária vazia não deve respondê-las indiretamente por meio de uma substituição inesperada de arquivo.
Para equipes de plataforma, a implicação se estende ao desenho da avaliação. Uma ferramenta deve ser avaliada enquanto recusa uma operação, e não apenas enquanto conclui uma tarefa aprovada.
Uma recusa bem-sucedida tem propriedades observáveis. Os dados existentes permanecem intactos. O motivo é compreensível. O aplicativo não deixa para trás uma alteração de configuração parcialmente aplicada.
Estes são critérios de aceitação propostos, e não alegações adicionais sobre a versão. Eles oferecem às equipes uma forma concreta de interpretar a correção documentada em seu próprio ambiente.
O mesmo raciocínio se aplica à documentação interna. Um guia de implantação deve explicar a relação entre confiança no projeto e escopo de configuração, em vez de apenas instruir todos a aceitar um prompt.
As equipes que mantêm esse contexto podem registrar decisões em uma base de conhecimento pesquisável. Um registro útil explica por que existe um limite e de qual fluxo de trabalho ele depende.
Essa documentação não pode impor permissões. No entanto, ela pode ajudar revisores a distinguir uma recusa esperada de uma regressão quando o comportamento muda após uma atualização.
A recuperação de sessão apresenta problemas distintos de precisão e preservação
Uma conversa recuperada deve tanto sobreviver no disco quanto reconstruir a atividade anterior das ferramentas sem acrescentar respostas duplicadas.
A correção de reconstrução de sessão aborda respostas duplicadas de ferramentas quando conversas registradas são retomadas. Uma resposta de ferramenta é o resultado retornado depois que o assistente solicita uma operação externa.
Segundo o colaborador, a recuperação podia reproduzir uma resposta já registrada e também gerar outra resposta a partir dos resultados salvos de chamadas de ferramenta. A mudança verifica respostas existentes antes de gerar substituições.
Ela também filtra identificadores de resposta duplicados dentro de uma troca e mantém o comportamento de fallback para registros mais antigos. Os testes descritos cobrem registros modernos, formatos antigos, chamadas paralelas e filtragem de duplicatas.
Isso diz respeito à reconstrução, e não é evidência de que um comando externo necessariamente tenha sido executado duas vezes. Repetir uma resposta histórica no contexto do assistente é diferente de executar novamente a ação subjacente.
Essa distinção é essencial para interpretar a correção. Um registro de conversa impreciso pode gerar confusão sem provar que o aplicativo duplicou alterações no sistema de arquivos ou solicitações externas.
A preservação é uma questão separada. A correção de preservação de histórico descreve conversas salvas sendo excluídas depois que usuários as retomavam e saíam rapidamente antes de enviar outro prompt.
O colaborador identifica o rastreamento de sessões retomadas e a coordenação com a inicialização como partes da correção. Inicialização é o processo de inicialização que prepara os dados de trabalho do aplicativo.
A mudança também descreve a verificação de dados salvos quando a memória ainda não contém informações confiáveis sobre a conversa. Esses mecanismos abordam a diferença entre uma sessão nova e vazia e uma sessão existente que ainda está sendo carregada.
Um fluxo de trabalho hipotético pela manhã torna essa diferença concreta. Um desenvolvedor abre a conversa de ontem para verificar seu assunto, percebe que selecionou a errada e a fecha imediatamente.
Essa ação não deve implicar permissão para descartar o trabalho de ontem. Abrir e sair de um registro é diferente de criar um registro vazio que nunca conteve conteúdo útil.
A precisão importa de outra forma. Um desenvolvedor que retorna a uma investigação precisa distinguir ações propostas, ações concluídas e os resultados produzidos por essas ações.
Imagine uma conversa que contém uma verificação que falhou, seguida por uma correção bem-sucedida. Se a recuperação distorce a relação entre solicitações e resultados, a próxima recomendação se torna mais difícil de avaliar.
Esta é uma consequência analítica de registros não confiáveis, e não um resultado mensurado da versão. O material disponível não quantifica a qualidade posterior das respostas nem o tempo economizado.
Ainda assim, a lição para avaliação é clara. As equipes devem inspecionar as evidências recuperadas, em vez de julgar a recuperação apenas pelo fato de a janela da conversa abrir.
Elas também devem evitar tratar o histórico de conversas como um registro de auditoria completo. Uma troca salva pode fornecer contexto útil, mas ainda exige confirmação em relação às alterações de código e aos resultados reais dos comandos.
Para a Gemini CLI Release v0.65.0, essas correções tornam o tratamento de interrupções um tema concreto para revisão. A pergunta relevante é se um trabalho conhecido retorna intacto e continua compreensível.
A compatibilidade de autenticação exige validação precisa
Um requisito de autenticação pode rejeitar conexões legítimas quando o cliente o aplica de forma mais ampla do que as capacidades declaradas pelo servidor permitem.
OAuth, uma estrutura de autorização, permite que aplicativos obtenham acesso sem coletar diretamente a senha do usuário. Sua resposta de redirecionamento pode incluir iss, um valor que identifica o servidor de autorização.
A alteração na validação do emissor torna esse parâmetro de resposta obrigatório apenas quando os metadados do servidor declaram explicitamente suporte. Metadados são informações legíveis por máquina que descrevem as capacidades do servidor.
Segundo o colaborador, o Gemini CLI continua validando o emissor sempre que a resposta o inclui. A correção, portanto, distingue a ausência de um valor opcional de um valor fornecido que precisa corresponder às expectativas.
A pull request identifica a autenticação do Notion MCP como um exemplo afetado. MCP, o Model Context Protocol, oferece uma forma comum para assistentes se conectarem a ferramentas e dados externos.
Seu autor descreve falhas quando um servidor publicava um emissor, mas não declarava suporte para retornar o parâmetro de emissor. Esse exemplo explica o problema de compatibilidade sem estabelecer quantos usuários o encontraram.
A lição para o produto é que um comportamento mais rigoroso precisa de uma definição precisa. Exigir mais informações não é automaticamente melhor quando o protocolo aplicável trata essas informações como opcionais.
Por outro lado, aceitar a ausência de um campo opcional não implica aceitar um campo incorreto. Presença, ausência e incompatibilidade representam condições diferentes.
Essa distinção dá aos responsáveis por integrações uma pergunta melhor para fazer durante a revisão. De qual capacidade do servidor o cliente depende e quais evidências determinam se uma resposta deve ser aceita?
Uma falha genérica de login esconde esses detalhes. Ela deixa o desenvolvedor se perguntando se o problema envolve acesso à conta, disponibilidade do serviço ou suposições de implementação incompatíveis.
Uma conexão bem-sucedida também é apenas parte da avaliação. As equipes devem confirmar que a conexão chega ao serviço esperado e concede o acesso pretendido.
Estas são prioridades de revisão sugeridas. As fontes da versão não fornecem uma avaliação de segurança independente nem uma pesquisa abrangente de compatibilidade entre serviços externos.
A conexão com a confiança no espaço de trabalho é conceitual, e não mecânica. Ambas as mudanças dependem de traduzir uma condição declarada no comportamento correto do aplicativo.
Para um espaço de trabalho, a condição declarada é se o projeto é confiável. Para a autorização, é se o servidor anuncia uma capacidade específica de resposta.
Problemas surgem quando o software trata uma representação incompleta como uma instrução completa. Uma configuração vazia pode se tornar uma substituição não intencional. Uma declaração de emissor pode se tornar um requisito excessivamente amplo para o callback.
Essa comparação ajuda a explicar a versão sem combinar mecanismos não relacionados em uma única afirmação técnica. As correções operam em caminhos de código separados e exigem validação separada.
Para equipes que dependem de serviços conectados, a implicação imediata é uma avaliação direcionada. Um fluxo de autorização que antes falhava merece uma nova análise, com a configuração do serviço e as permissões esperadas registradas.
Uma afirmação mais ampla de que a autenticação agora é universalmente confiável iria além das evidências. A mudança documentada sustenta uma conclusão mais restrita e útil sobre uma regra específica de validação.
A Confiabilidade É Uma Questão Competitiva, Sem Um Ranking
As equipes que escolhem um assistente de programação precisam de evidências sobre interrupções, permissões e recuperação, além de evidências sobre o código gerado.
A arquitetura de permissões da Anthropic oferece um contexto competitivo relevante. Sua documentação descreve modos de permissão configuráveis e isolamento de sistema de arquivos e rede por meio de sandboxing.
Sandboxing significa restringir o acesso de um processo a recursos fora de limites definidos. Os controles de permissão determinam quais operações recebem aprovação sob a configuração selecionada.
Esses são recursos documentados pelo fornecedor, e não provas independentes de que Claude Code impede todas as ações indesejadas. Eles estabelecem que os limites de execução são uma parte explícita do design de um produto concorrente.
A comparação é deliberadamente limitada. A correção das configurações de espaço de trabalho do Gemini CLI não corresponde diretamente a todas as configurações de permissão do Claude Code.
As fontes também não estabelecem qual assistente tem menos defeitos, melhor recuperação ou menor sobrecarga operacional. Esses julgamentos exigiriam testes comparáveis entre versões e ambientes.
Uma comparação justa exporia cada ferramenta ao mesmo fluxo de trabalho relevante. Isso inclui o projeto sendo inspecionado, as operações permitidas, os serviços conectados e a interrupção introduzida.
O resultado deve incluir mais do que a conclusão de uma tarefa. Os revisores precisam entender o que mudou, o que permaneceu salvo e o que o operador precisou resolver depois.
Isso desloca a conversa de compra para um trabalho que a equipe pode observar. Uma ferramenta que produz um patch aceitável ainda precisa atender às expectativas da organização em relação a arquivos locais e contexto preservado.
A pressão é especialmente concreta para gerentes de engenharia responsáveis por padrões compartilhados. Sua decisão afeta colegas que talvez nunca leiam uma nota de versão ou inspecionem uma discussão de implementação.
Esses gerentes precisam de uma explicação do comportamento esperado que sobreviva às transferências de responsabilidade. Um limite documentado ajuda as equipes de suporte a distinguir a confusão do usuário de um problema no produto.
Desenvolvedores individuais enfrentam uma versão menor da mesma responsabilidade. Eles decidem se devem confiar em um projeto, retomar uma investigação antiga ou conectar outro serviço.
Um assistente previsível reduz a ambiguidade em torno dessas decisões. Previsibilidade, aqui, significa um comportamento que corresponde a uma regra explícita e pode ser verificado posteriormente.
A leitura cética do Gemini CLI Release v0.65.0 continua necessária. Correções detalhadas mostram que os mantenedores estão tratando problemas identificados; elas não estabelecem a ausência de problemas relacionados.
Descrições de colaboradores e testes direcionados são evidências úteis sobre intenção e cobertura. Elas não substituem a observação do pacote lançado no ambiente em que será utilizado.
Também não há base aqui para atribuir um percentual de produtividade à atualização. Evitar uma conversa perdida tem valor prático evidente, mas seu impacto agregado não foi medido.
A conclusão apropriada é mais restrita do que um veredito de mercado. Esta versão oferece aos usuários do Gemini CLI mudanças específicas de confiabilidade para avaliar e fornece às ferramentas concorrentes um padrão consistente de comparação.
O Que Observar Após a Atualização
As evidências de acompanhamento mais fortes virão de comportamentos reproduzíveis, registros preservados e tratamento claro das condições visadas por estas correções.
O primeiro sinal a observar é se a configuração do espaço de trabalho permanece intacta quando uma operação restrita é rejeitada. Isso testa diretamente o limite descrito na correção das configurações.
Para uma avaliação em equipe, uma reprodução documentada deve registrar a configuração original, o estado de confiança, a operação tentada e o arquivo resultante. Isso torna o resultado revisável.
Se a operação for interrompida de forma limpa e preservar configurações não relacionadas, isso sustenta o comportamento pretendido. Se a configuração ainda mudar de forma inesperada, o escopo do problema precisa de investigação adicional.
O segundo sinal é se as conversas retomadas permanecem disponíveis e coerentes após interrupções. Disponibilidade e coerência devem ser consideradas separadamente porque respondem a perguntas diferentes.
Um registro salvo que sobrevive, mas é reconstruído incorretamente, ainda cria incerteza. Uma troca perfeitamente reconstruída é igualmente inútil se uma saída rápida posterior remove seu histórico salvo.
Relatos úteis de acompanhamento, portanto, descreveriam tanto o que permaneceu no disco quanto o que apareceu após a recuperação. Uma declaração vaga de que a retomada “funcionou” deixa comportamentos importantes sem explicação.
Se os fluxos de trabalho relevantes permanecerem estáveis, a confiança na adoção da versão aumenta. Falhas reproduzíveis envolvendo registros antigos ou saídas rápidas enfraqueceriam essa avaliação.
O terceiro sinal é se os fluxos de autorização externos afetados têm êxito sob as capacidades de servidor que realmente anunciam. Isso mantém a avaliação vinculada ao problema de compatibilidade documentado.
Um resultado aprovado deve preservar o limite de acesso pretendido e, ao mesmo tempo, permitir uma conexão compatível. Um sucesso obtido por meio de uma alteração de permissão não relacionada responderia a uma pergunta diferente.
Os relatos também devem distinguir a autenticação do comportamento posterior da ferramenta. Conectar-se a um serviço não estabelece que todas as operações expostas por esse serviço funcionam corretamente.
Nos próximos meses, correções subsequentes e relatos detalhados de usuários podem ajudar a esclarecer o escopo restante. Os relatos mais úteis identificarão versões e condições, em vez de oferecer aprovação ou crítica ampla.
Estes pontos de observação são critérios de avaliação propostos, e não marcos prometidos pelo Google. Seu propósito é transformar um anúncio de versão em perguntas com respostas observáveis.
Eles também ajudam as equipes a evitar reações exageradas em qualquer direção. Um relato de defeito não estabelece falha universal, enquanto uma demonstração bem-sucedida não estabelece confiabilidade universal.
Para usuários existentes, a atualização é mais relevante onde suas correções documentadas se sobrepõem ao trabalho diário. Investigações salvas, configuração do projeto e serviços conectados oferecem lugares concretos para avaliá-la.
Comece pelo fluxo de trabalho de que sua equipe mais depende e registre o que acontece antes e depois de adotar o Gemini CLI Release v0.65.0. Mantenha a configuração do projeto, as permissões esperadas e a conversa salva disponíveis para comparação. Peça a um colega que revise o resultado sem depender da sua lembrança da sessão. Se um limite interromper uma operação, confirme que a explicação faz sentido e que as informações existentes permanecem intactas. Se uma conversa for retomada, compare suas ações registradas com o trabalho subjacente. Use essas observações para decidir se a atualização se adapta ao seu ambiente. Qual interrupção seria mais cara para sua equipe recuperar e o pacote lançado a trata de maneira previsível?
