Gemini CLI 在 Windows 上报 "File device or inode changed during read"：解决方法

你在 Windows 上打开 Gemini CLI，让它读取一个文件，read_file 却返回 File device or inode changed during read。读哪个文件都一样：连只有两行的 hello.txt 也会失败。文件本身并没有变化。真正的问题出在你机器上安装的 Node 版本，而 Gemini CLI 从 0.63.0 开始才会察觉到它。

本文说明这个错误从何而来、如何用一条命令确认，以及在官方修复发布前的三种解决办法。所有内容均于 2026年10月25日 对照 google-gemini/gemini-cli 的源码与发布记录、libuv 的 ChangeLog 以及 Node 官方版本索引核对。

"File device or inode changed during read" 是什么意思？

意思是 Gemini CLI 在读取前和读取中比较了文件的身份（卷号和文件号），两次的值不一致。它会把这当成文件在读取过程中被替换，于是拒绝继续：

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

根据 2026年10月23日 提交的 issue #29898，这个错误会出现在 read_file、read_many_files、@文件 引用以及技能（skill）加载中。实际效果就是：智能体读不了项目里的任何文件。

为什么只在 Windows 上出现？

因为部分 Node 版本在 Windows 上，两次查询中有一次返回了错误的卷号。packages/core/src/utils/fileUtils.ts 中的 readSecureFileBuffer 函数先按路径获取文件的 dev 和 ino，再从已打开的文件句柄获取一次，并要求两者一致：

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

在使用 libuv 1.49.1 至 1.50.0 的 Node 版本中，Windows 上按路径查询返回 dev: 0，而按句柄查询返回真实的卷序列号。ino 一致，dev 不一致，于是所有文件都被拒绝。libuv 1.49.0 把 Windows 的 stat 换成了新的快速 API（"win,fs: use the new Windows fast stat API"），1.51.0 则加入了 "win: fix the inconsistency in volume serial number"。Linux 和 macOS 不走这段代码。

Node	libuv	Windows 上的结果
20.20.2	1.46.0	正常（issue 中已测试）
22.12.0 至 22.16.0	1.49.1 至 1.49.2	失败（issue 中测试了 22.12.0、22.14.0 和 22.16.0）
23.1.0 至 23.11.x	1.49.1 至 1.50.0	失败（issue 中测试了 23.11.0）
24.0.0 至 24.1.0	1.50.0	与失败版本使用相同的 libuv，issue 中未测试
22.17.0 及以上、24.2.0 及以上	1.51.0 或更新	正常（issue 中测试了 22.18.0、22.20.0 和 22.23.3）

libuv 一列的来源：官方索引 nodejs.org/dist/index.json，查询于 2026年10月25日。

Node 版本早就装了，为什么现在才出错？

因为这项检查是新加的。它来自 2026年9月25日 合并的 PR #29506，随稳定版 0.63.0 发布。项目的 CI 在 Node 20 上运行 Windows 测试，而 Node 20 没有这个问题；同时 package.json 允许 20 及以上的任何 Node。

Gemini CLI	是否有这项检查	发布日期
0.62.0	没有	2026年9月29日
0.63.0 和 0.64.0	有	2026年10月6日 和 10月13日
0.65.0（稳定版，latest 标签）	有	2026年10月20日
10月25日 的 0.67.0 nightly	有，尚未修复	2026年10月25日

如何确认就是这个问题？

查看 Gemini CLI 的版本，以及 Node 的版本和它的 libuv。在 PowerShell 和命令提示符中都能用：

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

如果 Gemini CLI 是 0.63.0 或更新版本，且 libuv 在 1.49.1 到 1.50.0 之间，就是这个 bug。想亲眼看到差异，可以在项目目录中运行下面的命令，把 package.json 换成该目录下任意存在的文件：

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

按照 issue 中的诊断，受影响的 Node 会输出第一个数字为 0、第二个不为 0。没有问题的 Node 两个数字相同。

如何解决 "File device or inode changed during read"？

把 Node 升级到 libuv 1.51.0 或更新的版本：24 LTS，或 22.18.0 及以上。这是根本解决办法，不需要改动 Gemini CLI。

使用 winget 时，LTS 包目前安装的是 Node 24.22.1：

winget install OpenJS.NodeJS.LTS

如果你用的是 nvm-windows：

nvm install 24.22.1
nvm use 24.22.1

然后打开一个新终端，重新安装 Gemini CLI 并确认：

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

在 nvm-windows 下重新安装很关键：每个 Node 版本都有自己的全局包目录，旧的 gemini 会一直留在之前的 Node 中。

无法更换 Node：回退到 0.62.0

比如另一个项目把机器锁定在 Node 22.14，那就把 Gemini CLI 回退到加入这项检查之前的版本。

1. 在 ~/.gemini/settings.json 中关闭自动更新，否则它会自己升级回 0.65.0：

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

2. 安装之前的版本：

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

3. 等修复进入稳定版后，重新打开 enableAutoUpdate 并更新。

代价是失去 0.63.0 到 0.65.0 之间的所有更新。如果你使用 --yolo，0.62.0 还有一个好处：它还没有 Untrusted Command Flags Detected 警告，我们在这篇指南中解释过。

第三种办法：在 WSL 中运行 Gemini CLI

这个 bug 位于 Windows 的代码路径中。在 WSL 里，Gemini CLI 运行在 Linux 上，检查比较的是一致的值：

wsl
npm install -g @google/gemini-cli

WSL 中的 Node 是另一套，安装在发行版内部，没有 dev: 0 的问题。在里面同样建议使用 24 LTS。

能关闭这项检查吗？

没有配置项可以关，靠修改代码绕过也不值得。代码注释说明，这个函数在读取前、读取中和读取后都会核对 dev 和 ino，以确保从头到尾读的是同一个文件。改包跳过这项比较，会让所有情况都失去保护，而不只是消除误报。升级 Node 就能解决问题，同时保留这层保护。

官方修复什么时候发布？

目前还没有。截至 2026年10月25日，issue #29898 仍处于打开状态，被标记为中等工作量，没有已合并的 PR。提交者提出了两种修复方案：两次测量都从已打开的文件句柄获取；或者在 Windows 上任意一方为 0 时跳过 dev，只比较 ino。任何一种都能在不更换 Node 的情况下消除这个错误。在此之前，升级 Node 是最干净的办法。