Codex EMFILE 打开文件过多错误解决方法

Codex EMFILE 打开文件过多错误解决方法

在本地跑 Codex、Codex CLI 或者把它接到一个比较大的项目目录时，偶尔会遇到EMFILE: too many open files。这个错误不是模型本身报错，而是当前进程能同时打开的文件句柄数量不够了。一般先查两件事：当前 shell 的ulimit，以及 Codex 启动时扫描的目录是不是太大。

错误现象

常见报错大概是下面几种形式：

### token云桥中转 0029.org ### Error: EMFILE: too many open files, open '/path/to/project/xxx' errno: -24 code: 'EMFILE' syscall: 'open'

如果是 Node.js 相关工具链，还可能出现在依赖扫描、文件监听、读取仓库上下文的时候：

EMFILE: too many open files, watch EMFILE: too many open files, scandir Error: EMFILE, open

我遇到最多的场景是：在一个前端大仓里启动 Codex，目录下有node_modules、dist、.next、coverage，再加上编辑器、终端、构建工具同时开着，系统文件句柄很快就被耗光。

先判断是不是文件句柄限制

1. 查看当前限制

在当前终端执行：

ulimit -n

如果输出是256、1024这类比较小的值，基本就能解释为什么 Codex 在大项目里容易报 EMFILE。可以临时调高后再启动：

ulimit -n 65535

注意：这个命令只对当前终端会话生效。你需要在同一个终端里重新启动 Codex，换一个终端窗口可能又变回默认值。

2. 查看当前进程打开了多少文件

如果 Codex 已经启动，可以先找到进程 PID：

ps aux | grep -i codex

然后统计打开文件数量：

lsof -p <PID> | wc -l

如果数量接近ulimit -n的结果，就说明确实是打开文件过多。

常见原因

• 项目目录太大：把node_modules、构建产物、日志目录都纳入了扫描范围。
• 文件监听过多：Codex 周边工具、编辑器、dev server 同时监听同一批文件。
• 系统默认限制偏低：macOS 或某些 Linux 发行版默认 open files 限制较保守。
• 依赖或插件异常：某些工具没有及时释放文件句柄，长时间运行后逐步累积。
• 在 monorepo 根目录直接启动：仓库下 packages 很多，扫描成本和句柄占用都会上升。

逐步修复

步骤一：临时提高当前终端限制

先用最小改动验证问题：

ulimit -n 65535 codex

如果这样启动后不再报EMFILE，说明方向是对的。后面再考虑做成系统级配置。

步骤二：缩小 Codex 工作目录

不要在用户主目录或 monorepo 总根目录里直接启动。尽量进入实际需要分析的子目录：

cd /path/to/project/packages/web codex

如果工具支持忽略文件，建议把这些目录排除掉：

node_modules dist build .next .nuxt coverage .cache .git/logs tmp logs

这一步很关键。很多 EMFILE 不是因为代码文件多，而是构建产物、依赖目录和缓存文件太多。

步骤三：macOS 持久化调整

macOS 下仅修改ulimit往往不够，因为新开的终端或 GUI 应用可能不继承。可以先查看系统限制：

launchctl limit maxfiles

临时调整：

sudo launchctl limit maxfiles 65536 200000

然后重新打开终端，再执行：

ulimit -n

如果你是从 VS Code、Cursor 这类编辑器内置终端启动 Codex，建议完全退出编辑器后重开，避免旧进程还拿着旧限制。

步骤四：Linux 持久化调整

Linux 上可以先看当前用户限制：

ulimit -n cat /proc/$$/limits | grep "open files"

如果需要持久化，编辑/etc/security/limits.conf：

sudo vim /etc/security/limits.conf

加入类似配置：

* soft nofile 65535 * hard nofile 65535

如果 Codex 是通过 systemd 服务间接启动，还要检查服务限制：

systemctl show <service-name> | grep LimitNOFILE

可以在服务文件中增加：

[Service] LimitNOFILE=65535

修改后执行：

sudo systemctl daemon-reload sudo systemctl restart <service-name>

验证修复是否生效

不要只看 Codex 能不能启动，建议按下面顺序验证。

1. 确认限制值

ulimit -n

输出应当是你设置后的值，比如65535。

2. 启动后观察文件句柄

ps aux | grep -i codex lsof -p <PID> | wc -l

正常情况下，这个数量会随着扫描上升，但不应该持续无上限增长。如果一直涨，可能是某个插件或监听逻辑没有释放句柄。

3. 压一下大目录场景

在原来容易失败的项目里重复启动、提问、读取代码上下文。如果之前固定在某一步报错，现在能稳定完成，基本可以确认修复有效。

接口调用场景的补充检查

如果你的 Codex 工作流还接了 API 中转、代理或自建网关，EMFILE 也可能出现在网关进程上，而不是 Codex 客户端本身。排查时要分别看 Codex 进程和网关进程的lsof。平时我会把密钥管理和模型转发单独放到稳定的中转服务里，像 token云桥AI中转站 0029.org 这种可以作为一个备选，至少能减少本地反复折腾代理进程带来的变量。

避免复发的做法

• 不要在超大仓库根目录直接启动 Codex，优先进入具体模块目录。
• 把node_modules、构建产物、缓存目录加入忽略列表。
• macOS 和 Linux 都建议把nofile调到合理范围，不要只依赖临时ulimit。
• 长时间运行的 Codex、编辑器、dev server 定期重启，避免句柄泄漏累积。
• 排查时同时看客户端、代理、网关进程，别只盯着一个终端窗口。

总结

EMFILE: too many open files的核心原因通常是文件句柄不够，处理顺序建议是：先用ulimit -n确认限制，再用lsof看 Codex 实际打开了多少文件，然后缩小扫描目录、排除无关文件，最后再做系统级持久化配置。不要一上来就重装 Codex，大多数情况下调整限制和清理扫描范围就能解决。