OpenAI 的 Codex 桌面应用近期再次让 Mac 用户陷入困境。几周前，刚刚修复了一个能迅速耗尽 SSD 写入寿命的日志漏洞，如今新问题接踵而至——不仅存在磁盘写入异常，还会导致系统完全卡死，即便关闭应用也无法恢复，必须重启电脑才能解决。这一话题在 Reddit 上引发了广泛讨论，单篇帖子已获得 400 多个赞。

实际情况是：有用户反馈，在 Mac 上运行 Codex 后，系统出现明显卡顿，即使彻底退出应用，卡顿感依然持续存在，唯一有效的办法就是重启电脑。更令人困惑的是，这种性能下降的根源既非 CPU 飙升，也非内存不足。有趣的是，让 Codex 进行自我诊断时，AI 智能体给出的结论是——自身存在“过度 I/O 操作”以及图形处理负载过高。

多位用户报告了类似情况。Reddit 上另一篇帖子也证实了这一问题，只是严重程度因设备不同而有所差异。可见，这并非孤立事件。

历史遗留问题：日志写入的“黑洞”

这场风波最早可追溯至今年 6 月。当时 GitHub 上的 issue #28224 揭露了一个关键问题：Codex 的本地诊断日志记录器默认以最高级别 TRACE 模式运行，且完全无视 RUST_LOG 环境变量的设置。结果导致大量数据被疯狂写入 ~/.codex/logs_2.sqlite 这个 SQLite 数据库。

Apache Flink PMC 成员 Rui Fan 曾专门计算过：运行约 21 天，主 SSD 写入量便达到 37TB。按此速度，一年写入量约 640TB——这意味着不到 12 个月就能耗尽普通消费级 SSD 的全部写入寿命保修额度。对于 MacBook 这类采用焊接式存储芯片的设备，这种磨损是不可逆的，因为用户无法自行更换硬盘。

针对此问题，OpenAI 于 6 月 22 日发布的 0.142.0 版本中加入了两个修复。测试显示，新版本将日志写入量降低了约 85%，同时计划在 0.143.0 版本中推出第三项修复。随后，该漏洞被标记为关闭。

然而问题并未真正解决。仅两天后，后续报告指出：一台搭载 M4 芯片的 MacBook Air，在 Codex 基本处于空闲状态时，仍保持约每分钟 207MB 的写入速度，同时 code_sign_clone 缓存文件夹膨胀至 12GB。如此数据量，令人担忧。

系统卡顿的幕后黑手：Gatekeeper 在“发疯”

那么，持续的系统卡顿原因何在？这很可能源于另一个独立问题。GitHub 上仍未关闭的 issue #25719 显示，自 6 月 1 日起，Codex 桌面应用可能反复触发 macOS 自带的 Gatekeeper 守护进程异常运行。

具体表现为：系统进程 syspolicyd 在启动 Codex 后，CPU 占用率飙升至 125%～200%，内存使用量甚至超过 8GB。syspolicyd 是 macOS 中负责验证应用安全性的进程，会检查用户打开的程序。若该进程进入异常状态，即使 Codex 及相关辅助进程已退出，整个系统仍可能持续受到拖累。

这一现象与 Reddit 用户描述的情况高度吻合：Codex 关闭后电脑仍然卡顿，只有重启才能恢复。报告者还确认，Codex 内置的“Computer Use”辅助程序已完成正确签名和公证，这意味着问题可能出在应用反复启动或重新验证自身组件的方式上。即便用户在配置文件中关闭了相关功能，这种行为仍可能发生。

怎么办？一些“急救”建议

目前来看，虽然尚未出现 SSD 彻底损坏的明确案例，但持续写入磨损确实存在且不断累积。Mac 用户可使用 smartctl -a /dev/nvme0n1 命令查看 SSD 累计写入量；Windows 用户可用 CrystalDiskInfo 查看“Total Host Writes”数据。

首先，建议升级至最新版本，至少获得 0.142.x 系列中的日志写入修复。若写入量仍异常，社区推荐临时解决方案：将 ~/.codex/logs_2.sqlite 符号链接到基于内存的存储路径，这样日志写入就不会直接触及 SSD 闪存。

至于系统卡顿问题，在 OpenAI 彻底解决 Codex 与 macOS syspolicyd 兼容性之前，最有效的方法仍是退出应用并重启电脑。等待异常的 Gatekeeper 进程自行恢复，恐怕不太现实。

截至目前，OpenAI 尚未就这些最新反馈公开发表评论。然而，事态发展至此，用户们的耐心恐怕已所剩无几。