Codex 用了一个月，SSD 少了 4.8TB——AI 编程工具暗藏的 5 个资源陷阱与终极方案

上周帮一个朋友排查电脑变慢的问题。他的 MacBook Pro 是顶配——M4 Max、64GB 内存、1TB 固态，买了不到半年，最近却卡得连 Chrome 都打不开。

我打开活动监视器一看，磁盘写入量显示「1.5 PB」。对，你没看错，1.5 PB——1500 TB。一块全新 1TB 固态的 TBW（总写入字节数）标称值通常只有 600 TB，他的硬盘已经被写废了 2.5 轮。

什么软件能在半年内吃掉 1.5 PB 的写入寿命？我顺着一查，找到了元凶——OpenAI Codex CLI。

这不是个例。过去一个月，从 GitHub、V2EX 到 Twitter，大量用户现身说法：Codex 桌面端在后台疯狂写日志，有人一个月 SSD 写入量暴增 4.8 TB，有人 21 天测出 37 TB 累计写入，折合全年 640 TB——正好超过主流消费级 SSD 的 TBW 上限。

我自己的机器也没幸免。装 Codex 两个月，查了一下 SSD 的 SMART 数据，累计写入量 56 TB。我过去两年所有开发工作加起来，写入量都没这么大。

下面是我花了三天时间排查、验证、解决的全过程，加上过程中发现的另外 4 个隐藏资源陷阱。

第一个坑：日志风暴——TRACE 级别的无差别轰炸

症状

电脑莫名其妙变卡，风扇狂转，SSD 的健康度每个月掉几个百分点。

排查过程

一开始我以为是 Spotlight 索引或者 Time Machine 备份的问题。关了这两样，写入量没降。打开 iStat Menus 看实时磁盘活动，发现 ~/.codex/ 目录下有一个叫 logs_2.sqlite 的文件，每秒钟都在写入，峰值时每秒 50 MB。

用 lsof 确认了是 Codex 的进程在写：

lsof ~/.codex/logs_2.sqlite
# COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
# codex 1234 ubuntu … REG 1,2 2147483648 … logs_2.sqlite

这个 SQLite 数据库文件已经膨胀到了 2 GB，而且还在持续增长。

根因

Codex CLI 内置了一个基于 SQLite 的诊断日志组件，默认启用了 TRACE 级别的日志输出。TRACE 是日志体系里最详细、最啰嗦的级别——它会把程序做的每一件小事都记下来，包括：

• 每一次 WebSocket 连接和断开的原始数据包
• 每一次系统文件读取操作（比如读取 /etc/passwd、/etc/ld.so.cache 这些常规操作）
• 每一个内部函数调用的进出时间
• 每一条环境变量读取记录

GitHub 用户 1996fanrui 在 6 月 14 日提交了详细的分析报告。他统计发现，71% 的 TRACE 日志记录的都是底层冗余信息，对普通用户没有任何调试价值。更离谱的是，Codex 完全忽略了标准的 RUST_LOG 环境变量设定，用户无法通过常规手段降低日志级别。

数据有多夸张

临时解决方案

在 OpenAI 正式修复之前（GitHub Issue #23340 和 #23722 已经被标记为高优先级），可以通过创建符号链接将日志文件重定向到内存文件系统：

# 把日志文件指向 /tmp（内存文件系统）
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
ln -s /tmp/codex-logs.sqlite ~/.codex/logs_2.sqlite

为什么这么做：

• /tmp/ 目录挂载在内存上（tmpfs），所有写入操作变成内存操作
• 这个日志文件只存底层运行记录，不保存用户对话数据
• 设备重启后日志丢失，但不影响 Codex CLI 正常运行

验证是否生效：

# 确认链接
ls -la ~/.codex/logs_2.sqlite
# 输出：~/.codex/logs_2.sqlite -> /tmp/codex-logs.sqlite

# 监控写入量（macOS）
sudo fs_usage -w -f filesys | grep codex

# Linux
iostat -x 1 | grep codex

你也可以在 Codex 的配置文件中手动设置日志级别（如果版本支持）：

# 检查是否支持环境变量
CODEX_LOG=error codex

第二个坑：WebSocket 的无底洞——150GB 流量去哪了

后面还有N个类似的坑，每一个都让我怀疑人生——【关注后查看完整避坑手册】

症状

Codex 桌面端装了一个月，宽带账单涨了 100 多块。

排查过程

