【2026 最新】Codex 硬碟清理怎麼做？Crashpad 雙路徑盤點、保留 Session 與五步驗收

Mac 硬碟快滿了，Codex 卻還能正常回答，怎麼知道空間去了哪裡？這篇 Codex 硬碟清理教學，帶你先分清診斷檔、對話紀錄與專案，再決定哪些舊檔值得移除。

寫給第一次排查磁碟問題、願意照著終端機操作的讀者。你會完成雙路徑盤點、清理前預覽，以及重啟後的兩項驗收：容量是否再增長、舊對話與工作是否仍可讀。先存好進行中的工作，再開始。

查核截至 2026 年 10 月 18 日。下文整理原始回報、官方文件與 macOS 指令；容量案例屬於回報者的電腦，本文的刪除條件另以臨時假檔案核對，未在讀者的環境重現故障。

先說結論：Codex 硬碟清理＝先認檔案，再清舊診斷，最後量增長

把 Crashpad 想成事故紀錄箱，Session 想成工作筆記，Worktree 想成另一張工作桌。箱子太滿，不代表該把筆記與桌上的作品一起丟掉。清理收回的是空間；是否還在產生事故，要另外觀察。

• 先量兩個已被回報的 Crashpad 路徑，找不到就記「此路徑不存在」，不自己建立。
• 先保存必要樣本、版本與量測時間；退出使用相關框架的 App，再核對背景程序。
• 清理僅限指定 pending 第一層、檔名符合規則、修改時間超過約 48 小時的普通檔案。
• 重啟後用相同時間窗複測，也打開一段舊對話與原專案；兩項都要有紀錄。

為什麼要查兩個路徑？先把回報與通則分開

10 月 16 日的原始社群回報稱診斷檔可能約占 230GB，但作者明說這是以檔案數與約 31,000 個檔案抽樣推估，並非全目錄量完的數字。因此不能把「230GB」當成你的電腦應能釋放的容量。

10 月 17 日的 GitHub 原始留言另列出兩個 Crashpad 目錄，回報合計約 323GB。值得注意：這則環境寫的是 ChatGPT.app 26.1007.71326、macOS 15.7.4，並列出 Codex Framework。它提供雙路徑排查線索，不能被改寫成所有 Codex 版本的共同結果。

另一則 10 月 5 日原始留言特別區分歷史積壓與當天狀態：舊檔很多，當天清理期間佇列卻維持空白。這正是要量兩次的原因；目錄很大，只能證明存了很多，不能單靠它判定現在仍在暴增。

依 Crashpad 設計文件，Crashpad 用於擷取、保存與傳送程序診斷報告。.dmp 是程序狀態的傾印檔；報告可能含記憶體片段與本機資訊。需要提供樣本時，先詢問維護者的私密接收方式，不把原檔貼進公開 Issue。

①「先分抽屜」：版本、診斷檔、Session 與專案分開記

不知道哪一份 App 在運作？先記錄實際開啟的 App 名稱與版本。從該 App 的「關於」畫面抄下版本與 build，再執行下面兩行記下 macOS 與架構。舊回報中的 Codex.app 與現在看到的 ChatGPT.app，要照實分欄。

sw_vers
uname -m

先到「系統設定 → 一般 → 儲存空間」看全機剩餘容量；Apple 說明指出「系統資料」是多類檔案的集合，這個分類名稱本身不能指認是哪一個 App。再用下列唯讀指令，看兩個候選目錄的實際磁碟用量。

date -u '+%Y-%m-%dT%H:%M:%SZ'
for p in \
  "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" \
  "$HOME/Library/Application Support/Codex/Crashpad"
do
  if [ -d "$p" ]; then
    du -sk "$p"
    find "$p" -type f -exec stat -f '%z' {} + |
      awk '{n++; b+=$1} END {printf "files=%d logical_bytes=%.0f\n", n, b}'
  else
    printf 'MISSING: %s\n' "$p"
  fi
done
df -k "$HOME"

du -sk 第一欄以 KiB 列出磁碟用量；stat 加總的是檔案邏輯位元組，兩欄不要混用。df 則觀察家目錄所在檔案系統的可用區塊。APFS、其他 App 寫入與快照，都可能讓刪除量和全機空間變化不同。數百萬小檔案可能量很久；等指令完成再記結果。遇到權限或檔案消失錯誤，保留錯誤，將該輪標成不完整，別填零。

