Codex日志bug把SSD写废了怎么办

我把Codex写爆SSD这件事拆成了可直接照抄的修复模板。

我最近一直在看这种“安全工具把自己先弄出安全事故”的戏码，真有点烦。你一边听 OpenAI 讲 GPT-5.5-Cyber 怎么帮你补漏洞、怎么守住生产环境，另一边 Codex 却在本地疯狂写 SQLite 日志，写到能把消费级 SSD 直接熬死。这个反差太刺眼了，像是一个人一边教你怎么防火，一边把打火机塞进你口袋里。

更让我不舒服的是，这类问题不是“模型回答错了”那么简单，而是基础设施层面的失控。你以为自己只是开了个 AI 编程助手，结果它在后台默默做高频写盘，机器还很安静，磁盘寿命却在一点点掉。开发者最怕这种事：没有报错，没有崩溃，只有硬件在悄悄流血。这篇知乎把这个矛盾讲得很直白，所以我想把它拆开，不讲情绪，讲你真正该关心的东西：它为什么会发生，风险到底在哪，怎么把这类工具管住。

我也见过类似场景。日志系统默认开得太猛，开发机风扇像起飞，最后排查半天，问题根本不是业务逻辑，而是“写得太勤快”。AI 工具现在也开始复刻这个老毛病，只不过规模更大，速度更狠，后果更贵。

原文作者是新智元，发在知乎专栏里，核心素材来自 OpenAI 这次 GPT-5.5-Cyber、Codex Security 和 Patch the Planet 的同步发布，以及社区对 Codex SQLite 日志写入异常的反馈。原文里提到了 GitHub issues、OpenAI 研究员回应和多个安全基准，我下面会按开发者视角拆开讲。来源链接我放在文末，方便你回去对照。

别被“修补地球”这句话带跑偏

OpenAI还发起了一个听起来就很燃的计划—— Patch the Planet（修补地球）。

这句听起来像宣传口号，但我读下来只想说：它本质上是在讲一个很现实的问题，开源世界的漏洞太多，维护者太少，AI 只是把“发现问题”这件事加速了。

原文里有个数字我觉得很关键：被广泛使用的开源项目中，94%的项目，一年内90%以上的新增代码，靠的是不到10个开发者。这个数字不是为了煽情，它是在提醒你，安全修复不是“多发几份报告”就能解决的。报告太多，维护者会先被噪声淹没。

我以前在团队里也碰过类似情况。扫描器一开，告警像下雨，最后大家不是在修漏洞，而是在给漏洞做工单分流。AI 安全工具如果只会“发现”，不会“收敛”，那它就是把维护成本往别人身上甩。

所以 Patch the Planet 真正有价值的地方，不是名字多大，而是它强调了专业人工复核。研究员先去重、先验证，再把干净的补丁送给维护者。这个思路很朴素，但很对。你不能把一车噪声倒给维护者，然后说自己在帮忙。

怎么用到你自己的项目里？我建议你把“AI 安全扫描”分成三层：第一层只负责发现；第二层负责聚类、去重、排序；第三层才进入人工确认和补丁生成。别让自动化直接越过第二层，不然你会得到一个更快的垃圾制造机。

• 先定义“可行动”漏洞，而不是所有命中都算数。
• 给每条告警加去重键：文件、函数、调用链、版本号。
• 把人工确认作为发布门禁，而不是事后补课。

GPT-5.5-Cyber强在哪，不在“更会聊天”

原文给了几个基准：CyberGym 85.6%，ExploitGym 39.5%，SEC-bench Pro 69.8%。这些数字的意思不是“它更聪明”，而是它更擅长做防御任务里的那套脏活累活：找漏洞、验证风险、生成补丁、给人工审查证据。

我更愿意把它理解成一个专用安全工程师，而不是一个通用大模型。普通模型擅长给你解释概念，安全模型要做的是把攻击面一层层剥开。这个差别很大。前者像顾问，后者像值班工程师。

原文还对比了普通版 GPT-5.5、Claude Opus 4.7 和 Cyber 版。这里我不想把重点放在“谁赢了谁”，因为那很容易变成口水战。对开发者来说，真正有用的是：当模型开始进入高风险工作流时，评估指标必须贴近实际任务，而不是只看对话体验。

我见过不少团队把“模型表现好”理解成“上线没问题”，结果一接到真实任务，模型开始稳定输出看起来很合理、实际很危险的建议。安全场景尤其这样。你不能只问它“能不能说”，你要问它“能不能在约束下做对事”。

怎么落地？如果你在做内部安全助手，别直接让它碰生产系统。先把它放进只读环境，给它有限的代码快照、有限的执行权限、明确的审计日志。再把输出限定成三种格式：风险说明、证据链、候选补丁。别让它自由发挥写长篇建议，那种输出最容易把人带沟里。

