发布日期：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*

# 查看日志级别分布，确认是否有大量 TRACE
sqlite3 ~/.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 Disk
DISK=$(hdiutil attach -nomount ram://2097152 | awk 'NR==1 {print $1}')
diskutil erasevolume HFS+ CodexRAM "$DISK"
mkdir -p /Volumes/CodexRAM/codex-sqlite

# 用 RAM Disk 运行 Codex
CODEX_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 是否为 tmpfs
findmnt /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-sqlite
CODEX_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/null
echo "已备份到 $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 版本，官方修复后建议优先采用官方方案。