问题有多严重？

这个问题的核心是 Codex 的日志记录功能出现了严重配置错误。

• 疯狂的写入量：有用户在连续运行 Codex 21天后，发现 SSD 竟承受了约 37TB 的写入量。按此推算，一年写入量将高达 640TB。

• 远超SSD寿命极限：目前主流的 1TB 消费级 SSD，其总写入字节数（TBW）通常在 600TB 左右。这意味着，如果放任不管，Codex 这个 Bug 可以在不到一年的时间内，就把一块全新的 1TB SSD 写“废”掉。

为什么会出现这个问题？

问题根源在于 Codex 的日志模块默认开启了 TRACE 级别的日志记录。

• TRACE 是最“吵闹”的级别：它会事无巨细地记录程序运行的每一个底层细节，比如原始的 WebSocket 数据包、文件读写操作等。据统计，其中约 71% 都是对普通用户毫无用处的冗余信息。

• 无法通过常规方式关闭：更麻烦的是，Codex 忽略标准的 RUST_LOG 环境变量，用户无法通过常规方法调低日志级别。

• “写入放大”效应：SQLite 数据库频繁进行小块数据的插入和删除，会导致SSD实际物理写入量远超逻辑写入量，进一步加剧了损耗。

如何解决？

在 OpenAI 官方发布修复补丁之前，你可以采取以下紧急措施来保护你的 SSD：

1. 查看是否安装sqlite3

打开终端（Windows 上是 CMD 或 PowerShell，macOS/Linux 上是“终端”应用），输入以下命令并回车：

sqlite3 --version

• 如果已安装：系统会显示 SQLite 的版本号，例如 3.39.5 2022-10-14 20:42:19...。

• 如果未安装：系统会提示类似 'sqlite3' 不是内部或外部命令 (Windows) 或 command not found (macOS/Linux) 的错误信息。

如果有可以直接跳过这部分

如果未安装怎么办？

如果结果显示未安装，你需要先安装 sqlite3 命令行工具：

• macOS：如果你安装了 Homebrew，可以在终端执行 brew install sqlite3。

• Linux (Debian/Ubuntu)：在终端执行 sudo apt install sqlite3。

• Windows：需要从 sqlite官方下载 sqlite3.exe 文件

sqlite官方：https://www.sqlite.org/download.html

根据自己的系统选择安装 一般都是 64的

​

解压这个sqlite3.exe

​

然后复制到c盘下的windows目录

​

然后打开黑窗口 win+R 输入 cmd

sqlite3 --version

​

2.解决问烧盘问题

1.先关闭codex

2.Windows (在 PowerShell 中执行):

sqlite3 "$env:USERPROFILE\.codex\logs_2.sqlite" "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

2.macOS / Linux (在终端中执行):

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

执行后，触发器会立即生效，无需重启 Codex 或电脑。

注意：仅供参考，不代表事实，此问题是从卫新公众号得知，我也是codex的用户，解决问题后想分享自己的经验，帮助大家一起解决。

如果有需要token的可以看看这个  https://apical.top