Gemini CLI Release v0.65.0 corregge lacune di affidabilità di workspace e sessioni
Gemini CLI Release v0.65.0 di Google risolve problemi che potevano sovrascrivere le impostazioni del workspace o eliminare la cronologia delle conversazioni riprese. Pubblicato il 20 ottobre 2026, l'aggiornamento interviene anche su risposte duplicate degli strumenti, compatibilità dell'autenticazione e scorrimento del terminale. La sua rilevanza risiede nel lavoro che circonda una risposta dell'IA: preservare la configurazione, ricostruire le azioni precedenti e mantenere intatto il contesto di lavoro di uno sviluppatore.
La tensione centrale è tra comodità e gestione affidabile dello stato. Per stato si intendono le informazioni che un'applicazione conserva sulla propria configurazione, sulle conversazioni e sulle azioni completate. Un assistente di coding diventa più difficile da considerare affidabile quando tali informazioni cambiano inaspettatamente, anche se il codice generato sembra ragionevole. Questa release mette in evidenza tali responsabilità meno visibili.
Claude Code offre un confronto utile perché anche la sua documentazione tratta autorizzazioni e limiti di esecuzione come aspetti espliciti del prodotto. Tuttavia, questa release non stabilisce una classifica competitiva. La pressione immediata ricade sui manutentori di Gemini CLI e sui team che lo adottano: le correzioni documentate devono tradursi in comportamenti prevedibili durante le normali interruzioni.
Cosa cambia davvero con Gemini CLI Release v0.65.0
Il tema più chiaro dell'aggiornamento è la preservazione dell'ambiente di lavoro dello sviluppatore tra modifiche di configurazione, recupero delle sessioni e interazioni con l'interfaccia.
Le modifiche della release pubblicate identificano correzioni per impostazioni di workspace non attendibili, risposte duplicate durante il recupero delle sessioni e cancellazione della cronologia dopo un'uscita rapida. Includono inoltre la convalida dell'autenticazione e l'inutile cancellazione del terminale durante l'espansione dell'output con Ctrl+O.
Questi cambiamenti riguardano parti diverse dell'applicazione. La configurazione determina il comportamento di un progetto. La cronologia delle conversazioni registra il lavoro precedente. L'autenticazione collega servizi esterni. L'output del terminale aiuta chi supervisiona l'assistente a capire cosa è accaduto.
Per i lettori che devono decidere se la release sia rilevante, questa distribuzione è più informativa del solo numero di versione. Suggerisce un aggiornamento da valutare rispetto ai flussi di lavoro esistenti, specialmente quelli che coinvolgono conversazioni salvate e impostazioni specifiche del progetto.
Le note includono anche manutenzione del changelog, un incremento della versione nightly e una correzione del workflow del repository. Queste voci appartengono alle operazioni di release. Non dovrebbero essere interpretate come miglioramenti separati dell'intelligenza di coding o come prova di nuove capacità del modello.
Un numero di release stabile e una stringa di versione nightly descrivono inoltre elementi diversi. Il primo identifica il pacchetto pubblicato in esame. La seconda compare qui come voce della sua cronologia di sviluppo.
Questa distinzione è importante quando i team registrano decisioni di aggiornamento. Una valutazione utile richiede la versione installata, l'ambiente e il comportamento verificato. Una data di annuncio ricordata offre molta meno utilità quando si deve riprodurre un problema in seguito.
La modifica al terminale illustra perché un lavoro sull'interfaccia apparentemente minore rientri nella stessa discussione. Espandere l'output è un'azione di ispezione. Dovrebbe aiutare gli sviluppatori a rivedere le informazioni senza rendere più difficile ritrovare la propria posizione.
L'interpretazione più ampia è semplice: l'utilità di un assistente dipende dall'applicazione circostante oltre che dal modello che risponde ai prompt. Questa è una valutazione editoriale delle modifiche, non l'affermazione che Google abbia annunciato una nuova direzione strategica.
Esiste anche un limite pratico a ciò che l'annuncio stabilisce. Una voce di release documenta una correzione prevista. Non misura la frequenza del problema originale tra gli utenti.
Gli sviluppatori hanno quindi motivo di esaminare queste correzioni senza presumere che la propria installazione abbia riscontrato tutti i problemi elencati. I team con flussi di lavoro pertinenti hanno una ragione più specifica per valutare l'aggiornamento rispetto ai lettori in cerca di migliori punteggi nella generazione di codice.
Le modifiche più rilevanti meritano attenzione separata, perché le loro modalità di errore differiscono. La protezione del workspace riguarda ciò che l'applicazione è autorizzata a scrivere. Il recupero della sessione riguarda se il lavoro salvato in precedenza sopravvive e viene ripristinato correttamente.
La fiducia nel workspace deve governare anche le scritture di configurazione
Un confine di fiducia è incompleto quando disabilita le impostazioni del progetto ma consente comunque scritture distruttive attraverso il percorso del file in cui sono salvate.
Un workspace è la directory di progetto in cui opera l'assistente. La fiducia nel workspace determina se l'applicazione considera approvata la configurazione locale di quel progetto.
Secondo la correzione delle impostazioni del workspace, un progetto non attendibile riceveva in memoria una rappresentazione vuota della configurazione. Tale rappresentazione conservava la posizione del file delle impostazioni e rimaneva scrivibile.
Un comando di configurazione con ambito workspace poteva quindi salvare la rappresentazione vuota sopra le impostazioni esistenti. La correzione rende quella rappresentazione di sola lettura e blocca le scritture interessate prima che avvengano modifiche alla configurazione.
Il contributore descrive inoltre test che coprono il rifiuto delle modifiche a livello di progetto e la preservazione del file esistente. Le impostazioni a livello utente restano operative, mentre l'instaurazione della fiducia ripristina la normale scrivibilità del workspace.
La distinzione importante è tra ignorare la configurazione e preservarla. Queste responsabilità sono correlate, ma non intercambiabili. Un software può correttamente rifiutare di attivare un file e al tempo stesso gestirlo male durante un'operazione successiva.
Si consideri uno sviluppatore ipotetico che ispeziona un repository non familiare. Non ha approvato la sua configurazione e tenta di modificare un'impostazione di integrazione a livello di progetto. La sua ragionevole aspettativa è un rifiuto esplicito o una decisione deliberata di fiducia.
La sostituzione silenziosa di impostazioni non correlate violerebbe tale aspettativa. Il comando dello sviluppatore esprime un'intenzione limitata, mentre la modifica risultante al file avrebbe un effetto molto più ampio.
Questo esempio spiega la posta in gioco senza affermare che ogni repository non familiare contenga configurazioni dannose. La preoccupazione è un comportamento prevedibile dell'applicazione in condizioni ristrette.
Un errore esplicito introduce attrito, ma identifica anche una decisione che lo sviluppatore deve prendere. Questo progetto dovrebbe diventare attendibile? La modifica dovrebbe applicarsi invece all'utente? La configurazione dovrebbe restare invariata?
Queste scelte spettano alla persona che utilizza l'assistente. Una rappresentazione temporanea vuota non dovrebbe rispondervi indirettamente attraverso una sovrascrittura inattesa del file.
Per i team che gestiscono piattaforme, l'implicazione si estende alla progettazione della valutazione. Uno strumento dovrebbe essere valutato anche mentre rifiuta un'operazione, non solo mentre completa un'attività approvata.
Un rifiuto riuscito ha proprietà osservabili. I dati esistenti restano intatti. Il motivo è comprensibile. L'applicazione non lascia dietro di sé una modifica di configurazione applicata solo in parte.
Questi sono criteri di accettazione proposti, non ulteriori affermazioni sulla release. Offrono ai team un modo concreto per interpretare la correzione documentata nel proprio ambiente.
Lo stesso ragionamento si applica alla documentazione interna. Una guida alla distribuzione dovrebbe spiegare il rapporto tra fiducia nel progetto e ambito della configurazione, anziché limitarsi a istruire tutti ad accettare un prompt.
I team che mantengono questo contesto possono conservare le decisioni in una base di conoscenza ricercabile. Una registrazione utile spiega perché esiste un confine e quale flusso di lavoro dipende da esso.
Tale documentazione non può applicare autorizzazioni. Può tuttavia aiutare i revisori a distinguere un rifiuto previsto da una regressione quando il comportamento cambia dopo un aggiornamento.
Il recupero delle sessioni presenta problemi distinti di accuratezza e conservazione
Una conversazione recuperata deve sia sopravvivere su disco sia ricostruire l'attività precedente degli strumenti senza aggiungere risposte duplicate.
La correzione della ricostruzione della sessione affronta le risposte duplicate degli strumenti quando vengono riprese conversazioni registrate. Una risposta di uno strumento è il risultato restituito dopo che l'assistente richiede un'operazione esterna.
Secondo il contributore, il recupero poteva riprodurre una risposta già registrata generandone al contempo un'altra dai risultati salvati delle chiamate agli strumenti. La modifica verifica la presenza di risposte esistenti prima di generarne di sostitutive.
Filtra inoltre gli identificatori di risposta duplicati all'interno di uno scambio e mantiene un comportamento di fallback per le registrazioni meno recenti. I test descritti coprono registrazioni moderne, formati precedenti, chiamate parallele e filtraggio dei duplicati.
Si tratta di ricostruzione, non della prova che un comando esterno sia necessariamente stato eseguito due volte. Ripetere una risposta storica nel contesto dell'assistente è diverso dall'eseguire nuovamente l'azione sottostante.
Questa distinzione è essenziale per interpretare la correzione. Una registrazione imprecisa della conversazione può creare confusione senza dimostrare che l'applicazione abbia duplicato modifiche al filesystem o richieste esterne.
La conservazione è una questione separata. La correzione della conservazione della cronologia descrive conversazioni salvate cancellate dopo che gli utenti le avevano riprese e chiuse rapidamente prima di inviare un altro prompt.
Il contributore identifica il tracciamento delle sessioni riprese e il coordinamento con l'inizializzazione come parte della correzione. L'inizializzazione è il processo di avvio che prepara i dati di lavoro dell'applicazione.
La modifica descrive anche il controllo dei dati salvati quando la memoria non contiene ancora informazioni affidabili sulla conversazione. Questi meccanismi affrontano la differenza tra una nuova sessione vuota e una sessione esistente ancora in fase di caricamento.
Un ipotetico flusso di lavoro mattutino rende concreta questa differenza. Uno sviluppatore apre la conversazione di ieri per controllarne l'argomento, si rende conto di aver selezionato quella sbagliata e la chiude immediatamente.
Quell'azione non dovrebbe implicare l'autorizzazione a scartare il lavoro di ieri. Aprire e abbandonare una registrazione è diverso dal creare una registrazione vuota che non ha mai contenuto contenuti utili.
L'accuratezza conta anche in un altro modo. Uno sviluppatore che torna a un'indagine deve distinguere tra azioni proposte, azioni completate e risultati prodotti da tali azioni.
Si immagini una conversazione che contiene un controllo fallito seguito da una correzione riuscita. Se il recupero distorce la relazione tra richieste e risultati, la raccomandazione successiva diventa più difficile da valutare.
Questa è una conseguenza analitica di registrazioni inaffidabili, non un risultato misurato della release. Il materiale disponibile non quantifica la qualità delle risposte a valle né il tempo risparmiato.
Ciononostante, la lezione per la valutazione è chiara. I team dovrebbero ispezionare le evidenze recuperate, anziché giudicare il recupero soltanto in base all'apertura della finestra di conversazione.
Dovrebbero inoltre evitare di trattare la cronologia delle conversazioni come una registrazione di audit completa. Uno scambio salvato può offrire contesto utile, pur richiedendo ancora conferma rispetto alle modifiche del codice e ai risultati effettivi dei comandi.
Per Gemini CLI Release v0.65.0, queste correzioni rendono la gestione delle interruzioni un argomento concreto da esaminare. La domanda pertinente è se il lavoro familiare ritorni intatto e resti comprensibile.
La compatibilità dell'autenticazione richiede una convalida precisa
Un requisito di autenticazione può rifiutare connessioni legittime quando il client lo applica più ampiamente di quanto supportato dalle capacità dichiarate del server.
OAuth, un framework di autorizzazione, consente alle applicazioni di ottenere accesso senza raccogliere direttamente la password dell'utente. La sua risposta di reindirizzamento può includere iss, un valore che identifica il server di autorizzazione.
La modifica alla convalida dell'emittente rende obbligatorio quel parametro di risposta solo quando i metadati del server dichiarano esplicitamente il supporto. I metadati sono informazioni leggibili dalle macchine che descrivono le capacità del server.
Secondo il contributore, Gemini CLI continua a convalidare l'emittente ogni volta che la risposta lo include. La correzione distingue quindi tra un valore opzionale mancante e un valore fornito che deve corrispondere alle aspettative.
La pull request indica l'autenticazione Notion MCP come esempio interessato. MCP, il Model Context Protocol, offre un metodo comune agli assistenti per connettersi a strumenti e dati esterni.
Il suo autore descrive malfunzionamenti quando un server pubblicava un emittente senza dichiarare il supporto alla restituzione del parametro dell'emittente. L'esempio chiarisce il problema di compatibilità senza stabilire quanti utenti lo abbiano riscontrato.
La lezione per il prodotto è che un comportamento più rigoroso necessita di una definizione precisa. Richiedere più informazioni non è automaticamente meglio quando il protocollo applicabile considera tali informazioni facoltative.
Al contrario, accettare un campo opzionale assente non implica accettare un campo errato. Presenza, assenza e mancata corrispondenza rappresentano condizioni diverse.
Questa distinzione offre ai responsabili delle integrazioni una domanda migliore da porsi durante la revisione. Su quale capacità del server fa affidamento il client e quali elementi determinano se una risposta debba essere accettata?
Un errore generico di accesso nasconde questi dettagli. Lascia lo sviluppatore a chiedersi se il problema riguardi l'accesso all'account, la disponibilità del servizio o ipotesi di implementazione incompatibili.
Anche una connessione riuscita è solo una parte della valutazione. I team dovrebbero confermare che la connessione raggiunga il servizio previsto e conceda l'accesso desiderato.
Queste sono priorità di revisione suggerite. Le fonti della release non forniscono una valutazione di sicurezza indipendente né un'indagine completa sulla compatibilità tra servizi esterni.
Il collegamento con l'affidabilità dell'area di lavoro è concettuale, non meccanico. Entrambe le modifiche dipendono dalla traduzione di una condizione dichiarata nel comportamento applicativo corretto.
Per un'area di lavoro, la condizione dichiarata è se il progetto sia attendibile. Per l'autorizzazione, è se il server pubblicizzi una particolare capacità di risposta.
I problemi sorgono quando il software tratta una rappresentazione incompleta come un'istruzione completa. Una configurazione vuota può diventare una sostituzione non intenzionale. Una dichiarazione dell'emittente può diventare un requisito di callback eccessivamente ampio.
Questo confronto aiuta a spiegare la release senza fondere meccanismi non correlati in un'unica affermazione tecnica. Le correzioni operano in percorsi di codice separati e richiedono convalide distinte.
Per i team che dipendono da servizi connessi, l'implicazione immediata è una valutazione mirata. Un flusso di autorizzazione che in precedenza non riusciva merita un nuovo esame, registrando la configurazione del servizio e le autorizzazioni previste.
Una dichiarazione più ampia secondo cui l'autenticazione è ora universalmente affidabile andrebbe oltre le prove disponibili. La modifica documentata supporta una conclusione più circoscritta e utile su una regola di convalida specifica.
L'affidabilità è una questione competitiva, senza una classifica
I team che scelgono un assistente di coding hanno bisogno di prove su interruzioni, autorizzazioni e ripristino, oltre alle prove sul codice generato.
L'architettura delle autorizzazioni di Anthropic offre un contesto competitivo rilevante. La documentazione descrive modalità di autorizzazione configurabili e isolamento del filesystem e della rete tramite sandboxing.
Il sandboxing consiste nel limitare l'accesso di un processo a risorse esterne ai confini definiti. I controlli delle autorizzazioni determinano quali operazioni ricevono approvazione nella configurazione selezionata.
Si tratta di funzionalità documentate dal fornitore, non di prove indipendenti che Claude Code impedisca ogni azione indesiderata. Esse stabiliscono che i confini di esecuzione sono una componente esplicita della progettazione di un prodotto concorrente.
Il confronto è volutamente limitato. La correzione delle impostazioni dell'area di lavoro di Gemini CLI non corrisponde direttamente a ogni impostazione di autorizzazione di Claude Code.
Le fonti non stabiliscono neppure quale assistente presenti meno difetti, un recupero migliore o minori costi operativi. Tali giudizi richiederebbero test comparabili tra versioni e ambienti.
Un confronto equo sottoporrebbe ogni strumento allo stesso flusso di lavoro pertinente. Ciò include il progetto esaminato, le operazioni consentite, i servizi connessi e l'interruzione introdotta.
L'output dovrebbe includere più del semplice completamento di un'attività. I revisori devono comprendere che cosa è cambiato, che cosa è rimasto salvato e che cosa l'operatore ha dovuto risolvere in seguito.
Questo sposta la conversazione d'acquisto verso un lavoro che un team può osservare. Uno strumento che produce una patch accettabile deve comunque adattarsi alle aspettative dell'organizzazione riguardo ai file locali e al contesto conservato.
La pressione è particolarmente concreta per i responsabili dell'ingegneria incaricati delle impostazioni predefinite condivise. La loro decisione influenza colleghi che potrebbero non leggere mai una nota di rilascio né esaminare una discussione sull'implementazione.
Questi responsabili hanno bisogno di una spiegazione del comportamento previsto che resista ai passaggi di consegne. Un confine documentato aiuta il personale di supporto a distinguere la confusione dell'utente da un problema del prodotto.
I singoli sviluppatori affrontano una versione più ridotta della stessa responsabilità. Decidono se fidarsi di un progetto, riprendere una vecchia indagine o collegare un altro servizio.
Un assistente prevedibile riduce l'ambiguità che circonda tali decisioni. Prevedibilità, in questo caso, significa un comportamento conforme a una regola esplicita e verificabile in seguito.
Resta necessaria una lettura scettica di Gemini CLI Release v0.65.0. Correzioni dettagliate mostrano che i manutentori affrontano problemi identificati; non dimostrano l'assenza di problemi correlati.
Le descrizioni dei contributori e i test mirati sono prove utili di intenzione e copertura. Non sostituiscono l'osservazione del pacchetto rilasciato nell'ambiente in cui verrà utilizzato.
Non vi è inoltre alcuna base per attribuire all'aggiornamento una percentuale di produttività. Evitare la perdita di una conversazione ha un evidente valore pratico, ma il suo impatto aggregato non è stato misurato.
La conclusione appropriata è più circoscritta di un verdetto di mercato. Questa release offre agli utenti di Gemini CLI modifiche specifiche di affidabilità da valutare e fornisce agli strumenti concorrenti uno standard coerente di confronto.
Cosa osservare dopo l'aggiornamento
Le prove successive più solide deriveranno da comportamenti riproducibili, registri conservati e una gestione chiara delle condizioni a cui mirano queste correzioni.
Il primo segnale da osservare è se la configurazione dell'area di lavoro rimanga intatta quando viene rifiutata un'operazione soggetta a restrizioni. Questo verifica direttamente il confine descritto nella correzione delle impostazioni.
Per una valutazione di team, una riproduzione documentata dovrebbe acquisire la configurazione originale, lo stato di attendibilità, l'operazione tentata e il file risultante. Ciò rende il risultato verificabile.
Se l'operazione si interrompe in modo pulito e preserva impostazioni non correlate, supporta il comportamento previsto. Se la configurazione continua a cambiare inaspettatamente, l'ambito del problema richiede ulteriori indagini.
Il secondo segnale è se le conversazioni riprese restino disponibili e coerenti attraverso le interruzioni. Disponibilità e coerenza dovrebbero essere considerate separatamente perché rispondono a domande diverse.
Un record salvato che sopravvive ma viene ricostruito in modo errato crea comunque incertezza. Uno scambio ricostruito perfettamente è altrettanto inutile se una successiva uscita rapida elimina la cronologia salvata.
I report successivi utili dovrebbero quindi descrivere sia ciò che è rimasto sul disco sia ciò che è apparso dopo il recupero. Un'affermazione vaga secondo cui la ripresa ha “funzionato” lascia inspiegati comportamenti importanti.
Se i flussi di lavoro pertinenti rimangono stabili, aumenta la fiducia nell'adozione della release. Errori riproducibili che coinvolgono registrazioni precedenti o uscite rapide indebolirebbero tale valutazione.
Il terzo segnale è se i flussi di autorizzazione esterni interessati riescano in base alle capacità del server che effettivamente pubblicizzano. Questo mantiene la valutazione legata al problema di compatibilità documentato.
Un risultato positivo dovrebbe preservare il confine di accesso previsto consentendo al contempo una connessione supportata. Un successo ottenuto tramite una modifica non correlata delle autorizzazioni risponderebbe a una domanda diversa.
I report dovrebbero anche distinguere l'autenticazione dal comportamento successivo degli strumenti. Connettersi a un servizio non dimostra che ogni operazione esposta da quel servizio funzioni correttamente.
Nei prossimi mesi, correzioni successive e report dettagliati degli utenti potranno aiutare a chiarire l'ambito rimanente. I report più utili identificheranno versioni e condizioni invece di offrire approvazioni o critiche generiche.
Questi punti di osservazione sono criteri di valutazione proposti, non traguardi promessi da Google. Il loro scopo è trasformare un annuncio di release in domande con risposte osservabili.
Aiutano inoltre i team a evitare reazioni eccessive in entrambe le direzioni. Un report di difetto non dimostra un malfunzionamento universale, mentre una dimostrazione riuscita non dimostra un'affidabilità universale.
Per gli utenti esistenti, l'aggiornamento è più rilevante laddove le correzioni documentate si sovrappongono al lavoro quotidiano. Indagini salvate, configurazione del progetto e servizi connessi offrono punti concreti per valutarlo.
Iniziate dal flusso di lavoro da cui il vostro team dipende maggiormente, quindi registrate ciò che accade prima e dopo l'adozione di Gemini CLI Release v0.65.0. Tenete disponibili per il confronto la configurazione del progetto, le autorizzazioni previste e la conversazione salvata. Chiedete a un collega di riesaminare il risultato senza affidarsi al vostro ricordo della sessione. Se un confine interrompe un'operazione, confermate che la spiegazione sia sensata e che le informazioni esistenti rimangano intatte. Se una conversazione riprende, confrontate le sue azioni registrate con il lavoro sottostante. Usate queste osservazioni per decidere se l'aggiornamento si adatta al vostro ambiente. Quale interruzione sarebbe più costosa da recuperare per il vostro team e il pacchetto rilasciato la gestisce in modo prevedibile?
