Mac用戶抱怨 OpenAI Codex 讓 Mac 嚴重卡頓，還可能狂寫 SSD 害系統停擺

OpenAI Codex 桌面應用再傳軟體瑕疵！許多 Mac 使用者近日在社群平台反映，在電腦上運行 Codex 應用程式後，整體系統會陷入極為明顯的嚴重卡頓。

更令人困擾的是，即便使用者手動關閉 Codex 應用程式，系統的延遲與卡頓現象依然無法恢復，最終唯有重新開機才能徹底解決。這項問題繼日前瘋狂寫入日誌、耗損 SSD 壽命的漏洞後，再次將這款熱門 AI 開發工具推上風口浪尖。

Codex 自我診斷：過度的 I/O 讀寫操作

根據 Reddit 社群 r/codex 上的熱烈討論，有發帖使用者指出，這種效能暴跌並非由常見的 CPU 或記憶體資源吃滿所致。奇妙的是，當使用者嘗試讓 Codex 自身的 AI Agent 進行自我診斷時，AI 竟回覆將原因歸咎於自身存在「過度的 I/O 讀寫操作」以及「過高的圖形處理負載」。社群中多位使用者也隨後證實了相同情況，雖然各台 Mac 設備的受影響程度不一，但關閉程式後卡頓不退的現象極為普遍。

這場關於 OpenAI Codex 影響 Mac 效能與硬體健康度的爭議，最早可追溯至今年 6 月。

當時在 GitHub issue #28224 中，開發者揭露了 Codex 本地診斷日誌記錄器（Diagnostic Logger）存在嚴重瑕疵。該元件會以最高層級的 TRACE 日誌模式持續運行，並將龐大的數據強制寫入位於 ~/.codex/logs_2.sqlite 的 SQLite 資料庫中，同時完全無視環境變數 RUST_LOG 的設定。

Apache Flink PMC 成員 Rui Fan 曾對此進行精確測算並警告：「Codex 運行大約 21 天後，主要 SSD 就已累計寫入高達 37 TB 的資料。」若按此速率推算，一年寫入量將衝破 640 TB，足以在不到 12 個月內徹底耗盡市面上絕大多數消費級 SSD 的原廠保固寫入 TBW（Total Bytes Written）額度。

面對社群強烈反彈，OpenAI 於 6 月 22 日推出的 0.142.0 版本中緊急加入了兩項修復措施。經測試，該版本成功將日誌寫入量降低了約 85%，OpenAI 隨後也規劃在 0.143.0 版本中導入第三階段修復，並將該 GitHub Issue 標記為已關閉。

然而，問題顯然並未隨之終結。僅在兩天後，全新的後續報告（issue #29876）再度指出，一台搭載 M4 晶片的 MacBook Air 在 Codex 幾乎處於待機空閒狀態時，依然保持每分鐘約 207 MB 的異常寫入，且 code_sign_clone 快取資料夾更暴增至 12 GB。

對於採用板載快閃記憶體、晶片直接銲死在主機板上的現代 MacBook 而言，這類 SSD 的實體磨損是完全不可逆的，使用者無法像傳統電腦般自行拆卸更換硬碟。

可能來自另一個Bug

針對關閉應用程式後系統依舊卡頓的現象，技術專家分析這可能來自另一個尚未解決的獨立 Bug。GitHub 上持續開啟的 issue #25719 顯示，自 6 月 1 日起，Codex 桌面應用程式便會頻繁且異常地觸發 macOS 系統內建的 Gatekeeper 安全防護守護程序。

具體而言，macOS 的系統核心程序 syspolicyd 在 Codex 啟動後，CPU 使用率會異常飆升至 125% 至 200%，記憶體占用量甚至突破 8 GB。由於 syspolicyd 是 macOS 負責驗證軟體簽章與安全性的底層程序，一旦該程序被 Codex 拖垮而進入異常迴圈，即使 Codex 主程式與其輔助程序已完全退出，syspolicyd 依然會持續卡死系統資源。

這也完美解釋了為何使用者關閉 Codex 後 Mac 依然卡頓、必須重新開機才能釋放資源的原因。報告者進一步確認，Codex 內置的「Computer Use」輔助元件本身已完成正確的 Apple 數位簽章與公證，問題極有可能出在應用程式反覆啟動或以不當方式重新驗證組件所致。

針對 SSD 壽命維護與系統卡頓問題，專家建議 Mac 使用者應立即升級至 Codex 最新版本以取得基礎修復。

若發現硬碟寫入量異常，可採用社群提供的臨時解決方案：將 ~/.codex/logs_2.sqlite 設定符號連結（Symbolic Link）至記憶體磁碟（RAM Disk）路徑，避免日誌資料直接刷寫閃存。而面對 syspolicyd 引起的卡頓，在 OpenAI 釋出官方相容性修正檔前，最有效的方式仍是在關閉 Codex 後直接重啟 Mac。目前 OpenAI 官方尚未對最新的系統卡頓反饋發表正式回應。