OpenAI 的编程助手 Codex，出事了。
GitHub 上一个刚刚浮出水面的 issue 揭示了一个让人不安的事实：Codex 的日志系统正在以惊人的速度吞噬用户的本地 SSD。一个用户报告，他的 Codex 在一段时间的活跃使用后，写入了多达 2TB 的日志数据到本地硬盘——而他只是一个普通开发者，不是日处理量巨大的企业用户。
这个数字意味着什么？意味着你的 512GB 笔记本 SSD，可能在几个月内就被 Codex 的”隐形后台活动”吃掉一半可用空间，而你完全不知情。
问题出在哪里？
根据 issue 里的技术分析，罪魁祸首是 TRACE 级别的日志。在这次采样中，TRACE 日志占到了保留字节数的 70.7%。加上 codex_otel.log_only 和 codex_otel.trace_safe 两个配置项贡献的 25.3%，这三项加起来达到了 96% 的占比。
换句话说，Codex 产生的数据里，真正有用的反馈日志只占 4%，剩下 96% 都是技术团队为了调试目的留下的”中间产物”。
更关键的是：这些日志写入是无差别的。不管你的项目大小，不管你是否在意，这些数据都会照写不误。对于硬盘空间有限的笔记本用户，这是一个实际的、可见的伤害。
这不是小问题
有人会说：”日志而已，删掉就好了。”但问题没这么简单。
首先，这些日志不是普通日志——里面包含了 websocket/SSE payloads 的原始数据，以及大量的遥测镜像数据。这些数据不仅体积大，而且可能包含用户在代码编辑器里的操作内容。这带来了一个隐私问题：你的代码编辑行为被完整记录并存储在本地，这些数据会不会以某种方式被回传？
issue 里的描述很直白：“top sources are mostly global TRACE logs, mirrored telemetry logs, and raw websocket/SSE payload logging.” 三个主要来源，没有一个是用户主动开启的。
其次，96% 的数据可以通过配置过滤掉——但普通用户不知道这些配置存在。OpenAI 把调试工具的副产品留在了默认行为里，让用户承担存储成本，这是一个产品设计问题。
为什么会发生？
Codex 是一个编程助手，面向的既有个人开发者，也有企业用户。企业用户有 IT 团队可以管理这些配置，但个人开发者没有。
OpenAI 的模型发布节奏一直很快——快速推出、快速迭代。这套策略在模型能力上很有效，但在工程细节上会留下技术债。日志系统是典型的”先跑通再说”的领域：先把功能跑起来，调试工具慢慢加，日志慢慢积累，最后发现这些东西已经成了用户机器上的隐形负担。
这不是 Codex 第一次被抱怨存储问题。之前就有用户反馈 Codex 的缓存机制不够透明，空间清理逻辑缺失。这次日志问题只是同一个根本问题的另一个症状：OpenAI 在快速扩张时，对客户端资源管理的优先级不够高。
谁受影响最大？
个人开发者和小型团队是主要受害者。
企业用户通常有受管理的机器，有 IT 策略可以限制日志空间，有预算购买更大的 SSD。但个人开发者——尤其是用 13 寸 MacBook Air 写代码的那批人——硬盘空间本来就紧张，512GB 还要分给系统、Node_modules、Docker 镜像，最后发现最大的空间消耗者是一个编程助手的后台日志。
这很荒谬。
开源社区的反应
issue 一发出，就在 Hacker News 上引起了讨论。有人贴出了自己的硬盘使用数据，有人开始研究如何用配置关闭这些日志（codex_otel.log_only 和 codex_otel.trace_safe 可以过滤掉大部分），也有人开始担心这些日志里是否包含敏感代码内容。
这是开源社区的价值所在：透明度。Codex 的问题被用户自己发现了，而不是被媒体曝光或者等到用户硬盘彻底写满才引起注意。
结论
OpenAI 在模型能力上一直是领先的，但在产品工程细节上还在追赶。日志管理是其中最典型的例子——它不影响模型输出，不影响基准测试成绩，但它直接影响用户体验。
对于 Codex 用户，现在可以做的：检查你的硬盘使用情况，定位 ~/.codex 或者相关日志目录；如果不需要调试日志，可以通过配置关闭 TRACE 级别日志记录。
对于 OpenAI：这个问题值得在产品层面正视。用户愿意为强大的模型能力付费，但不意味着愿意用自己的硬盘空间为你们的调试工具买单。
本文相关平台：