Codex 正在悄悄写穿你的 SSD：完整排查与修复指南
发布日期：2026-06-30 | 数据来源：OpenAI Codex 官方文档、GitHub Issue、社区实测
OpenAI Codex CLI 存在一个静默的 SSD 写入问题：它默认将 TRACE 级网络事件持续写入~/.codex/logs_2.sqlite数据库，21 天内可产生约37TB写入量，年化约640TB——超过主流 1TB 消费级 SSD 的标称全生命周期写入寿命（约 600TBW）。问题由 Apache Flink PMC 成员@1996fanrui于 2026 年 6 月在 GitHub 提交缺陷报告后引发广泛关注。本文提供从诊断到根治的完整操作步骤，包括立即止血方案、官方配置迁移方法，以及 macOS RAM Disk 和 Linux tmpfs 的正确用法。
为什么会这样？根本原因
Codex 内部使用了两条独立的日志过滤链。
用户通过RUST_LOG=warn设置的过滤器，只影响终端输出；而 app-server 和 TUI 启动时挂载的 SQLite 日志层使用自己的过滤链，默认接受所有 TRACE 级别：
// Codex 源码中的默认配置.with_filter(Targets::new().with_default(Level::TRACE))结果是：哪怕你设置了RUST_LOG=warn，TRACE 日志依然绕过这个限制，每秒持续落盘。每次插入还会更新多个索引，加上保留策略的定期删除，形成持续的 insert-prune 循环——文件大小看起来稳定在几百 MB，SSD 背后承受的写入却在悄悄积累（来源：GitHub Issue #17320，2026 年 6 月）。
受影响的文件是这三个：
~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm第一步：先诊断，确认你中招了没
# 查看文件大小（超过几百 MB 就要警惕）ls-lh~/.codex/logs_2.sqlite*# 查看日志级别分布，确认是否有大量 TRACEsqlite3 ~/.codex/logs_2.sqlite\"SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC;"# 找出写入量最高的来源（前 20 条）sqlite3 ~/.codex/logs_2.sqlite<<'SQL' SELECT target, level, COUNT(*) AS n FROM logs GROUP BY target, level ORDER BY n DESC LIMIT 20; SQL如果 TRACE 行数以百万计，说明问题严重，立即执行下面的方案。
方案一：SQLite Trigger 立即止血（推荐先做）
最快的临时方案。先完全退出 Codex，再执行：
sqlite3 ~/.codex/logs_2.sqlite<<'SQL' CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END; SQL验证是否生效：
sqlite3 ~/.codex/logs_2.sqlite\"SELECT name FROM sqlite_master WHERE type='trigger';"看到block_log_inserts即代表成功。之后新启动的 Codex 将不再向该文件写入日志。
⚠️ 注意：Codex 版本升级后需重新检查 trigger 是否还存在，升级有可能重建数据库文件。
方案二：把 SQLite 迁走（官方配置，长期有效）
这是 Codex 官方文档提供的正规路径——通过sqlite_home配置项，把数据库整体迁移到其他位置（外置硬盘、HDD、或内存盘）。
方式 A：写进配置文件（永久生效）
# ~/.codex/config.toml sqlite_home = "/Volumes/ExternalDisk/codex-sqlite"方式 B：环境变量（单次生效，适合测试）
CODEX_SQLITE_HOME=/path/to/other/disk codex⚠️sqlite_home会迁移所有SQLite 状态，包括 state、logs、goals、memories，不只是日志。迁移前确认目标路径可写且空间充足。
方案三：macOS RAM Disk（内存当硬盘用）
把 SQLite 文件放进内存盘，写入全在内存里完成，SSD 完全不受影响。代价是重启后数据清空，适合不需要跨会话保留日志的场景。
# 创建约 1 GiB RAM DiskDISK=$(hdiutil attach-nomountram://2097152|awk'NR==1 {print $1}')diskutil erasevolume HFS+ CodexRAM"$DISK"mkdir-p/Volumes/CodexRAM/codex-sqlite# 用 RAM Disk 运行 CodexCODEX_SQLITE_HOME=/Volumes/CodexRAM/codex-sqlite codex# 用完后卸载hdiutil detach /Volumes/CodexRAM一个常见误区：macOS 的/tmp不是tmpfs，软链到/tmp对保护 SSD 毫无意义。验证你的/tmp是否在内存：
df-h/tmp# Filesystem 如果是 /dev/disk，就是 SSD，不是内存方案四：Linux tmpfs（前提是先确认挂载）
Linux 下/tmp通常是 tmpfs（内存文件系统），但不是所有发行版都默认如此。先确认：
findmnt /tmp# 看 FSTYPE 是否为 tmpfsfindmnt /dev/shm# /dev/shm 通常一定是 tmpfs确认是 tmpfs 后，再通过配置文件或环境变量把sqlite_home指向它：
# ~/.codex/config.toml（Linux，/tmp 已确认为 tmpfs） sqlite_home = "/tmp/codex-sqlite"或者指向更稳的/dev/shm：
mkdir-p/dev/shm/codex-sqliteCODEX_SQLITE_HOME=/dev/shm/codex-sqlite codex同时关掉 history 持久化（附加减量）
除了 SQLite 问题，Codex 还会把会话记录写进history.jsonl。不需要保留历史时可以关掉，并限制文件大小上限（来源：Codex 官方配置文档，2026 年）：
# ~/.codex/config.toml [history] persistence = "none" # 关闭 session 记录 max_bytes = 10485760 # 或限制为 10MB 上限两项结合，可以把 Codex 在~/.codex目录下产生的写入量降到最低。
安全清理已有日志
别直接删~/.codex整个目录——里面有你的登录凭据和配置文件。只删日志：
# 1. 先确认 Codex 已完全退出pgrep-fl'Codex|codex|app-server'lsof-nP|grep-E'\.codex/.+logs_2\.sqlite'# 2. 备份后移除（安全起见先备份）BACKUP="$HOME/.codex/logs-backup-$(date+%Y%m%d-%H%M%S)"mkdir-p"$BACKUP"mv"$HOME/.codex"/logs_2.sqlite*"$BACKUP"/2>/dev/nullecho"已备份到$BACKUP"如果 Time Machine 或 rsync 在备份~/.codex，记得排除 WAL 文件：
--exclude='*.sqlite-wal' --exclude='*.sqlite-shm'那些看起来有用、其实没用的方法
| 方案 | 为什么无效 |
|---|---|
RUST_LOG=warn | 只影响终端输出，SQLite 日志层独立过滤，TRACE 照写不误 |
[feedback] enabled = false | 只禁用反馈上传，日志写入层不受影响 |
| 定期清理旧行 + VACUUM | 能回收文件空间，但不阻止新写入，SSD 写放大依然存在 |
常见问题
Q：我的 SSD 已经因此损耗了，怎么评估损失？
在 macOS 用smartmontools（brew install smartmontools），然后运行smartctl -a /dev/disk0，看Total bytes written字段。对比购买时的 TBW 规格，可以算出剩余寿命百分比。Linux 用nvme-cli：sudo nvme smart-log /dev/nvme0，看Data Units Written（单位 512B）。
Q：关掉 trigger 后，Codex 还能正常用吗？
可以。Trigger 只阻断日志写入，不影响 Codex 的代码生成、Agent 任务、会话管理等核心功能。唯一损失是 SQLite 里不再保存运行日志，调试时无法通过sqlite3查历史记录。
Q：OpenAI 官方会修复这个问题吗？
GitHub Issue #17320 已标记为bug，截至 2026 年 6 月 30 日尚未关闭。从根本修复的角度，需要在 SQLite 日志层加入独立的 level 过滤，或默认将日志级别从 TRACE 提升到 WARN。在官方修复前，sqlite_home迁移方案是最稳妥的长期解决方式。
Q：用多个 AI 编程工具，有没有统一管理的办法？
Codex 用的是标准 OpenAI SDK 接口，Claude Code 用的是 Anthropic 格式。如果需要在两者之间灵活切换模型（比如 Codex 做安全审查、Claude Code 做业务逻辑），可以通过七牛云 AI 统一接入——兼容 OpenAI 和 Anthropic 双格式，一套 API Key 管理多个工具，不用每个工具单独配置鉴权。
权威来源：
- Codex 官方配置文档 — config-reference
- Codex 官方文档 — 环境变量
- GitHub openai/codex Issue #17320（
@1996fanrui提交，2026-06-14）- 多模型接口统一管理：七牛云 AI 大模型广场
本文方案基于 2026 年 6 月 30 日 Codex 版本，官方修复后建议优先采用官方方案。