打开系统的网络监控面板，发现 Codex 进程在过去 30 天消耗了 150 GB 的上行+下行流量。日均 5 GB——相当于全天候挂着 YouTube 4K 视频。

根因

很多人以为 Codex 就是「帮你写代码的 AI 助手」，跟 Copilot 一样轻量。但 Codex 桌面端实际上是一个完整的 Electron 应用 + 云端沙盒环境。

它的实时通信通道是 WebSocket 长连接，这意味着：

更关键的是，Codex 的设计哲学是「始终在线」。你即使没有在主动使用它，它也在后台干这些事：

• 保持 GitHub 代码审查的实时同步
• 维护任务队列状态
• 处理 MCP 服务器的连接
• 支持从手机端远程操控（Remote Control）
• 持续索引你的项目文件

对比 Claude Code

同样的事情，Claude Code 就没有这个问题。原因很简单——它们是两种不同的产品形态：

有个 Reddit 调查挺有意思：500 多名开发者中，65% 日常更偏好 Codex（因为「丢进去就不用管了」），但盲测代码质量时，67% 的人认为 Claude Code 的输出更干净。

这引出了一个更深层的思考——AI 编程工具越来越「重」，这个趋势值得警惕。

流量控制方案

# 限制 Codex 的带宽使用（Linux/macOS）
# 用 cgroups 或者 network link conditioner 限速

# 监控实时流量
nethogs | grep codex

# 禁止后台网络（如果不需要 Remote Control）
# 在 Codex 设置中关闭 "Background Sync"

第三个坑：云端沙盒的执行模型——代码上下文反复上传

症状

每次提交任务，Codex 都要「思考」很久。你以为它在推理，其实它在上传数据。

根因

Codex 的核心设计是「云端沙盒执行」。每次提交一个编码任务，它的流程是：

每一轮交互都在上传下载大量数据。如果你同时开了多个并行任务（Codex 支持最多 8 个并行 Agent），数据量要乘以并发数。

实测数据

一个中等规模的 React 项目（约 10 万行代码），每次重构操作上传的上下文约 50-100 MB。一次完整的 PR 评审流程，需要 20-30 轮交互。 一个月下来，仅此一项就能吃掉 30-60 GB 流量。

对比 Claude Code： 所有代码操作都在本地执行，只传输 prompt 和 response。同样一个复杂重构任务，有开发者实测：Claude Code 花了 155 美元的 API 费用，Codex 只花了 15 美元——Codex 的 token 效率约是 Claude Code 的 4 倍。但 Token 效率高 ≠ 资源消耗低。Codex 通过「拆小步、多轮次」减少了单次 token 开销，却把网络和磁盘的开销转移到了用户端。

第四个坑：Electron 的内存黑洞

症状

Codex 打开后什么都不干，内存占用 800 MB+。

排查过程

# 查看 Codex 的 RSS（Resident Set Size）
ps aux | grep -i codex | awk '{print $6 " " $11}'
# 输出示例：845632 ./codex-desktop
# 845632 KB ≈ 826 MB

更夸张的是，如果开启 8 个并行 Agent，每个 Agent 都要维持自己的 WebSocket 连接和上下文缓存，总内存占用可以轻松突破 4 GB。

根因

Codex 是基于 Electron 的桌面应用。Electron 本身就要加载 Chromium 引擎（约 200-300 MB），再加上 Codex 的业务逻辑、本地索引服务、WebSocket 连接池、项目文件缓存——800 MB 是起步价，重度使用 3-4 GB 很正常。

优化方案

# 限制 Electron 的 GPU 进程（Codex 不需要 GPU 渲染）
codex –disable-gpu –disable-software-rasterizer

# 或者彻底退出后台进程，需要时再启动
# 写一个 shell 函数
codex-on-demand() {
pgrep -x codex-desktop || codex &
codex "$@"
}

第五个坑：日志滚雪球——从 2 GB 到 67 GB 的 GitHub Issue 史

症状

磁盘空间莫名其妙少了 60 GB，查了一圈发现都是日志。

深度排查

这不是单个问题的爆发，而是一连串 bug 的累积效应。GitHub 上相关的 issue 从 5 月开始就没有断过：

• #23159：/goal 命令 + 配额耗尽导致 TUI 无限循环
• #23179：/goal 无限复制 usage-limit 错误消息
• #22818：5 小时时间限制触发后，Agent 继续运行，不断重试
• #23340：/goal 长循环产生单行 480 KB 的日志——一天写 34 GB
• #23722：重试循环把 codex-tui.log 撑到 67 GB
• #24682：TUI 日志又到 92 GB

