OpenAI Codex on Codexer

Codex 正在偷偷「吃掉」你的 SSD：一个日志 Bug 每年写入 640TB

Tue, 23 Jun 2026 09:00:00 +0800

想象一个场景：你买了一台新 MacBook，装好 Codex CLI 就开始用它写代码。每天开着终端，Codex 在后台帮你补全、重构、调试。三个月后，你发现电脑越来越慢，打开 Activity Monitor 一看，磁盘写入量已经超过了 150TB。翻遍进程列表，凶手正是那个你最信任的 AI 编程助手。

这不是虚构。2026 年 6 月 14 日，GitHub 用户 1996fanrui 在 Codex 仓库提交了一个 Issue，标题简洁但触目惊心：「Codex is writing 640 TB/year to my SSD」。

一个被忽视的「诊断日志」

问题的核心藏在 ~/.codex/logs_2.sqlite 这个不起眼的文件里。

Codex CLI 内部有一个日志子系统，它把运行期间的所有事件，包括每一次工具调用、每一段 WebSocket 消息体的完整内容、甚至每次对 /etc/passwd 和 ld.so.cache 的平凡文件访问，全部写入一个本地的 SQLite 数据库。

关键不在于「记录了日志」，而在于以什么级别记录。

Codex 的 SQLite 日志 sink 默认运行在 TRACE 级别。在传统日志体系里，TRACE 是最低层级，用于调试极其底层的代码执行细节。正常发布的软件产品要么默认关闭 TRACE，要么只在用户主动开启时才启用。但 Codex 的日志子系统不仅默认开 TRACE，而且完全忽略 RUST_LOG 环境变量，用户没有任何办法调低日志级别。

更糟糕的是，根据社区分析，约 71% 的写入数据属于 TRACE 级别的噪音日志，对普通用户来说毫无意义。你花钱买的 SSD 寿命，正在被一堆你看不见也用不上的日志数据匀速消耗。

640 TB 是怎么算出来的

1996fanrui 的机器上有一块 1TB SSD。他在 21 天里积累了约 37TB 的写入量，折合每天约 1.76TB。按这个速率往下推，一年就是 640TB。

AI 代理的自我进化：Codex 与 Claude Code 如何自动分析失败、优化提示词

Mon, 22 Jun 2026 09:00:00 +0800

想象这样一个场景：你有一个 AI 客服代理，它对 100 个用户问题给出了回复，其中 35 个回复被用户标记为不满意。你面前摆着两样东西，一份是包含所有对话记录的 JSONL 日志，另一份是一个简洁的任务描述：「请分析失败原因，修改提示词或切换模型，让代理的表现更好」。

你会怎么做？大概率是先翻日志找规律，尝试改几版提示词，跑几个例子看效果，不行再调。

现在，把这个任务交给一个 AI 编程代理，比如 Codex 或 Claude Code，它会怎么做？

研究员 Andrew Jesson 在 2026 年 4 月做了一组实验，结果既在意料之中，又让人重新思考一个问题：当 AI 代理开始优化 AI 代理时，那些「专业工具」还有存在的必要吗？

实验设计：100 条记录，一个指标，零专业工具

Jesson 的实验设计简单直接。他准备了五个不同的 AI 代理应用场景：

应用	描述	评价指标
软件工程	Linux 终端代理，执行命令解决编码任务	验证器打分 (0–1)
商业管理	多轮 CEO 代理，驱动商业模拟	按时完成任务数
命名实体识别 (NER)	从句子中提取组织名、人名等	精确匹配
NDA 条款提取	从 OCR 合同中提取生效日期、管辖地等	字段级匹配
科学研究复现	代理从沙盒数据和遮罩 PDF 中复现天体物理论文	数值二元匹配

每个应用先跑一轮 baseline：用初始提示词加上 gpt-5.4-mini 模型执行 100 个不同任务，记录下每次推理的内容和对应的反馈分数。

然后，把这份数据连同一个 Markdown 技能文件丢进一个隔离容器，告诉 Codex（搭载 GPT-5.5）或 Claude Code（搭载 Claude Sonnet 4）：分析这些失败案例，创建新的提示词变体或更换模型，让指标更好。