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环境变量设定用户无法通过常规手段降低日志级别。数据有多夸张指标数值21 天累计写入37 TB估算全年写入640 TB主流 1TB SSD 的 TBW 标称值600 TBSSD 理论寿命不足一年一个月桌面端流量150 GB24 小时不间断运行日志文件可达数十 GB临时解决方案在 OpenAI 正式修复之前GitHub Issue #23340 和 #23722 已经被标记为高优先级可以通过创建符号链接将日志文件重定向到内存文件系统# 把日志文件指向 /tmp内存文件系统mv~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bakln-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# 监控写入量macOSsudofs_usage-w-ffilesys|grepcodex# Linuxiostat-x1|grepcodex你也可以在 Codex 的配置文件中手动设置日志级别如果版本支持# 检查是否支持环境变量CODEX_LOGerror codex第二个坑WebSocket 的无底洞——150GB 流量去哪了后面还有N个类似的坑每一个都让我怀疑人生——【关注后查看完整避坑手册】症状Codex 桌面端装了一个月宽带账单涨了 100 多块。排查过程打开系统的网络监控面板发现 Codex 进程在过去 30 天消耗了 150 GB 的上行下行流量。日均 5 GB——相当于全天候挂着 YouTube 4K 视频。根因很多人以为 Codex 就是「帮你写代码的 AI 助手」跟 Copilot 一样轻量。但 Codex 桌面端实际上是一个完整的Electron 应用 云端沙盒环境。它的实时通信通道是WebSocket 长连接这意味着你在编辑器里看到的每一个字符变化都在和云端保持同步模型推理的中间过程思维链、工具调用的实时状态、代码 diff 的流式传输全部通过这条管道持续灌输网络不稳定时WebSocket 会反复重连——从Reconnecting 1/5一路试到5/5每一次重连都在消耗带宽更关键的是Codex 的设计哲学是「始终在线」。你即使没有在主动使用它它也在后台干这些事保持 GitHub 代码审查的实时同步维护任务队列状态处理 MCP 服务器的连接支持从手机端远程操控Remote Control持续索引你的项目文件对比 Claude Code同样的事情Claude Code 就没有这个问题。原因很简单——它们是两种不同的产品形态维度CodexClaude Code产品形态Electron 桌面端终端 CLI连接方式WebSocket 长连接HTTPS 短连接后台守护始终在线用完即走沙盒执行云端沙盒本地执行月流量100-150 GB不到 1 GB资源消耗高低有个 Reddit 调查挺有意思500 多名开发者中65% 日常更偏好 Codex因为「丢进去就不用管了」但盲测代码质量时67% 的人认为 Claude Code 的输出更干净。这引出了一个更深层的思考——AI 编程工具越来越「重」这个趋势值得警惕。流量控制方案# 限制 Codex 的带宽使用Linux/macOS# 用 cgroups 或者 network link conditioner 限速# 监控实时流量nethogs|grepcodex# 禁止后台网络如果不需要 Remote Control# 在 Codex 设置中关闭 Background Sync第三个坑云端沙盒的执行模型——代码上下文反复上传症状每次提交任务Codex 都要「思考」很久。你以为它在推理其实它在上传数据。根因Codex 的核心设计是「云端沙盒执行」。每次提交一个编码任务它的流程是上传将你当前项目的代码上下文文件结构、关键文件内容、git diff上传到 OpenAI 云端执行在云端沙盒里加载仓库、修改代码、跑测试下载把执行结果、代码 diff、测试输出传回来每一轮交互都在上传下载大量数据。如果你同时开了多个并行任务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 的 RSSResident Set Sizepsaux|grep-icodex|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-xcodex-desktop||codexcodex$}第五个坑日志滚雪球——从 2 GB 到 67 GB 的 GitHub Issue 史症状磁盘空间莫名其妙少了 60 GB查了一圈发现都是日志。深度排查这不是单个问题的爆发而是一连串 bug 的累积效应。GitHub 上相关的 issue 从 5 月开始就没有断过#23159/goal命令 配额耗尽导致 TUI 无限循环#23179/goal无限复制 usage-limit 错误消息#228185 小时时间限制触发后Agent 继续运行不断重试#23340/goal长循环产生单行 480 KB 的日志——一天写 34 GB#23722重试循环把codex-tui.log撑到 67 GB#24682TUI 日志又到 92 GB5 月 20 日有人报codex-tui.log长到 67 GB5 月 27 日就有人报另一个位置的日志 92 GB。看起来修了一个另一个又冒出来。根源这些问题的共同模式是错误 → 重试 → 写日志 → 继续错误 → 继续写日志。一旦触发某个边界条件配额用完、时间限制、连接断开Codex 的重试机制不是优雅降级而是疯狂重试同时把每一次重试的记录都写入日志文件。# 简化版的「死亡螺旋」whileTrue:try:resultexecute_task()returnresultexceptUsageLimitError: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.sqlite2/dev/null||echo (不存在)du-sh~/.codex/codex-tui.log2/dev/null||echo (不存在)# 2. 查 SSD 写入需要 smartmontoolsifcommand-vsmartctl/dev/null;thenechoecho SSD 健康度:sudosmartctl-A/dev/nvme0n1|grep-EPercentage Used|Data Units Writtenfi# 3. 查 Codex 进程内存CODE_MEM$(psaux|grep-icodex|grep-vgrep|awk{sum$6} END {printf %.0f MB, sum/1024})echoecho Codex 内存占用:$CODE_MEM# 4. 查日志增长速度if[-f~/.codex/logs_2.sqlite];thenSIZE_YESTERDAY$(stat-f%z~/.codex/logs_2.sqlite2/dev/null||stat--format%s~/.codex/logs_2.sqlite2/dev/null)SIZE_NOW$(du-b~/.codex/logs_2.sqlite2/dev/null|cut-f1)echoecho 建议: 如果日志大于 1GB请执行符号链接方案fi避坑总结优先级方案立即执行把日志文件重定向到内存见第一个坑的解决方案。这是最紧急的——不解决SSD 几个月就废了一周内执行限制后台网络流量关闭不需要的 Remote Control 和 Background Sync长期策略根据自己的使用场景决定是否切换到「按需启动」模式或者用 Claude Code 做架构设计 Codex 做 debug 的混合方案为什么 OpenAI 还没修截至写这篇文章时2026 年 7 月 1 日相关的 GitHub issue 已经提交了三周。OpenAI 官方确认了问题并标记为高优先级但还没有发布正式修复。一个可能的原因是这不是一个简单的 bug 修复而是涉及 Codex 的日志基础设施重构。要用标准日志库替换当前的 SQLiteTRACE 方案还要确保不破坏现有的调试能力——对一个大体量的 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 进化成自动驾驶开发台程序员该慌还是该爽这个系列会持续更新点个关注 不错过下一期。你还想了解什么评论区告诉我。