再開一份保留清單。官方故障排查文件列出 Session transcript 位於 $CODEX_HOME/sessions，預設為 ~/.codex/sessions；封存紀錄在 archived_sessions。若有自訂 CODEX_HOME，按自己的實際位置備份。對話檔案只是備份的一部分，不能當成所有設定與狀態的完整還原包。

• 保留：整個實際 CODEX_HOME 的必要備份、認證與設定、Session、封存紀錄及資料庫；這些均不在本篇清理範圍。
• 保留：專案、尚未提交的修改、Worktree 與建置產物。先用 git worktree list 找工作目錄，另做盤點。
• 另列：App 日誌、下載檔與其他快取。看到它們很大，也不擴大下面的刪除範圍。

Worktree 是同一專案的另一份工作目錄，官方 Worktree 文件說明它有自己的檔案與工作狀態。想學會審查與交接，可接著看 Proliferate 的 Worktree 流程；不要把工作桌當成事故紀錄箱。

②「先看水龍頭」：兩次量測，分清積壓與持續新增

空間很大，就表示現在還在壞嗎？保持同一使用情境，做兩次完整盤點。記下第一輪開始與結束時間、兩個路徑各自的 KiB、檔數、logical_bytes；約十分鐘後重跑同一段。期間不要同時清理或更新 App，避免把不同動作混成一個結果。

工作表每個路徑留一列：「App／build、macOS、T0 時間與容量、T1 時間與容量、檔數差、期間做了什麼」。增長率用 （T1 KiB－T0 KiB）÷實際間隔分鐘。十分鐘只是本篇建議的觀察窗，並非官方合格線；有緩慢增長，再補一個較長窗口。

例如，假設某個 pending 從 100,000KiB 變成 102,000KiB，兩次採樣相隔十分鐘，增量就是 200KiB／分鐘。這是教算式的假設數字。若換成你的資料後為零，只能寫「這十分鐘未觀察到淨增長」，不能寫成根因已修好。盤點本身耗時很長時，要保留各輪起訖，不把動態目錄當瞬間快照。

③「先留線索」：退出 App，保存樣本，再預覽清理名單

準備清理前，停止正在執行的工作，正常退出實際使用的 Codex／ChatGPT App。在「活動監視器」搜尋 browser_crashpad_handler，檢查程序的檔案或執行路徑，確認是否仍屬於相關 App。名稱相同不代表都是同一個產品；若相關程序仍在寫入，先重新啟動 Mac，暫不開該 App，再檢查。仍持續寫入就先停在盤點與回報。

用 Finder 的「前往檔案夾」開啟各自的 Crashpad/pending，以修改時間查看。先將少量近期 .dmp 與同名 _sidecar.json 複製到私有備份位置，核對檔案確實可讀；容量吃緊時可用自己的外接磁碟。保留時間、檔名與版本，不公開原始內容。

下面函式可貼到 macOS 終端機的 zsh 或 bash；最後一行只預覽，不刪除。它逐一檢查兩個固定 pending 路徑，實體路徑若與預期不同便拒絕，避免沿符號連結清到別處。只挑第一層普通檔案，且修改時間超過約 2,880 分鐘；保留較新的檔案、子目錄、連結與未知名稱。

crashpad_clean() {
  local mode="${1:-preview}" p real
  case "$mode" in preview|apply) ;; *) return 2 ;; esac
  for p in \
    "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" \
    "$HOME/Library/Application Support/Codex/Crashpad/pending"
  do
    [ -d "$p" ] || continue
    real=$(cd "$p" && pwd -P) || return 1
    if [ "$real" != "$p" ]; then
      printf 'STOP: unexpected physical path: %s\n' "$p"
      return 1
    fi
    printf '%s: %s\n' "$mode" "$p"
    if [ "$mode" = preview ]; then
      find -P "$p" -maxdepth 1 -type f \
        \( -name '*.dmp' -o -name '*_sidecar.json' \) \
        -mmin +2880 -print || return 1
    else
      find -P "$p" -maxdepth 1 -type f \
        \( -name '*.dmp' -o -name '*_sidecar.json' \) \
        -mmin +2880 -delete || return 1
    fi
  done
}
crashpad_clean preview

逐行核對預覽：每個檔案都應位於上述兩個 pending 之一，且是你決定捨棄的舊診斷檔。預覽與執行會重新掃描，所以要保持 App 已退出、目錄無寫入；若清單仍變動，先停下。這個流程不建立「永久停止記錄」的設定，也不修改 Crashpad 權限。

