发布日期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_LOGwarn设置的过滤器只影响终端输出而 app-server 和 TUI 启动时挂载的 SQLite 日志层使用自己的过滤链默认接受所有 TRACE 级别// Codex 源码中的默认配置.with_filter(Targets::new().with_default(Level::TRACE))结果是哪怕你设置了RUST_LOGwarnTRACE 日志依然绕过这个限制每秒持续落盘。每次插入还会更新多个索引加上保留策略的定期删除形成持续的 insert-prune 循环——文件大小看起来稳定在几百 MBSSD 背后承受的写入却在悄悄积累来源GitHub Issue #173202026 年 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.sqliteSQL 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.sqliteSQL 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 typetrigger;看到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|awkNR1 {print $1})diskutil erasevolume HFS CodexRAM$DISKmkdir-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.tomlLinux/tmp 已确认为 tmpfs sqlite_home /tmp/codex-sqlite或者指向更稳的/dev/shmmkdir-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-flCodex|codex|app-serverlsof-nP|grep-E\.codex/.logs_2\.sqlite# 2. 备份后移除安全起见先备份BACKUP$HOME/.codex/logs-backup-$(date%Y%m%d-%H%M%S)mkdir-p$BACKUPmv$HOME/.codex/logs_2.sqlite*$BACKUP/2/dev/nullecho已备份到$BACKUP如果 Time Machine 或 rsync 在备份~/.codex记得排除 WAL 文件--exclude*.sqlite-wal --exclude*.sqlite-shm那些看起来有用、其实没用的方法方案为什么无效RUST_LOGwarn只影响终端输出SQLite 日志层独立过滤TRACE 照写不误[feedback] enabled false只禁用反馈上传日志写入层不受影响定期清理旧行 VACUUM能回收文件空间但不阻止新写入SSD 写放大依然存在常见问题Q我的 SSD 已经因此损耗了怎么评估损失在 macOS 用smartmontoolsbrew install smartmontools然后运行smartctl -a /dev/disk0看Total bytes written字段。对比购买时的 TBW 规格可以算出剩余寿命百分比。Linux 用nvme-clisudo nvme smart-log /dev/nvme0看Data Units Written单位 512B。Q关掉 trigger 后Codex 还能正常用吗可以。Trigger 只阻断日志写入不影响 Codex 的代码生成、Agent 任务、会话管理等核心功能。唯一损失是 SQLite 里不再保存运行日志调试时无法通过sqlite3查历史记录。QOpenAI 官方会修复这个问题吗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-referenceCodex 官方文档 — 环境变量GitHub openai/codex Issue #173201996fanrui提交2026-06-14多模型接口统一管理七牛云 AI 大模型广场本文方案基于 2026 年 6 月 30 日 Codex 版本官方修复后建议优先采用官方方案。