跳到正文
原文
Hacker News· AIorNot·· 7 小时前精选AI 评分46

Codex Desktop 持续生成 Crashpad 待处理转储文件，无上限增长单日超 5GB

Codex Desktop continuously generates Crashpad pending dumps

AI 导读

用户实测发现 Codex Desktop 在 macOS 端持续生成 Crashpad 待处理转储文件，两天磁盘占用约 323GB，单日增长超过 5GB。

推荐理由

原文给出具体的 Crashpad 堆积体量、复现版本与环境，读者可据此自行核对本地是否受影响，也可观察官方后续修复进展。

正文 · AI 翻译

  6. 更改了标题

    [-]Codex Desktop 持续生成 Crashpad 待处理转储文件，增长到约 5GB[/-] [+]Codex Desktop 持续生成 Crashpad 待处理转储文件，毫无限制地增长：每天至少增加 5GB[/+]

    on Jun 9, 2026

  26. 在当前构建版本上仍然存在，而且规模大得多。测量时间为 2026-10-15 至 2026-10-17：

    环境

    • ChatGPT.app 26.1007.71326（构建版本 20398），Codex Framework (Chromium) 155.0.8059.40
    • macOS 15.7.4，Apple Silicon (arm64)

    我发现的内容

    文件夹 大小 文件
    ~/Library/Application Support/com.openai.codex/web/Crashpad 180 GB 2,251,765
    ~/Library/Application Support/Codex/Crashpad（几乎全部在 pending/ 中） 143 GB 1,785,095
    总计 约 323 GB 约 404 万

    这大约占 926 GB 磁盘的 35%。在我发现之前，可用空间已降至 1.4 GB。应用内没有任何警告。我只是通过在 ~/Library 上运行 du 才发现了这个问题。

    应用在此期间一直正常运行，正如其他人在这里报告的那样。因此，转储文件在后台静默堆积，没有任何限制。

    清理

    在应用仍在运行的情况下，我重命名了两个 Crashpad 文件夹，并删除了重命名后的副本。可用空间在几分钟内从 1.4 GB 增加到 50 GB 以上，删除操作仍在进行中（数百万个小文件）。

    诉求

    1. 为 Crashpad/pending 设置大小或数量上限，并自动清理（另见 为 Codex 生成的数据添加存储限制和自动清理 #51361）。
    2. 停止产生转储文件的处理程序崩溃循环（[app][macOS][26.727.51351] browser_crashpad_handler 启动后 2 毫秒即触发 SIGTRAP，launchd 重新生成它，Crashpad/pending 以每天约 17GB 的速度填满磁盘 #36982）。
    3. 当应用自身数据超过几个 GB 时，在应用内显示警告。

    相关：#36982、#39875、#51739、#52194、#51361。

来源：Hacker News · github.com

#行业动态#OpenAI