OpenAI 的 AI 編碼工具 Codex 桌面版應用程式在 Mac 上出現嚴重錯誤，導致錯誤報告（Crashpad dumps）無限累積，佔用大量硬碟空間。有用戶回報這些檔案高達數百 GB，甚至佔據了硬碟總容量的 35%。儘管 OpenAI 表示已合併修復，但用戶仍需手動檢查並清理，以避免硬碟被塞滿。
10 月 17 日，一位 Mac 用戶在 Codex 的 GitHub 問題追蹤器中新增了一張表格，該問題自 6 月 2 日以來一直存在。表格顯示，兩個錯誤報告資料夾內約有 400 萬個檔案，總計約 323 GB。該用戶寫道：「這大約佔了我 926 GB 硬碟的 35%，在我發現之前，可用空間一度只剩下 1.4 GB。」
該問題的標題簡潔地描述了這個錯誤：「Codex 桌面版持續生成 Crashpad 待處理的錯誤傾印，且無限制地增長：每天至少增加 5GB。」LavX News 在 10 月 18 日報導了此事。如果您在 Mac 上運行 Codex 桌面應用程式，花幾分鐘檢查自己的硬碟是值得的，所有下方連結的報告都與 macOS 上的桌面應用程式有關，我個人尚未在自己的機器上重現此問題。
這些數字來自問題追蹤器和 OpenAI 論壇的用戶報告，並非 OpenAI 的官方測量數據。最初的報告於 6 月 2 日提出，一天內就累積了 4.9 GB 和 54,504 個檔案。針對應用程式版本 26.727.51351 提出的問題 #36982 估計增長速度約為「每天 17GB」。
9 月 23 日在 macOS 15.2 上開啟的問題 #47466 報告稱，該資料夾約為 511 GB，應用程式開啟時大約每秒生成一個約 160 KB 的迷你錯誤傾印。10 月 6 日的問題 #51361 報告了 130.53 GiB 的數據，剩餘約 821 MiB 的可用空間，並因「裝置空間不足」導致暫存檔案寫入失敗。
10 月 8 日的問題 #52194 報告了約 168 GB 和約 197 萬個檔案。10 月 16 日的一篇論壇貼文估計錯誤報告約為 230 GB。10 月 17 日的評論指出了其建置版本：ChatGPT.app 26.1007.71326。
在這種情況下，應用程式仍能正常運作，第一位報告者指出它仍然可用，這也是為什麼資料夾可以在數週內不斷增長而沒有人發現的原因。
Crashpad 是 Chromium 專案的錯誤報告工具，它是一個「用於捕獲、儲存和傳輸事後錯誤報告的函式庫」。其資料庫儲存著「待上傳的錯誤傾印」，這些就是待處理資料夾中的檔案。目前主要的解釋來自用戶，而非 OpenAI。
在 #25921 中，一位報告者發現每個錯誤傾印都是關於錯誤處理程式本身，即 browser_crashpad_handler，還有幾位用戶也引用了相同的啟動失敗。其對 mach_port_request_notification 的呼叫返回「(os/kern) invalid capability (20)」，檢查失敗並顯示 Check failed: kr == KERN_SUCCESS.，然後該程序終止。
它會重新啟動，再次失敗，並寫入另一個錯誤傾印。#36982 的標題總結了這一點：處理程式「啟動 2 毫秒後 SIGTRAPs，launchd 重新生成它」。#25921 中的一位評論者報告說，在 macOS Tahoe 26.3.1 上的其他 Chromium 和 Electron 應用程式中也出現了相同的錯誤。
問題的後半部分是沒有任何機制來清理該資料夾。Crashpad 的設計文件指出：「資料庫儲存可配置數量的錯誤傾印，並有可配置的最大總大小。」#25921 中的一位評論者表示，該應用程式沒有使用 Crashpad 的清理器。問題 #51361 要求 OpenAI 預設開啟儲存限制和清理功能，目前該問題仍未解決且沒有指派負責人。
部分問題可能已修復。10 月 6 日，一位儲存庫貢獻者在 #47466 中寫道：「這似乎是較舊 Mac 核心的問題。」在同一評論中：「一個修復程式已經合併，並將很快發布。」該問題於當天關閉。10 月 7 日，一位用戶詢問哪個已發布的版本包含此修復，以及它是否會清理已經非常龐大的佇列。該討論串中沒有出現答案。
更早之前，在 6 月 14 日，一位貢獻者在 #25921 中寫道：「我認為這在較新的 macOS 版本中已修復，至少在 26.5 版本中是如此。」然而，後來在 macOS 26.0 到 26.3 上報告的用戶仍然看到增長，而 #47466 的報告來自 macOS 15.2。
10 月 17 日的報告是在建置版本 26.1007.71326 上，運行 macOS 15.7.4。該討論串沒有說明該建置版本是否包含 10 月 6 日的修復。#25921 仍然開放。
來自 #52194 的另一個數據點是：該報告者發現有兩個來自舊框架版本的處理程式程序仍在運行，儘管該版本已不在磁碟上。終止這些程序並沒有幫助，對他們來說，重新啟動 macOS 停止了這個循環。
檢查您的 Mac：問題追蹤器列出了兩個位置：一個較舊的，一個較新的。使用 du 測量兩者：
cd ~/Library/"Application Support"
du -sh Codex/Crashpad/pending \ com.openai.codex/web/Crashpad/pending 2>/dev/null
如果結果以 GB 為單位，則表示錯誤傾印正在堆積。要查看它是否仍在增長，請使用 find 計算檔案數量，並在應用程式開啟的情況下，間隔一分鐘測量兩次。這從同一個資料夾運行。如果 com.openai.codex/web/Crashpad/pending 是大的那個，請替換該路徑：
find Codex/Crashpad/pending -type f | wc -l
du -sh Codex/Crashpad/pending ; sleep 60
du -sh Codex/Crashpad/pending
然後檢查是否有處理程式程序正在運行：
pgrep -lf browser_crashpad_handler
如果資料夾很大，請先退出應用程式。#52194 的報告者表示，OpenAI 支援人員告訴他們在應用程式關閉時清除待處理的報告。在您刪除時，一個正在運行的處理程式會不斷添加新的錯誤傾印。由於有數百萬個檔案，rm pending/* 會失敗，因為 shell 會將每個名稱展開為一個參數列表。find -delete 會遍歷資料夾：
cd ~/Library/"Application Support"
find Codex/Crashpad/pending -type f -delete
如果 com.openai.codex/web/Crashpad/pending 也很大，請對其運行相同的命令。然後重新啟動，這在 #52194 中是有效的，重新開啟應用程式並再次運行增長檢查。如果資料夾仍在增長，#25921 中的用戶會設定定時器進行清理，直到修復版本發布。這會刪除超過 24 小時的錯誤傾印：
find Codex/Crashpad/pending -type f -mtime +0 -delete
一些評論者使用 chmod 將 pending 設為唯讀。其他人警告說，這也會阻止真正的錯誤報告傳送給 OpenAI，因此如果您這樣做，請在更新後撤銷。任何您發布的本地佇列都需要設定上限，一個只有在成功上傳時才會清空的資料夾就是一個佇列。當消費者從不運行時，佇列會一直增長直到磁碟滿載，而應用程式中卻沒有任何異常。
Crashpad 已經有兩個可以限制此問題的限制：計數和總大小，它們必須被設定。這同樣適用於您自己的工具寫入的內容：代理記錄、重試佇列、偵錯日誌、錯誤報告。為每個設定大小限制和時間限制，並讓它在磁碟快滿時減少寫入，這正是 #51361 要求 Codex 執行的。
如果您覺得這篇文章有用，我正在開發 Hermes IDE，它是一個適用於 macOS、Windows 和 Linux 的開源整合開發環境，可以為每個任務提供獨立的分支和工作樹，讓 AI 代理不會互相干擾。一個沒有限制且消費者從不運行的佇列是一個經典的系統設計失敗，它不僅僅出現在錯誤報告工具中。
《系統設計袖珍指南：基礎》涵蓋了像這樣的故事背後的構建塊，從速率限制到可用性，以防止一個卡住的組件拖垮整個系統。
覺得值得一看？分享給朋友。
以上為 AI 自動翻譯導讀。原文版權歸 DEV Community (Codex) 所有， 建議透過「閱讀原文」前往原始網站，以取得最完整資訊並支持原作者。
43 個來源、每 2 小時更新，太多看不完。電子報每週挑最值得看的幾則，附上 Max 的看法。
