Gemini CLI "File device or inode changed during read" on Windows: how to fix

You opened Gemini CLI on Windows, asked it to read a file, and read_file came back with File device or inode changed during read. The file doesn't matter: even a two-line hello.txt fails. The file didn't change. The problem is the Node version on your machine, and Gemini CLI started noticing it in version 0.63.0.

This guide shows where the error comes from, how to confirm it with one command, and three ways to get unstuck while the official fix is pending. Everything was checked against the source code and releases of google-gemini/gemini-cli, the libuv ChangeLog and the official Node release index on 2026-10-25.

What does "File device or inode changed during read" mean?

It means Gemini CLI compared the file's identity (volume number and file number) before and during the read, and the two values didn't match. It treats that as the file being swapped mid-read and refuses to continue:

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

The error shows up in read_file, read_many_files, @file references and skill loading, according to issue #29898, opened on 2026-10-23. In practice, the agent can't read anything in your project.

Why does it only happen on Windows?

Because some Node versions on Windows return the wrong volume number in one of two lookups. The readSecureFileBuffer function, in packages/core/src/utils/fileUtils.ts, reads the file's dev and ino by path and then from the open file handle, and requires them to match:

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

On Node versions that ship libuv 1.49.1 through 1.50.0, the path lookup returns dev: 0 on Windows, while the handle lookup returns the real volume serial. ino matches, dev doesn't, and every file is rejected. libuv 1.49.0 switched Windows stat to a new fast API ("win,fs: use the new Windows fast stat API"), and 1.51.0 shipped "win: fix the inconsistency in volume serial number". Linux and macOS don't go through that code.

Node	libuv	Result on Windows
20.20.2	1.46.0	Works (tested in the issue)
22.12.0 to 22.16.0	1.49.1 to 1.49.2	Fails (22.12.0, 22.14.0 and 22.16.0 tested in the issue)
23.1.0 to 23.11.x	1.49.1 to 1.50.0	Fails (23.11.0 tested in the issue)
24.0.0 to 24.1.0	1.50.0	Same libuv as the failing versions, not tested in the issue
22.17.0 and later, 24.2.0 and later	1.51.0 or newer	Works (22.18.0, 22.20.0 and 22.23.3 tested in the issue)

Source for the libuv column: the official index at nodejs.org/dist/index.json, checked on 2026-10-25.

Why only now, if the Node version is old?

Because the check is new. It came in with PR #29506, merged on 2026-09-25, and reached the stable 0.63.0 release. The project's CI runs the Windows tests on Node 20, which doesn't have the problem, while package.json accepts any Node from 20 up.

Gemini CLI	Has the check?	Released
0.62.0	No	2026-09-29
0.63.0 and 0.64.0	Yes	2026-10-06 and 2026-10-13
0.65.0 (stable, latest tag)	Yes	2026-10-20
Nightly 0.67.0 from 10/25	Yes, not fixed	2026-10-25

How do I confirm this is the problem?

Check the Gemini CLI version and the Node version with its libuv. Works in PowerShell and Command Prompt:

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

If Gemini CLI is 0.63.0 or newer and libuv is between 1.49.1 and 1.50.0, it's this bug. To see the mismatch yourself, run this in the project folder, replacing package.json with any file that exists there:

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

Per the issue's diagnosis, on an affected Node the first number is 0 and the second isn't. On a Node without the problem, both are equal.

How do I fix "File device or inode changed during read"?

Upgrade Node to a version with libuv 1.51.0 or newer: 24 LTS, or 22.18.0 and later. It's the root fix and doesn't touch Gemini CLI.

With winget, the LTS package currently installs Node 24.22.1:

winget install OpenJS.NodeJS.LTS

If you use nvm-windows:

nvm install 24.22.1
nvm use 24.22.1

Then open a new terminal, reinstall Gemini CLI and check:

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

The reinstall matters on nvm-windows: each Node version has its own global packages folder, and the old gemini stays stuck on the previous Node.

Node can't change: go back to 0.62.0

If another project pins your machine to Node 22.14, for example, roll Gemini CLI back to before the check.

1. Turn off auto update in ~/.gemini/settings.json, or it will update itself back to 0.65.0:

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

2. Install the previous version:

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

3. When the fix lands in a stable release, turn enableAutoUpdate back on and update.

The cost is losing everything that shipped from 0.63.0 to 0.65.0. If you run with --yolo, 0.62.0 has one upside: it doesn't have the Untrusted Command Flags Detected warning yet, which we explain in this guide.

Third option: run Gemini CLI in WSL

The bug lives in the Windows code path. Inside WSL, Gemini CLI runs on Linux and the check compares consistent values:

wsl
npm install -g @google/gemini-cli

WSL has its own Node, installed inside the distribution, and it doesn't have the dev: 0 problem. Using 24 LTS there too is a good idea.

Can I turn the check off?

Not through settings, and patching it out isn't worth it. The code comment says the function checks dev and ino before, during and after the read to make sure the file read is the same from start to finish. Editing the package to skip that comparison removes the protection for everything, not just the false positive. Upgrading Node fixes it without giving that up.

When will the official fix ship?

It hasn't yet. As of 2026-10-25, issue #29898 was still open, labeled medium effort, with no merged PR. The reporter proposed two fixes: take both measurements from the open file handle, or skip dev on Windows when either side is 0 while keeping ino. Either one ends the error without changing Node. Until then, an up-to-date Node is the cleanest path.