最新 7 月 20 日消息，就在 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 尚未针对这些最新反馈公开发表评论。