中国政策档案 Governance Archive HOLDINGS 223,392 · FONDS 106
Record · 凤凰网科技 ACC. 900061449

Mac Users Report OpenAI Codex Desktop App Causes System Lag, Persists After App Closure

Mac用户称OpenAI Codex导致电脑卡顿,关闭应用后也无法恢复

Issuer
凤凰网科技
Date
Instrument
other
Cited by
0
This media report details ongoing performance issues with OpenAI's Codex desktop application on Mac systems, including system lag and excessive SSD write operations, despite previous fixes. It highlights unresolved technical problems affecting user hardware.
Full text · 原文 2,219 字
IT之家 7 月 20 日消息,就在 OpenAI 宣布解决了一个会疯狂消耗开发者 SSD 寿命的日志写入漏洞几周后,Mac 用户再次反馈,Codex 桌面应用依然在“折磨”他们的硬件。而这一次,问题不仅仅表现为大量磁盘写入。<br> IT之家注意到,近日 Reddit 的 r/codex 社区出现一篇帖子,并在周末获得超过 400 个赞。发帖用户表示,在 Mac 上运行 Codex 应用后,整个系统会出现明显卡顿,即使关闭应用,卡顿现象仍然持续,唯有彻底重启电脑才能有效解决。<br> 值得注意的是,该用户强调,这种性能下降并不是由常见的 CPU 或内存占用过高导致的。而当他让 Codex 自己分析问题时,AI 智能体反而将原因归结为自身存在“过度 I/O 操作”和图形处理负载过高。<br> Reddit 上另一篇帖子也证实了多个用户出现的相同情况,不过严重程度似乎因设备而异。<br> 这场争议最早可以追溯到今年 6 月。当时 GitHub issue #28224 揭露,Codex 的本地诊断日志记录器存在严重问题,它会以最高级别的 TRACE 日志模式运行,并将大量数据写入位于 ~/.codex/ logs_2.sqlite 的 SQLite 数据库,同时完全忽略 RUST_LOG 环境变量设置。<br> Apache Flink PMC 成员 Rui Fan 曾对这一问题进行测算。他表示:“运行大约 21 天后,主 SSD 已经写入约 37 TB 数据。”按照这一速度推算,一年写入量将达到约 640 TB,足以在不到 12 个月内消耗掉普通消费级 SSD 的全部写入寿命保修额度。<br> 针对这一问题,OpenAI 在 6 月 22 日发布的 0.142.0 版本中加入了两项修复。根据问题报告者自己的测试,新版本将日志写入量降低了约 85%,同时 OpenAI 还计划在 0.143.0 版本中加入第三项修复。<br> 随后,该漏洞被官方关闭。然而,问题似乎并没有真正结束。仅两天后提交的后续报告(issue #29876)显示,一台搭载 M4 芯片的 MacBook Air 在 Codex 基本处于空闲状态时,仍然保持约每分钟 207 MB 的写入速度,同时 code_sign_clone 缓存文件夹膨胀到了 12 GB。<br> 对于采用焊接式存储芯片的现代 MacBook 来说,这类 SSD 磨损是不可逆的,因为用户无法直接更换存储设备。<br> 持续性的系统卡顿可能来自另一个独立问题。GitHub 上仍未关闭的 issue #25719 显示,自 6 月 1 日以来,Codex 桌面应用可能会反复触发 macOS 自带的 Gatekeeper 守护进程异常运行。<br> 具体表现为,系统进程 syspolicyd 在启动 Codex 后 CPU 占用飙升至 125%~200%,内存使用量甚至超过 8 GB。<br> 由于 syspolicyd 是 macOS 中负责验证应用安全性的系统进程,它会检查用户打开的各种程序。如果该进程进入异常状态,即使 Codex 和相关辅助进程已经退出,整个系统依然可能持续受到影响。<br> 这一现象与 Reddit 用户描述的情况高度吻合:Codex 关闭后电脑仍然卡顿,只有重启才能恢复。<br> 报告者还确认,Codex 内置的“Computer Use”辅助程序本身已经完成正确签名和公证,这意味着问题可能出在应用反复启动或重新验证自身组件的方式上。据称,即使用户在配置文件中关闭相关功能,这种行为仍可能发生。<br> 目前尚未出现明确的 SSD 彻底损坏案例,但持续性的写入磨损确实存在,并且会不断累积。<br> Mac 和 Linux 用户可以通过 smartctl-a/dev/ nvme0n1 命令(可通过 Homebrew 安装 smartmontools)查看 SSD 的累计写入量;Windows 用户则可以使用 CrystalDiskInfo 查看“Total Host Writes(总主机写入量)”数据。<br> 用户应升级到最新 Codex 版本,以获得 0.142.x 系列中的日志写入修复。如果发现写入量仍然异常,社区目前仍推荐一种临时解决方案:将 ~/.codex/logs_2.sqlite 符号链接到基于内存的存储路径,让大量日志写入不会直接触碰 SSD 闪存。<br> 在 OpenAI 解决 Codex 与 macOS syspolicyd 之间的兼容问题之前,如果用户遇到关闭 Codex 后系统仍然卡顿的情况,最有效的方法可能是直接退出应用并重启电脑,而不是继续等待异常的 Gatekeeper 进程自行恢复。<br> 截至目前,OpenAI 尚未针对这些最新反馈公开发表评论。<br> “特别声明:以上作品内容(包括在内的视频、图片或音频)为凤凰网旗下自媒体平台“大风号”用户上传并发布,本平台仅提供信息存储空间服务。<br> Notice: The content above (including the videos, pictures and audios if any) is uploaded and posted by the user of Dafeng Hao, which is a social media platform and merely provides information storage space services.”