5 月 20 日有人报 codex-tui.log 长到 67 GB，5 月 27 日就有人报另一个位置的日志 92 GB。看起来修了一个，另一个又冒出来。

根源

这些问题的共同模式是：错误 → 重试 → 写日志 → 继续错误 → 继续写日志。一旦触发某个边界条件（配额用完、时间限制、连接断开），Codex 的重试机制不是优雅降级，而是疯狂重试，同时把每一次重试的记录都写入日志文件。

# 简化版的「死亡螺旋」
while True:
try:
result = execute_task()
return result
except UsageLimitError:
log("Usage limit exceeded, retrying…") # 写入日志
sleep(5)
# ❌ 没有检查重试次数，没有指数退避
# ✅ 应该：if retries > MAX: break

完整监测方案

#!/bin/bash
# check-codex-resources.sh
# 放进 cron，每天检查一次

echo "=== Codex 资源监测 ==="
echo ""

# 1. 查日志大小
echo "📁 日志文件大小:"
du -sh ~/.codex/logs_2.sqlite 2>/dev/null || echo " (不存在)"
du -sh ~/.codex/codex-tui.log 2>/dev/null || echo " (不存在)"

# 2. 查 SSD 写入（需要 smartmontools）
if command -v smartctl &> /dev/null; then
echo ""
echo "💾 SSD 健康度:"
sudo smartctl -A /dev/nvme0n1 | grep -E "Percentage Used|Data Units Written"
fi

# 3. 查 Codex 进程内存
CODE_MEM=$(ps aux | grep -i codex | grep -v grep | awk '{sum+=$6} END {printf "%.0f MB", sum/1024}')
echo ""
echo "🧠 Codex 内存占用: $CODE_MEM"

# 4. 查日志增长速度
if [ -f ~/.codex/logs_2.sqlite ]; then
SIZE_YESTERDAY=$(stat -f "%z" ~/.codex/logs_2.sqlite 2>/dev/null || stat –format="%s" ~/.codex/logs_2.sqlite 2>/dev/null)
SIZE_NOW=$(du -b ~/.codex/logs_2.sqlite 2>/dev/null | cut -f1)
echo ""
echo "📊 建议: 如果日志大于 1GB，请执行符号链接方案"
fi

避坑总结

优先级方案

为什么 OpenAI 还没修

截至写这篇文章时（2026 年 7 月 1 日），相关的 GitHub issue 已经提交了三周。OpenAI 官方确认了问题并标记为高优先级，但还没有发布正式修复。

一个可能的原因是：这不是一个简单的 bug 修复，而是涉及 Codex 的日志基础设施重构。 要用标准日志库替换当前的 SQLite+TRACE 方案，还要确保不破坏现有的调试能力——对一个大体量的 Electron 应用来说，这需要时间。

但在官方修复出来之前，你的 SSD 每一秒都在被蚕食。

最终的思考

这次排查让我想明白一件事。Codex 的 SSD 写入问题、150 GB 流量问题、67 GB 日志问题——它们不是孤立 bug，而是同一个设计选择在不同维度的表现。

Codex 选择了「云端执行 + 始终在线 + 全面日志」的产品哲学。这给它带来了更省心的用户体验、更高的 token 效率、更强的并行能力。代价是——这些资源消耗从 OpenAI 的账单转移到了用户的硬盘、网络和内存上。

Claude Code 选择了另一条路：本地执行、用完即走、保持轻量。它在用户端几乎零消耗，但 token 开销更大。

没有绝对正确的选择。但如果你看到了 150 GB 流量和 4.8 TB 磁盘写入这些数字，至少应该知道一件事：你的 AI 编程工具正在以你未曾注意的方式，静默地消耗你的硬件寿命。 趁还来得及，把那行 ln -s 命令跑了吧。

延伸阅读：AI编程CLI代理踩坑实录：部署Codex CLI和Goose时遇到的7个致命问题、AI编程Benchmark 90%≠能上线——企业级项目用Cursor和Claude Code踩的4个真实坑

📌 系列文章

• 阿里 Qoder 1.0 上手：当 AI IDE 进化成"自动驾驶"开发台，程序员该慌还是该爽？

这个系列会持续更新，点个关注 不错过下一期。你还想了解什么？评论区告诉我。