• 把任务拆成“识别、验证、修复建议”三段。
• 只给只读上下文，不给任意执行权限。
• 所有建议必须附证据链，不能只给结论。

Codex Security 不是插件，它是工作流入口

原文说 Codex Security 插件把漏洞扫描、威胁建模、攻击路径追踪、补丁生成直接焊进了 Codex 工作流。这个描述挺准确，我读的时候想到的不是“插件”，而是一个新的入口层：它试图把安全能力塞进你日常写代码的路径里。

这件事的价值在于前移。以前很多安全检查是“写完再扫”，现在它想变成“边写边看”。这当然更高效，但前提是工具本身得稳定，不然你会在编码时多背一层故障风险。

原文提到，自今年 3 月研究预览上线以来，Codex Security 已经扫描了超过 3000 万次提交，覆盖 3 万多个代码仓库，人工复核确认修复的发现超过 7 万个，自动判定修复的超过 50 万个。这个规模说明什么？说明 OpenAI 不是在做一个玩具功能，它在试图把安全扫描做成高频基础设施。

我对这种规模化工具一向有个偏见：只要它开始大规模写日志、缓存状态、追踪上下文，就一定要盯住资源边界。因为一旦你把“安全”做成常驻服务，资源消耗会跟着放大。安全工具最怕的不是慢，是悄悄把别的系统拖垮。

怎么用？如果你要把类似 Codex 的安全插件接进团队流程，我建议你先设三道闸：限制扫描频率、限制本地持久化、限制长任务运行时长。尤其是本地持久化，别默认让它把所有中间状态都落盘。很多“稳定性问题”其实都出在这里。

还有个很实用的习惯：把插件的日志目录单独放到一个可监控分区里，给它设磁盘配额。这样一旦它开始发疯，你至少能看到它在烧什么，而不是等 SSD 寿命被磨掉一半才发现。

真正的 bug 不在模型，在写盘策略

这部分是我最想吐槽的。原文里那个问题很具体：Codex 在流式传输和长时间运行时，会以极高频率往本地 ~/.codex/logs_2.sqlite 写 TRACE 日志，峰值能到 16MB/s，实测有人算出一年可写入 640TB。这个量级已经不是“日志多一点”了，这是在拿 SSD 当耗材。

最离谱的是，它还很安静。文件看起来不大，因为它在反复写入、删除、清理，肉眼看不出什么异常，但闪存芯片已经在吃满负荷。开发者最容易被这种假象骗过去：目录大小没涨，不代表写入量没涨。

原文提到，有 GitHub 用户实测开机运行 21 天，主 SSD 被写入约 37TB 数据。这个数字已经足够让人警觉了。更关键的是，相关 issue 从 4 月就有人提，后面一路有人补刀，到 6 月 14 日又把问题顶上来。也就是说，这不是一次偶发事故，而是一个被社区反复指出、但迟迟没彻底解决的资源管理问题。

我在项目里也见过类似“默认日志级别太高”的坑。开发阶段大家嫌日志少，生产阶段大家嫌日志多。最后没人去调，因为“先这样跑着”。结果一拖就是几个月，直到磁盘告急、I/O 抖动、机器变卡，才开始认真看。

怎么处理这种问题？别只改日志级别，得把写盘策略一起改掉。要么做采样，要么做批量刷盘，要么做内存环形缓冲。最差也要给 TRACE 级别加速率限制。日志不是越细越好，日志的成本也得算进去。

• 给 TRACE 日志加每秒写入上限。
• 把高频日志改成批量落盘。
• 为本地 SQLite 设置配额和轮转策略。

SQLite 没错，错的是你把它当无限桶

我不想把锅甩给 SQLite。SQLite 本身没问题，问题是你拿它做高频日志存储，还默认允许持续写入、清理、再写入。数据库是拿来管理数据的，不是拿来当无限吞吐的垃圾桶。

原文里最让我警觉的一点，是“写入再删除、写入再删除”的模式。很多人只看文件大小，不看底层写放大。SSD 不是机械硬盘，写入寿命是实打实会被消耗的。你每次觉得“反正只是日志”，硬盘都在替你记账。

我建议你把这个问题翻译成工程语言：这是一个“后台写放大失控”的案例。它和模型能力没直接关系，和资源治理关系很大。只要你的工具会长时间运行、会流式输出、会记录上下文，就有可能踩到这个坑。

怎么防？最简单的办法是把日志分层。热日志放内存，冷日志批量落盘，审计日志单独存储。然后再给每层设置不同保留期。别把所有东西都塞进一个 SQLite 文件里，最后再指望它自己长出节制。

如果你是做平台工程的，我还建议加一个“日志写入预算”指标。这个指标不花哨，但很管用。比如每个 agent 每小时最多写多少 MB，超过就降级到摘要日志。你会发现，这种硬约束比事后排查好用得多。

