OpenAI 前脚刚宣布修复了一个会疯狂消耗开发者 SSD 寿命的日志写入漏洞，后脚 Mac 用户就发现，Codex 桌面应用又开始折腾他们的硬件了。而且，这次的问题还不只是磁盘写入这么简单。

事情是这样的：最近 Reddit 上 r/codex 社区的一篇帖子火了，周末期间获得了超过 400 个赞。发帖人描述了一个相当恼人的状况——在 Mac 上运行 Codex 应用后，整个系统会明显卡顿，更让人崩溃的是，就算把应用关了，卡顿感依然挥之不去，唯一的解决办法就是彻底重启电脑。

值得关注的是，这位用户特别强调，这次性能下降跟通常的 CPU 或内存占用过高没有关系。他让 Codex 自己分析问题，结果 AI 智能体给出的结论是：自身存在“过度 I/O 操作”和图形处理负载过高。

Reddit 上另一篇帖子也证实了类似情况，不少用户都遇到了相同的问题，只是严重程度因设备不同而有所差异。

说起这场争议，最早可以追溯到今年 6 月。当时 GitHub issue #28224 揭露，Codex 的本地诊断日志记录器存在严重问题——它以最高级别的 TRACE 日志模式运行，把大量数据写入 ~/.codex/logs_2.sqlite 这个 SQLite 数据库，而且完全无视了 RUST_LOG 环境变量的设置。

Apache Flink PMC 成员 Rui Fan 曾对此进行过测算。他表示：“运行大约 21 天后，主 SSD 写入量就达到了约 37 TB。”按照这个速度推算，一年写入量将高达约 640 TB，足以在不到 12 个月内消耗掉普通消费级 SSD 的全部写入寿命保修额度。

针对这一问题，OpenAI 在 6 月 22 日发布的 0.142.0 版本中加入了两个修复。根据问题报告者的测试，新版本将日志写入量降低了约 85%，同时 OpenAI 还计划在 0.143.0 版本中推出第三项修复。

随后，该漏洞被官方关闭。然而，故事并没有就此结束。仅仅两天后，就有后续报告（issue #29876）指出，一台搭载 M4 芯片的 MacBook Air，在 Codex 基本处于空闲状态时，仍然保持每分钟约 207 MB 的写入速度，同时 code_sign_clone 缓存文件夹也膨胀到了 12 GB。

对于采用焊接式存储芯片的现代 MacBook 来说，这种 SSD 磨损是不可逆的，因为用户无法直接更换存储设备。

持续性的系统卡顿，可能源自另一个独立的问题。GitHub 上仍未关闭的 issue #25719 显示，自 6 月 1 日以来，Codex 桌面应用可能会反复触发 macOS 自带的 Gatekeeper 守护进程异常运行。

具体表现为，系统进程 syspolicyd 在启动 Codex 后 CPU 占用飙升至 125% 到 200%，内存使用量甚至超过 8 GB。

由于 syspolicyd 是 macOS 中负责验证应用安全性的系统进程，它会检查用户打开的各种程序。如果该进程进入异常状态，即使 Codex 和相关辅助进程已经退出，整个系统依然可能持续受到影响。

这一现象与 Reddit 用户描述的情况高度吻合：Codex 关闭后电脑仍然卡顿，只有重启才能恢复。

报告者还确认，Codex 内置的“Computer Use”辅助程序本身已经完成正确签名和公证，这意味着问题可能出在应用反复启动或重新验证自身组件的方式上。据称，即使用户在配置文件中关闭相关功能，这种行为仍可能发生。

目前为止，还没有出现明确的 SSD 彻底损坏案例，但持续性的写入磨损确实存在，并且会不断累积。

如果你的 Mac 或 Linux 电脑也遇到了类似问题，可以通过 smartctl -a /dev/nvme0n1 命令（需通过 Homebrew 安装 smartmontools）查看 SSD 的累计写入量；Windows 用户则可以使用 CrystalDiskInfo 查看“Total Host Writes（总主机写入量）”数据。

建议用户升级到最新 Codex 版本，以获得 0.142.x 系列中的日志写入修复。如果发现写入量仍然异常，社区目前推荐一种临时解决方案：将 ~/.codex/logs_2.sqlite 符号链接到基于内存的存储路径，这样大量日志写入就不会直接触碰 SSD 闪存。

在 OpenAI 解决 Codex 与 macOS syspolicyd 之间的兼容问题之前，如果遇到关闭 Codex 后系统仍然卡顿的情况，最直接的做法就是退出应用并重启电脑，而不是继续等待异常的 Gatekeeper 进程自行恢复。

截至目前，OpenAI 尚未针对这些最新反馈公开发表评论。

《夸克》非常好用的免费AI浏览器

下载APP查看