④「只清已確認的舊檔」：Codex 硬碟清理的執行邊界

樣本已留好、預覽範圍正確，而且相關程序已停止後，才在同一個終端機視窗執行下一行。函式內的 -delete 會直接移除符合條件的檔案，不經垃圾桶。若尚未備份需要的診斷，先完成上一節。

crashpad_clean apply

這裡的約 48 小時是保守保留窗，不是 OpenAI 規定的保存期限；因此近期檔案很大時，清完仍可能占空間。此函式也不按 UUID 成組判斷時間：若一組的兩個檔案修改時間不同，可能暫留一個。需要完整成組的診斷樣本，清理前另外保留配對。

遇到 Permission denied 或 Operation not permitted，保留訊息、停止操作。不要為了讓這段教學跑完就加 sudo、改權限或取消系統保護。若占空間的其實是 completed、其他目錄或未知副檔名，先把它列回盤點表，這段函式不處理。

已有 codex-fix 開源工具提供先報告、再以明確旗標套用的流程；本篇核對的 README 將 Crashpad 清理列在其中一個舊路徑。使用前仍要讀你取得的版本與原始碼、比對雙路徑，不把「一鍵全部修復」當本篇步驟。也不需要為這次釋放空間順便更動 SQLite、終止全部 helper 或安裝常駐清理器。

⑤「重新開機驗收」：空間、增長與舊對話分開過關

清完先重跑第一段盤點，記「App 關閉時」結果，再重開實際使用的 App。開一段舊對話，核對最後幾則訊息；開原專案與 Worktree，看未提交修改是否仍在。若原本工作曾因磁碟滿而存檔失敗，保留目錄並不能補回當時未寫入的內容，要逐項核對。

接著在相同工作情境下做下一組 T0／T1。驗收一是空間有沒有收回；驗收二是同一路徑是否再次增加；驗收三是舊工作可讀。可用容量沒立刻同步時，先核對量的是同一檔案系統、其他程式是否在寫入；不要因單一儲存空間圖表未變，就重複刪更多目錄。

如果持續長，就保存「App 名稱與版本／build、macOS、架構、兩個完整路徑、量測時間窗、各自檔數與 KiB 差、是否已退出／重啟」回報。先去 原 Issue比對，或照 官方回饋入口提交；分享前遮掉使用者名稱、專案路徑與敏感紀錄。這份表比只說「吃了很多 GB」更有助定位。

FAQ：Codex 硬碟清理的八個新手問題

1. 看到 230GB，就能釋放同樣多嗎？

不能由那則回報推算。它是個別使用者的抽樣估計；你應記完整掃描結果與實際可用空間變化。

2. 找不到其中一個 Crashpad 路徑怎麼辦？

記「不存在」。版本與使用入口可能不同，不要建立空目錄來配合教學，也不把另一條路徑的結果複製過來。

3. App 還能用，就表示診斷檔正常嗎？

不一定。原始回報就描述前景仍能使用；要看目錄容量、檔數與時間窗。

4. 可以直接刪整個 ~/.codex 嗎？

本篇流程不這樣做。官方列出的 Session 就在 CODEX_HOME 下，還有你需保留的設定與狀態；這裡只處理兩個固定 pending 的指定舊診斷檔。

5. 清完十分鐘沒長，就算修好了嗎？

只能記這段時間未觀察到淨增長。下一次啟動、更新或較長工作後，再用相同表格複測。

6. 把 Crashpad 設成唯讀，是下一步嗎？

先不要把它列入這份清理流程。阻止診斷寫入會改變故障蒐集行為；本篇透過保留樣本、有限清理與回報處理，不修改權限。

7. Session 備份在，就保證對話全部能恢復嗎？

不能據此保證。還要核對 App 內的舊對話、狀態與最後訊息；尤其磁碟滿期間可能有未成功寫入的工作。

8. 還需要查使用額度嗎？

磁碟與額度分開看。前者是檔案占用，後者是服務使用量；若也遇到用量提示，可接著做 Codex 額度稽核。

給新手的三個重點

• 用完整掃描與兩次時間點，取代「抽樣乘上檔數」就當精確容量。
• 診斷檔、Session、Worktree 各有用途；刪除範圍越清楚，越容易驗收。
• 釋放空間與停止增長分開記；後續回報要帶版本、路徑與時間窗。