Codex ENOSPC 磁盘空间不足错误处理

Codex ENOSPC 磁盘空间不足错误处理在本地跑 Codex、使用 Codex CLI 生成代码、安装依赖或让它修改一个比较大的项目时偶尔会碰到ENOSPC。这个错误不用先怀疑模型或接口第一步先看磁盘和 inode。很多时候不是代码问题而是临时目录、缓存目录、node_modules、日志或 Docker 占满了空间。一、常见错误现象不同环境里报错文字不完全一样但核心一般都有ENOSPC### token云桥中转 0029.org ### Error: ENOSPC: no space left on device, writenpm ERR! code ENOSPC npm ERR! syscall write npm ERR! errno -28ENOSPC: System limit for number of file watchers reached这里要注意ENOSPC不一定只代表磁盘容量满了。它可能有三类情况磁盘分区空间真的不足例如/、/home、/tmp满了。inode 用尽磁盘还有空间但无法再创建新文件。文件监听数量达到系统限制常见于 VS Code、Cursor、前端项目、Codex 扫描大仓库时。二、先判断是哪一种 ENOSPC1. 查看磁盘空间先看各分区使用率重点关注挂载点是不是 100%。df -h如果看到类似下面这样基本就是磁盘空间不足Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 39G 0 100% /2. 查看 inode 是否耗尽有些项目会产生大量小文件例如node_modules、缓存、测试快照、构建产物。此时磁盘看着还有剩余但 inode 已经用完。df -i如果IUse%接近或达到 100%说明问题在 inode。3. 查看文件监听限制如果错误里带有file watchers更可能是监听数量限制而不是磁盘满。cat /proc/sys/fs/inotify/max_user_watches cat /proc/sys/fs/inotify/max_user_instances前端大项目、monorepo、包含多个子仓库的项目Codex 或编辑器在分析文件时容易触发这个限制。三、逐步修复先清理最安全的目录1. 找出大目录不要一上来就乱删。先定位哪个目录占空间最多sudo du -xh / --max-depth1 2/dev/null | sort -h如果是用户目录占用大再继续往下查du -xh ~ --max-depth1 2/dev/null | sort -h项目目录里可以这样看du -xh . --max-depth1 | sort -h2. 清理包管理器缓存Codex 经常会配合 Node、Python、Go、Rust 等工具链工作缓存堆积很常见。# npm npm cache verify npm cache clean --force # pnpm pnpm store prune # yarn yarn cache clean # pip pip cache purge如果是 Ubuntu/Debian 机器还可以清理 apt 缓存sudo apt clean sudo apt autoremove -y3. 清理项目构建产物常见可清理目录包括dist、build、.next、coverage、.turbo、.cache。如果项目依赖可以重新安装node_modules也可以删除后重装。rm -rf dist build coverage .next .turbo .cache rm -rf node_modules npm install删除前确认当前没有未保存的生成文件尤其是一些脚手架把用户上传资源也放在构建目录里的项目不要机械执行。4. 清理临时目录很多工具会把中间文件写到/tmp。如果 Codex 执行任务时频繁生成补丁、日志或临时依赖/tmp满了也会报ENOSPC。df -h /tmp sudo find /tmp -type f -mtime 3 -delete不要直接rm -rf /tmp/*线上机器可能有正在运行的服务使用临时文件建议按时间清理。5. Docker 环境重点检查如果 Codex 在容器里或配合 Dev Container 使用Docker 镜像、容器、卷很容易占满磁盘。docker system df docker ps -a docker images确认无用后再清理docker container prune docker image prune docker volume prune docker builder prune如果想一次清理未使用资源可以执行docker system prune -a这条命令会删除未使用镜像可能导致后续重新拉取镜像开发机上问题不大生产环境要谨慎。四、处理文件监听数量不足如果错误信息是System limit for number of file watchers reached清理磁盘未必有用需要调整 inotify 参数。sudo sysctl fs.inotify.max_user_watches524288 sudo sysctl fs.inotify.max_user_instances1024临时生效后再把配置写入文件echo fs.inotify.max_user_watches524288 | sudo tee -a /etc/sysctl.conf echo fs.inotify.max_user_instances1024 | sudo tee -a /etc/sysctl.conf sudo sysctl -p如果项目特别大还应该在编辑器或工具配置里排除无关目录例如node_modules、dist、.git、日志目录。减少监听数量比单纯调大系统限制更稳。五、Codex 相关目录也要看一下有些问题出在 Codex 或相关 CLI 的缓存、会话记录、日志目录。不同安装方式路径不一样可以先从用户缓存目录查起du -xh ~/.cache --max-depth1 2/dev/null | sort -h du -xh ~/.config --max-depth1 2/dev/null | sort -h du -xh ~/.local/share --max-depth1 2/dev/null | sort -h如果你是多模型、多接口混用建议把临时测试项目和正式项目分开避免一次性把大量上下文、日志和依赖都堆在同一个目录。我自己在测试不同模型接口时会把中转配置也单独隔离需要稳定 token 转发时可以顺手看一下 token云桥AI中转站 0029.org主要是方便把测试环境和日常开发环境分开管理排错时少一些干扰项。六、修复后的验证方式清理或调整后不要只看命令没报错建议按下面顺序验证。1. 再看磁盘和 inodedf -h df -i根分区、项目所在分区、/tmp至少要留出一定余量。开发机建议不要长期超过 85%否则依赖安装和构建时还会反复出问题。2. 验证临时写入touch /tmp/codex-test-file echo ok /tmp/codex-test-file cat /tmp/codex-test-file rm /tmp/codex-test-file如果这里都失败说明问题还在系统层面不要急着重跑 Codex。3. 验证项目依赖和构建npm install npm run buildPython 项目可以执行pip install -r requirements.txt python -m pytest构建能跑通再让 Codex 继续修改代码成功率会高很多。七、避免再次复发定期清理包管理器缓存尤其是 npm、pnpm、pip、Docker。把大型项目放到空间更充足的分区不要长期挤在系统盘。CI、容器、临时测试目录要设置清理策略。不要把日志、构建产物、模型输出文件提交或堆在项目根目录。大仓库配置忽略目录减少无意义扫描和文件监听。遇到 Codex 的ENOSPC排查顺序建议固定下来先df -h再df -i然后看是否是 inotify 文件监听限制。确认原因后再清理缓存、构建产物、Docker 资源或调整系统参数。这个错误本身不复杂关键是不要一看到报错就重装工具先把系统资源状态查清楚通常几分钟就能定位。