当前位置： 首页 > news >正文

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

news 2026/7/2 2:42:55

上周帮一个朋友排查电脑变慢的问题。他的 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 TB
SSD 理论寿命不足一年
一个月桌面端流量150 GB
24 小时不间断运行日志文件可达数十 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# 监控写入量（macOS）sudofs_usage-w-ffilesys|grepcodex# Linuxiostat-x1|grepcodex

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

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

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

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

症状

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

排查过程

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

根因

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

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

  1. 你在编辑器里看到的每一个字符变化，都在和云端保持同步
  2. 模型推理的中间过程（思维链）、工具调用的实时状态、代码 diff 的流式传输，全部通过这条管道持续灌输
  3. 网络不稳定时，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 的核心设计是「云端沙盒执行」。每次提交一个编码任务，它的流程是：

  1. 上传：将你当前项目的代码上下文（文件结构、关键文件内容、git diff）上传到 OpenAI 云端
  2. 执行：在云端沙盒里加载仓库、修改代码、跑测试
  3. 下载：把执行结果、代码 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 的 RSS（Resident Set Size）psaux|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||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 的重试机制不是优雅降级，而是疯狂重试，同时把每一次重试的记录都写入日志文件。

# 简化版的「死亡螺旋」whileTrue:try:result=execute_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 写入（需要 smartmontools）ifcommand-vsmartctl&>/dev/null;thenecho""echo"💾 SSD 健康度:"sudosmartctl-A/dev/nvme0n1|grep-E"Percentage Used|Data Units Written"fi# 3. 查 Codex 进程内存CODE_MEM=$(psaux|grep-icodex|grep-vgrep|awk'{sum+=$6} END {printf "%.0f MB", sum/1024}')echo""echo"🧠 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)echo""echo"📊 建议: 如果日志大于 1GB，请执行符号链接方案"fi

避坑总结

优先级方案

  1. 立即执行：把日志文件重定向到内存（见第一个坑的解决方案）。这是最紧急的——不解决，SSD 几个月就废了
  2. 一周内执行：限制后台网络流量，关闭不需要的 Remote Control 和 Background Sync
  3. 长期策略：根据自己的使用场景，决定是否切换到「按需启动」模式，或者用 Claude Code 做架构设计 + Codex 做 debug 的混合方案

为什么 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 进化成"自动驾驶"开发台，程序员该慌还是该爽？

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

http://www.jsqmd.com/news/1106159/

相关文章：

  • 孤能子视角：Karpathy LLM Wiki，一个人工观察符自动编织系统
  • 被需要是一种高级自由，这种被需要感能激发出你最深层的智慧和韧性。
  • 全书目录与章节地图 《AI Agent 开发平台资深技术专家 AI Agent 应用架构师 CTO 面试题库详解》
  • 第4章 RAG 检索增强生成全链路架构《AI Agent 开发平台资深技术专家 AI Agent 应用架构师 CTO 面试题库详解》
  • 下面设计实现的是：交换机Hlr指令处理任务模块。当然，在后续的业务发展过程中，还可能出现，其他类型指令的任务处理，所以根据“开闭”原则的定义，要抽象出一个接口类：BusinessEvent
  • Agent记忆中RAG难题，浙大MemGate盘活了
  • 终极指南：HS2-HF Patch - Honey Select 2游戏体验的完整革命
  • 智能合约开发中的威胁建模：代码生成前的安全基线构建
  • 生成式引擎优化（GEO）在酒店民宿行业的落地实践：对抗 OTA 流量截流
  • Adobe破解终极指南：三步免费激活Photoshop等专业软件
  • 【中小学AI人工智能教育】强化学习范例——平衡杆
  • Claude 桌面版（macOS / Windows）工具分享
  • DFT：IST和ROM BIST能不能同时跑？特别是在mission mode下
  • 多模态AI系统性能优化：从3.2秒到1.5秒的实战经验
  • 新160个CrackMe042-crackme、043-riijj_cm_20041121、044-tsrh-crackme逆向分析
  • 前端应用离线暂停更新策略：构建稳定可靠的渐进式部署方案
  • 第9章 MCP 协议与 Skills 工具生态《AI Agent 开发平台资深技术专家 AI Agent 应用架构师 CTO 面试题库详解》
  • 在C++基础上理解CSharp-6
  • AI 编译优化入门：算子融合不是为了少写几行代码
  • utpasswd命令详解：10个实用参数让密码管理更高效
  • SolidWorks_装配体设计5_自上而下设计
  • AI Agent 编排实战：别让多个智能体互相抢麦
  • 特种行业加固计算机配套的固态硬盘，兼容性问题通常出在哪里？
  • Kiran Biometrics：开源生物识别认证系统的完整指南
  • Java反射基础
  • Frida内存操作避坑指南：从原理到实战的逆向分析核心技能
  • CNN-LSTM-AdaBoost时间序列预测实战指南
  • 大模型推理加速年度趋势：从量化到稀疏化的技术跃迁路径
  • ActiveReports for .NET 20.0J SP1-AIレポートウィザードがさらに進化
  • 大模型推理加速核心：KV Cache 复用机制与内存布局优化