OpenAI 的回应说明了什么

原文最后提到，OpenAI 研究员 Vaibhav Srivastav 回应说，这个问题已经修复，并随最新 Codex 版本发布，用户需要通过 npm 或 bash 安装脚本升级。这个回应很直接，也挺符合工程现实：先修，再让大家升级。

但我更在意的是这件事暴露出来的节奏问题。一个安全工具刚高调发布，社区马上抓到资源写入异常，这会让人对“默认安全”这句话多一层怀疑。不是说功能没价值，而是说发布时对资源边界的把控还不够细。

我一直觉得，做基础设施工具的人最该怕的不是“功能不够多”，而是“默认值太激进”。默认值一旦激进，用户就会替你承担后果。Codex 这次的日志问题就是典型例子：你不改配置，它就按自己的节奏写，最后硬盘先扛不住。

如果你在团队里推类似工具，我的建议很简单：默认关闭高频 TRACE；默认只保留摘要日志；默认给本地存储加上上限；默认把升级说明写得比功能介绍更醒目。听起来很保守，但这才是能长期跑的做法。

说白了，AI 工具进入安全场景后，最值钱的不是“会不会找漏洞”，而是“会不会老老实实待在边界里”。边界感差的工具，能力越强，风险越大。

你可以直接照着改的那套做法

如果你现在也在做一个会长时间运行、会写日志、会接本地存储的 AI 工具，我建议你直接拿下面这套规则当起点。它不花哨，但能救命。

第一，把日志策略拆成三档：默认、调试、审计。默认档只保留必要事件，调试档只在短时间内打开，审计档单独落盘并限流。第二，把本地持久化从“默认开启”改成“显式开启”。第三，给每个 agent 加资源预算，尤其是磁盘写入预算。第四，所有长任务都要有超时和降级路径。

我知道很多团队会嫌这套流程麻烦，但麻烦是有意义的。因为一旦工具开始常驻，任何一个“先不管”的小洞，最后都会变成运维账单。你不在设计阶段管住它，就只能在事故阶段补票。

最后我想说，OpenAI 这次的两面性其实很典型：一边是更强的安全能力，一边是更糟的资源失控。开发者真正该学的，不是站队夸谁，而是把这种反差当成警报。能力提升了，边界也必须一起收紧，不然工具会比你想的更快把自己玩坏。

The template you can copy

# AI 安全插件资源控制模板

## 1. 默认策略
- TRACE 日志默认关闭
- 仅保留摘要日志，保留期 7 天
- 本地 SQLite 仅用于短期缓存，不用于无限追加
- 所有长任务必须设置超时

## 2. 磁盘写入预算
- 单个 agent 每小时最大写入：100 MB
- 单个 agent 每天最大写入：1 GB
- 超过预算后自动降级为摘要模式
- 超过 2 次预算触发，自动暂停高频日志

## 3. 日志分层
- 热日志：内存环形缓冲
- 冷日志：批量刷盘，每 30 秒一次
- 审计日志：单独目录，单独配额

## 4. SQLite 使用规范
- 禁止把 TRACE 级别日志直接写入主 SQLite 文件
- 仅允许写入聚合后的事件摘要
- 设置数据库最大大小上限
- 启用轮转和清理任务

## 5. 运行时保护
- 流式任务开启 I/O 监控
- 当写入速率超过阈值时自动降级
- 当磁盘占用超过 80% 时暂停非必要记录
- 记录所有降级动作到审计日志

## 6. 升级检查清单
- 检查默认日志级别
- 检查本地缓存目录位置
- 检查磁盘配额是否启用
- 检查长任务是否有超时
- 检查是否存在无限写入路径

## 7. 团队落地建议
- 安全扫描和日志系统分开评审
- 把资源预算写进 PR 模板
- 上线前做 24 小时压力测试
- 把写入量纳入可观测性面板

## 8. PR 模板里直接加这一段
### 资源与日志检查
- [ ] 是否新增高频日志
- [ ] 是否写入本地持久化存储
- [ ] 是否设置写入速率上限
- [ ] 是否设置磁盘配额
- [ ] 是否有降级和回滚方案

## 9. 适合贴到 README 的一句话
本项目中的 AI 组件默认受磁盘写入预算约束，禁止无限制高频落盘。

这套模板不是专门给 Codex 用的，是给所有“会长时间跑、会写日志、会碰本地存储”的 AI 工具用的。你可以直接贴进 PR 模板、平台规范或者 README 里，先把边界立起来，再谈智能。

来源：https://zhuanlan.zhihu.com/p/2052695927035531367。其中关于 GPT-5.5-Cyber、Codex Security、Patch the Planet 和 SQLite 写盘问题的叙述，主要来自原文与其引用的社区反馈；我在这里做的是面向开发者的拆解和模板化整理，不是原文复述。