物界前沿Mac 用户被 Codex 拖垮：这次不是日志，是整个系统在“漏气”
这条新闻值得关注，是因为它揭示了一个比日志写入漏洞更棘手的结构性问题。OpenAI 的 Codex 桌面应用，在 Mac 上制造了一种“卡顿幽灵”，即使关闭应用，电脑的迟缓也无法恢复。这不像一个简单的 bug，更像系统资源被某种机制永久锁死或泄漏了。
Reddit 的 r/codex 社区里，用户的描述带着一种精准的绝望。“我关闭了 Codex，但我的 MacBook 依然在风扇狂转，触控板延迟，就像它还在运行。” 一位用户写道。这让我想起基努里维斯在《黑客帝国》里的台词：“你感觉不到它，但它一直在那里。” 这次，用户能感觉到，而且无法摆脱。
背后逻辑是，Mac 的“统一内存”架构和 AI 应用的交互，正在进入一个危险的磨合期。传统上，应用关闭后，其申请的内存、CPU 时间片会被系统回收。但 Codex 这类 AI 应用，尤其是结合了本地模型推理或持续上下文监控的版本，可能通过某些后台守护进程、内核扩展或复杂的缓存机制，与系统底层建立了更深的绑定。它可能不是“不退出”，而是“退出不干净”。
[!info] 一个值得注意的细节是，用户反馈在 Activity Monitor 里已经找不到 Codex 的进程，但系统的“内存压力”和“能耗影响”依然居高不下。这暗示问题可能出在更底层的驱动或系统服务层面。
这种“卡顿幽灵”现象，让我联想到早年 Windows 上某些显卡驱动崩溃后，系统无法恢复完整的图形加速能力。但 Mac 的封闭生态和统一内存设计，理论上应该更易于管理资源。出现这种“退出后仍中毒”的情况，要么是 OpenAI 的工程师在开发时，对 macOS 的沙盒限制和资源管理策略理解不够深，使用了某些非标准或已被弃用的 API；要么是 Codex 为了追求低延迟的代码补全，在系统层面植入了过于激进的预加载或缓存策略，导致系统进程被错误地“污染”。
更有意思的是，这发生在 OpenAI 刚刚宣称解决了另一个“硬件杀手”级的日志写入漏洞之后。那个漏洞会疯狂消耗 SSD 寿命，本质上是一个软件层面的 Garbage Collection 失控。而这次，是资源管理的“系统性失控”。这就像一个人治好了肺炎，又查出了心脏病。根源可能在于，AI 应用的开发范式，与传统的操作系统资源管理哲学，产生了深刻的冲突。
AI 应用，尤其是桌面端的 AI 助手，它的运行逻辑是“常驻、感知、预测”。它需要持续监控用户的输入、文件变化、甚至系统状态，以便在“你需要”的瞬间给出响应。这种“预判式”的架构，与操作系统“响应式”的资源分配逻辑存在根本性矛盾。系统认为你不活跃了，可以回收资源；但 Codex 的“感知”进程却在后台保持一定活跃度，向系统发出“我需要保持待命”的信号。当这种信号传递出现混乱，或者应用的退出流程没有正确撤销这些信号，系统就陷入了一种“不知道该信谁”的困境。
一个明确的趋势预测是：未来一年内，我们会看到更多关于“AI 应用拖垮系统”的投诉。 这不是 OpenAI 一家