Codex 崩溃转储推荐排查，桌面代理一天写盘一百八十G 的怪病

用编码代理的用户请检查一下磁盘，某头部模型的桌面版被曝存在一个怪病，崩溃处理组件陷入死循环，一天能往硬盘写几个G 的崩溃转储，有用户实测累计占了一百八十G。事件上了技术社区热帖，官方至今没有回应。我把原始议题、后续跟帖与社区讨论核了一遍，这篇既讲事件也给出自查方法。

出了什么事

先还原机制。那家桌面应用基于网页内核构建，自带一套崩溃报告组件，程序崩溃时写一个转储文件留给开发者分析。问题出在组件本身反复崩溃。崩溃处理器自己崩了再触发写转储，写转储又崩，形成自我维持的循环。正常应该有一个清理器定期删旧文件，但这个应用没接入清理逻辑，文件只进不出。打个比方，像一台每次拍照就死机的相机，死机又自动拍照，照片存满一张卡再换一张。

数字越跟越夸张。首个报告者一天发现四点九G 共五万多个文件，后续跟帖陆续出现五十九G、六十一G、一百G、一百七十四G，最新一位实测一百八十G 二百多万个文件。关键在于应用功能本身正常，用户毫无感知，直到磁盘满了才发现。

这个议题六月二号就提了，四个多月一直开着，官方没有一条回应。期间一位贡献者说新版似乎修了，后续大量跟帖证明没有。四个月里每一位新中招的用户都在给这个议题添一块砖，砖头从五G 码到了一百八十G，码砖的速度说明问题在扩大而非收敛，扩大到这个规模还不回应，这份沉默本身值得记一笔。

怎么自查与处理

苹果系统的检查路径在应用支持目录下，找到对应应用文件夹里的 Crashpad 子目录看 pending 文件夹的大小，几个G 以上就是中招。视窗系统路径类似，在应用数据目录下。检查这件事值得加进季度运维习惯里，不光查这一个应用，所有常驻后台的工具都顺手过一遍，十几分钟的事。这个事件给所有桌面代理用户提了个醒，工具越自动，人越要关心工具在磁盘上写了什么，这个关心并非疑神疑鬼，自动化时代它就是卫生习惯，习惯养成后这类问题会少很多，少掉的都是不用请假救火的下午，救火痛谁救谁知道，不救的看看这个帖子也能体会几分，体会完顺手查查自己的硬盘，查完记得回来点赞这个议题，点赞是给后面中招的人留的灯塔，灯塔照亮的是同一条排查路径，路径三步十分钟，十分钟是这篇文章想让每位读者花出去的。

处理三步。先关应用，删掉整个 pending 文件夹的内容，这些只是未上传的崩溃报告，删了无副作用。再把该文件夹设为只读，阻止继续写入，只读之后应用照常用，只是新的崩溃报告写不进去了。长期方案是定时清理，社区有人配了十五分钟一次的定时任务，自动化之后的维护成本归零。最根本的解法是官方接入清理器或修掉循环，在那之前只能用户自救，自救三步加起来不超过十分钟。

解决了什么需求

这个案例的普适价值在两点。其一，代理工具磁盘纪律值得警惕，热帖评论区变成大型晒场，各家代理乱写盘经历都被翻出来，工作区残留、构建产物、测试截图，某用户被代理截上千张验证图吃掉整整九十G，共识是在代理配置文件里显式写明清理要求，写一句用完删除比事后救火管用。其二，无感知磁盘蚕食是桌面应用通病，不光代理，通讯软件缓存、开发工具索引、下载工具临时文件，都在无声啃存储，定期看一眼存储分析图，比出事后再排查省力得多。

一句话收尾，工具替你干活，磁盘的事还得自己盯。

来源

• 原始议题 https://github.com/openai/codex/issues/25921
• 社区讨论 https://news.ycombinator.com/item?id=50133231
• 官方发布页 https://openai.com/index/introducing-the-codex-app