TL;DR「日志 bug 可能写 TB 级数据到本地 SSD」是 2026 年 6 月 HN 510 分的风险报告。注意标题里的 may：它是风险信号，不是确认结论。这篇给一套照做即可的自查 SOP，外加一个每月两分钟的巡检习惯。

来源信号 SOURCES

以下内容整理自社区公开讨论，本页只做拆解与核实，不搬运原帖；观点归属原作者。

事实性知识 FACTS

这些是讨论中被多方印证、或可对照官方文档核实的事实。

2026-06-22 前后，GitHub issue「Codex logging bug may write TBs to local SSDs」出现，HN 讨论拿到 510 分、271 条评论——磁盘被写满是每个人都能共情的故障。
issue 标题用的是 may（可能）：这是一份风险报告，而非已确认的普遍故障；你本机是否受影响，只能靠 du 与 df 实测回答。
该事件已列入本站已知事件档案，与子代理提示词加密、自行绕过 sudo 并列为 2026 年中社区集中审视代理行为边界的一批案例。

社区讨论里的概念不全是事实——每条都标注了它的性质，读之前先看标签。

日志膨胀（log bloat）已验证事实

诊断与会话日志随使用持续追加，缺少轮转或清理时占用单向上涨。这不是 Codex 独有的问题，但代理类工具的单任务日志量远大于传统 CLI，膨胀速度也更快。

TB 级写入待验证假设

该 issue 报告的风险量级：日志累计可能达到 TB 级。量级是否普遍成立、机制如何，以 issue 后续与官方修复说明为准；对你可执行的结论只有一个——实测自己机器。

月度巡检个人观点

每月固定跑一次磁盘水位与目录大小检查并记录数字。环比异常增长是最早的警报，比任何新闻都早。这是本站建议，不是官方要求。

目标排查本机是否受到日志写入问题影响，清理异常占用，并建立可长期执行的磁盘巡检习惯。

前提macOS 或 Linux 终端可用；Codex CLI 已安装，数据目录默认在 <code>~/.codex</code>（若你自定义过位置，以官方文档/CLI 配置为准）。

01
看整体水位
运行 df -h，重点看系统盘所在行的容量与可用空间；如果可用空间明显低于你的记忆基线，进入下一步。
02
量 Codex 数据目录
运行 du -sh ~/.codex 查总占用。这个数字没有标准答案，但对照你自己的使用强度，异常大很容易看出来。
03
定位大头
运行 du -h -d 1 ~/.codex | sort -h，列出一级子目录并按大小排序，锁定异常膨胀的日志或会话目录。
04
确认后再清理
抽查可疑目录里文件的修改时间与内容形态，确认是日志/会话记录而不是配置与凭证；删除用 rm -ri（逐项交互确认），不要递归强删一把梭。
05
更新 CLI
把 Codex CLI 升级到最新版本（安装与升级命令以官方仓库 README 为准），并在 release notes 里确认日志相关问题是否在修复列表中。
06
建立巡检
把 df -h 与 du -sh ~/.codex 设为每月一次的例行检查，记下数字；环比突然增长就是最早的警报。

结果本机是否受影响有了实测答案；异常占用已清理、CLI 已更新，并且多了一个每月两分钟、能提前发现同类问题的巡检动作。

想知道今天的重置判定？回到首页实时雷达。