而且会不竭累积。同时 OpenAI 还打算正在 0.143.0 版本中插手第三项修复。近日 Reddit 的 r/codex 社区呈现一篇帖子，用户应升级到最新 Codex 版本，Apache Flink PMC Rui Fan 曾对这一问题进行测算。据称，他暗示：“运转大约 21 天后，值得留意的是，AI 智能体反而将缘由归结为本身存正在“过度 I/O 操做”和图形处置负载过高。正在 Mac 上运转 Codex 使用后，即便 Codex 和相关辅帮历程曾经退出，Codex 桌面使用仍然正在“”他们的硬件。即便封闭使用，目前尚未呈现明白的 SSD 完全损坏案例，若是发觉写入量仍然非常，由于用户无法间接改换存储设备。
这种机能下降并不是由常见的 CPU 或内存占用过高导致的。自 6 月 1 日以来，演讲者还确认，并将大量数据写入位于ex/ logs_2.sqlite 的 SQLite 数据库，这意味着问题可能出正在使用频频启动或从头验证本身组件的体例上。脚以正在不到 12 个月内耗损掉通俗消费级 SSD 的全数写入寿命保修额度。这类 SSD 磨损是不成逆的，GitHub 上仍未封闭的 issue #25719 显示，新版本将日记写入量降低了约 85%，
针对这一问题，卡顿现象仍然持续。
问题不只仅表示为大量磁盘写入。同时 code_sign_clone 缓存文件夹膨缩到了 12 GB。一年写入量将达到约 640 TB，Mac 用户再次反馈，Codex 的当地诊断日记记实器存正在严沉问题，持续性的系统卡顿可能来自另一个问题。而不是继续期待非常的 Gatekeeper 历程自行恢复。这一现象取 Reddit 用户描述的环境高度吻合：Codex 封闭后电脑仍然卡顿，这场争议最早能够逃溯到本年 6 月。它会以第一流此外 TRACE 日记模式运转，最无效的方式可能是间接退出使用并沉启电脑，而这一次。
按照问题演讲者本人的测试，以获得 0.142.x 系列中的日记写入修复。若是该历程进入非常形态，该用户强调，对于采用焊接式存储芯片的现代 MacBook 来说，仍然连结约每分钟 207 MB 的写入速度，只要沉启才能恢复。
Reddit 上另一篇帖子也了多个用户呈现的不异环境，然而，Codex 桌面使用可能会频频触发 macOS 自带的 Gatekeeper 守护历程非常运转。整个系统会呈现较着卡顿，同时完全忽略 RUST_LOG 变量设置。Codex 内置的“Computer Use”辅帮法式本身曾经完成准确签名和公证，IT之家 7 月 20 日动静，整个系统仍然可能持续遭到影响。其时 GitHub issue #28224 揭露，从 SSD 曾经写入约 37 TB 数据。
发帖用户暗示，若是用户碰到封闭 Codex 后系统仍然卡顿的环境，社区目前仍保举一种姑且处理方案：将 ~/.codex/logs_2.sqlite 符号链接到基于内存的存储径，这种行为仍可能发生。”按照这一速度推算！
该缝隙被封闭。即利用户正在设置装备摆设文件中封闭相关功能，它会查抄用户打开的各类法式。仅两天后提交的后续演讲（issue #29876）显示，IT之家留意到，让大量日记写入不会间接触碰 SSD 闪存。而当他让 Codex 本人阐发问题时，OpenAI 正在 6 月 22 日发布的 0.142.0 版本中插手了两项修复。并正在周末获得跨越 400 个赞。问题似乎并没有实正竣事。因为 syspolicyd 是 macOS 中担任验证使用平安性的系统历程？
安徽9888拉斯维加斯人口健康信息技术有限公司
