Gemini CLI "File device or inode changed during read" no Windows: como resolver

Você abriu o Gemini CLI no Windows, pediu para ele ler um arquivo, e o read_file devolveu File device or inode changed during read. Não importa o arquivo: até um hello.txt de duas linhas falha. O arquivo não mudou. Quem está errado é o Node instalado na sua máquina, e o Gemini CLI passou a notar isso na versão 0.63.0.

Este guia mostra de onde vem o erro, como confirmar em um comando e as três formas de destravar enquanto a correção oficial não sai. Tudo foi conferido no código-fonte e nos releases do google-gemini/gemini-cli, no ChangeLog da libuv e no índice oficial de versões do Node em 25/10/2026.

O que significa "File device or inode changed during read"?

Significa que o Gemini CLI comparou a identidade do arquivo (número do volume e número do arquivo) antes e durante a leitura, e os dois valores não bateram. Ele interpreta isso como troca do arquivo no meio da leitura e se recusa a continuar:

Error reading file hello.txt: File device or inode changed during read: C:\Users\...\hello.txt

O erro aparece no read_file, no read_many_files, nas referências com @arquivo e no carregamento de skills, segundo a issue #29898, aberta em 23/10/2026. Na prática, o agente fica sem conseguir ler nada do projeto.

Por que isso acontece só no Windows?

Porque algumas versões do Node no Windows devolvem o número do volume errado em uma das duas consultas. A função readSecureFileBuffer, em packages/core/src/utils/fileUtils.ts, pega o dev e o ino do arquivo pelo caminho e depois pelo arquivo aberto, e exige que sejam iguais:

(initialStats.dev !== handleStats.dev ||
  initialStats.ino !== handleStats.ino)

Nas versões do Node que usam a libuv de 1.49.1 a 1.50.0, a consulta pelo caminho devolve dev: 0 no Windows, enquanto a consulta pelo arquivo aberto devolve o número real do volume. O ino bate, o dev não, e todo arquivo é recusado. A libuv 1.49.0 trocou o stat do Windows por uma API nova e rápida ("win,fs: use the new Windows fast stat API"), e a 1.51.0 trouxe "win: fix the inconsistency in volume serial number". Linux e macOS não passam por esse código.

Node	libuv	Resultado no Windows
20.20.2	1.46.0	Funciona (testado na issue)
22.12.0 a 22.16.0	1.49.1 a 1.49.2	Falha (22.12.0, 22.14.0 e 22.16.0 testados na issue)
23.1.0 a 23.11.x	1.49.1 a 1.50.0	Falha (23.11.0 testado na issue)
24.0.0 a 24.1.0	1.50.0	Mesma libuv das versões que falham, não testado na issue
22.17.0 em diante, 24.2.0 em diante	1.51.0 ou mais nova	Funciona (22.18.0, 22.20.0 e 22.23.3 testados na issue)

Fonte da coluna libuv: índice oficial em nodejs.org/dist/index.json, consultado em 25/10/2026.

Por que só agora, se o Node é antigo?

Porque a checagem é nova. Ela entrou pelo PR #29506, incorporado em 25/09/2026, e chegou na versão estável 0.63.0. O CI do projeto roda os testes de Windows no Node 20, que não tem o problema, enquanto o package.json aceita qualquer Node a partir do 20.

Gemini CLI	Tem a checagem?	Publicada
0.62.0	Não	29/09/2026
0.63.0 e 0.64.0	Sim	06/10 e 13/10/2026
0.65.0 (estável, tag latest)	Sim	20/10/2026
Nightly 0.67.0 de 25/10	Sim, sem correção	25/10/2026

Como confirmar que é esse o problema?

Veja a versão do Gemini CLI e a do Node, com a libuv. Funciona no PowerShell e no Prompt de Comando:

gemini --version
node -p "process.version + ' libuv ' + process.versions.uv"

Se o Gemini CLI é 0.63.0 ou mais novo e a libuv está entre 1.49.1 e 1.50.0, é este bug. Para ver a divergência com os próprios olhos, rode na pasta do projeto, trocando package.json por qualquer arquivo que exista ali:

node -e "const fs=require('fs');const fd=fs.openSync('package.json','r');console.log(fs.statSync('package.json').dev, fs.fstatSync(fd).dev)"

Pelo diagnóstico da issue, no Node afetado o primeiro número sai 0 e o segundo não. Num Node sem o problema, os dois são iguais.

Como resolver o "File device or inode changed during read"?

Atualize o Node para uma versão com libuv 1.51.0 ou mais nova: o 24 LTS ou o 22.18.0 em diante. É a correção de raiz e não exige mexer no Gemini CLI.

Com o winget, o pacote LTS instala hoje o Node 24.22.1:

winget install OpenJS.NodeJS.LTS

Se você usa o nvm-windows:

nvm install 24.22.1
nvm use 24.22.1

Depois, abra um terminal novo, reinstale o Gemini CLI e confira:

npm install -g @google/gemini-cli
node -p "process.versions.uv"
gemini --version

A reinstalação importa no nvm-windows: cada versão do Node tem a própria pasta de pacotes globais, e o gemini antigo fica preso no Node anterior.

O Node não pode mudar: volte para a 0.62.0

Se outro projeto prende a máquina no Node 22.14, por exemplo, volte o Gemini CLI para antes da checagem.

1. Desligue a atualização automática no ~/.gemini/settings.json, senão ele volta sozinho para a 0.65.0:

   {
     "general": {
       "enableAutoUpdate": false
     }
   }

2. Instale a versão anterior:

   npm install -g @google/gemini-cli@0.62.0

3. Quando a correção sair numa versão estável, religue o enableAutoUpdate e atualize.

O custo é ficar sem tudo o que entrou da 0.63.0 à 0.65.0. Se você roda com --yolo, a 0.62.0 tem uma vantagem: ainda não tem o aviso Untrusted Command Flags Detected, que explicamos neste guia.

Terceira saída: rode o Gemini CLI no WSL

O bug está no caminho de código do Windows. Dentro do WSL, o Gemini CLI roda no Linux e a checagem compara valores coerentes:

wsl
npm install -g @google/gemini-cli

O Node do WSL é outro, instalado dentro da distribuição, e não tem o problema do dev: 0. Vale usar o 24 LTS lá dentro também.

Dá para desligar a checagem?

Não por configuração, e não vale a pena por gambiarra. O comentário no código diz que a função confere dev e ino antes, durante e depois da leitura para garantir que o arquivo lido é o mesmo do começo ao fim. Editar o pacote para pular essa comparação tira a proteção em todos os casos, não só no falso positivo. Trocar o Node resolve sem abrir mão dela.

Quando sai a correção oficial?

Ainda não saiu. Em 25/10/2026, a issue #29898 seguia aberta, classificada como esforço médio, sem PR incorporado. O autor propôs duas correções: tirar as duas medições do arquivo já aberto, ou ignorar o dev no Windows quando um dos lados vier 0, mantendo o ino. Qualquer uma das duas acaba com o erro sem precisar trocar o Node. Até lá, o Node atualizado é o caminho mais limpo.