# 策展 · X (Twitter) 🔥🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Kai (@hqmank) · 平台：X (Twitter) · 日期：2026-06-23

> 原始來源：https://x.com/hqmank/status/2069020259097735231

## 中文摘要

Codex 透過 SQLite 頻繁寫入大量無用日誌，導致使用者 SSD 壽命加速耗損。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/75c0c4c7f1233cde.jpg)
> 一張展示 Codex 軟體圖示與帶有 MP600 ELITE 字樣的固態硬碟硬體，並輔以程式日誌背景的技術示意圖。

**問題核心**
開發者 hqmank 指出，Codex 軟體（包含 CLI、桌面版及 VSCode plugin）存在嚴重的過度寫入問題。即使在閒置狀態下，Codex 也會持續將大量 `TRACE` 等級的診斷日誌寫入 `~/.codex/logs_2.sqlite` 資料庫。這些日誌包含大量無用的內部垃圾資訊，雖然檔案本身體積看似不大，但由於 SQLite 的寫入機制，底層會不斷進行磁碟刷新，導致 SSD 在短時間內承受巨大的寫入負載。

**實際影響**
根據 hqmank 的觀察，僅僅幾天的輕度使用，就產生了超過 78,000 筆 `TRACE` 紀錄，累積約 628 MB 的無用日誌。引用來源中的 GitHub 專案問題回報（Issue #28224）更進一步量化了此問題的嚴重性：
- 該日誌寫入量推算每年可達 640 TB，對於一般 1 TB 的消費級 SSD 而言，這意味著不到一年就會耗盡其保固內的寫入壽命（TBW）。
- 透過監測發現，該日誌系統存在嚴重的「寫入放大」現象，在 15 秒內即可插入超過 36,000 筆資料，隨後又立即刪除，導致磁碟不斷進行無效的寫入與索引更新。

**解決方案**
由於官方針對此問題的修復進度緩慢（儘管 GitHub 討論區顯示官方已於 2026 年 6 月 22 日合併了兩項 PR 以過濾部分日誌），hqmank 提供了一個立即可用的指令，透過在 SQLite 資料庫中建立觸發器（Trigger）來強制攔截並丟棄所有新的日誌寫入，且不會影響正常的對話功能：

1. 開啟終端機並執行以下指令，將規則寫入日誌資料庫：
   ```bash
   sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
   ```
2. 執行後，該資料庫將不再接收任何新的寫入請求，從而保護 SSD 免受持續的損耗。

**官方後續**
根據 GitHub 上的更新，官方開發者 jif-oai 已合併了 `Stop logging every Responses WebSocket event`（PR #29432）與 `Filter noisy targets from persistent logs`（PR #29457），據稱可減少約 85% 的日誌寫入量，該 Issue 目前已關閉。建議使用者確認軟體版本更新，或視需求採取上述的觸發器手段進行防護。

## 標籤

Codex, CLI, IDE, 硬體, 其他, Codex