代码改变世界

MAC 空间告急？Codex 的 156GB 缓存垃圾，这样清！

2026-09-08 06:39  AlfredZhao  阅读(0)  评论(0)    收藏  举报

最近笔者总是需要清理电脑空间，起初就是不断地去删除大文件。结果后来发现，越来越离谱，大文件都清理了，怎么还时不时空间不够告警呢？

常规去看电脑的存储空间情况：

image.png

发现这里系统数据占用 258.15 GB，属于偏高/不正常现象。AI 告诉笔者，在 macOS 中，正常的“系统数据”通常在 20 GB 到 60 GB 之间。达到 200 GB 以上，通常是因为开发工具缓存、容器镜像、日志文件、iOS 备份或 Time Machine 本地快照堆积导致的。

所以系统数据这么大，估计就是不正常的原因，但具体到底啥情况？一系列排查，最终发现是 Codex 的锅……

01 | 两个关键概念：系统数据与 Codex 缓存

在深入排查之前，先厘清两个关键概念：

  • macOS“系统数据”：这是 macOS 存储管理中对无法归类到应用、文稿、照片等明确类别的文件的统称。它涵盖系统缓存、日志、临时文件、开发者工具数据等。正常范围通常在 20–60 GB，超过 200 GB 则明显异常。
  • Codex 的插件市场（Marketplace）机制：Codex 客户端会从远端拉取并解压预装插件市场数据到本地临时目录（.codex/.tmp/bundled-marketplaces），以 openai-bundled.staging-<UUID> 命名。正常情况下，解压完成后应清理或替换为正式目录；若下载或解压失败，则会反复重试，不断生成新的 staging 文件夹，形成死循环堆积。

02 | 排查过程：从系统数据到 Codex 缓存

① 定位用户目录中的空间大户

先用命令看看用户目录下到底谁占空间最大：

% du -sh ~/.?* 2>/dev/null | sort -rh | head -n 10
156G	/Users/alfredzhao/.codex
 40G	/Users/alfredzhao/.colima
...

好家伙，Codex 一骑绝尘……而且此时又查了下空间，发现其实它一直都在增长，看起来是什么日志在疯狂输出。可是笔者电脑最近的 key 都用不了了，它到底在干嘛？

② 深入 Codex 目录，锁定 .tmp 隐藏目录

进入到 .codex 目录，发现一个隐藏目录 .tmp 占用巨大：

% du -sh .*
344K	.codex-global-state.json
344K	.codex-global-state.json.bak
4.0K	.personality_migration
156G	.tmp

进一步查看：

.tmp % du -hs *
156G	bundled-marketplaces
  0B	marketplaces
 76M	plugins
4.0K	plugins.sha
  0B	plugins.sync.lock

③ 确认无进程占用，排除“正在写入”的可能

确认无任何活动进程在占用写入该路径：

% lsof +D ~/.codex/.tmp
COMMAND   PID       USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
zsh     20246 alfredzhao  cwd    DIR   1,17      224 45281894 /Users/alfredzhao/.codex/.tmp
lsof    20902 alfredzhao  cwd    DIR   1,17      224 45281894 /Users/alfredzhao/.codex/.tmp
lsof    20903 alfredzhao  cwd    DIR   1,17      224 45281894 /Users/alfredzhao/.codex/.tmp

注意：lsof 输出中出现的 zsh 和 lsof 进程，只是当前终端会话的工作目录指向该路径，并非有程序在持续写入。真正的写入进程并不存在。

④ 查看 staging 文件夹内容，确认死循环堆积

确认是啥：

% du -sh ~/.codex/.tmp/bundled-marketplaces/* 2>/dev/null | sort -rh | head -n 10
138M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-103deadc-40cc-4487-9ac6-3843405b2b2b
120M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-9bd2c50e-c78d-4325-98e4-48cefff4c5d4
120M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-9a2f4ccc-6b22-4bf1-8997-e226556b0952
120M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-796e076d-c160-47f2-a0ae-475b003e0cee
120M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-465f925c-5e54-4e51-8902-c91ba3c397f5
119M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-72138f8c-76ca-470e-a3cc-86bae49a4744
119M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-64b1c673-73b9-4bca-8fee-9a5cfe85ee53
119M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-3167f1c4-22aa-4c15-aedc-28232e5dc1e1
119M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-2ed29469-1541-4955-bd6b-783f35019f6c
112M	/Users/alfredzhao/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-eb08b968-abc0-4e16-ae02-0e40ea970fe4

从输出可以看到，大量形如 openai-bundled.staging-<UUID> 的解压文件夹不断被重复创建（每个约 120MB，累计达 1000 多个文件夹，最终堆积出 156GB）。这属于典型的自动化下载/解压预装插件市场（staging）时重试失败陷入死循环。

flowchart TD A[Codex 启动/同步插件市场] --> B{下载或解压是否成功?} B -- 否 --> C[生成新的 staging 文件夹<br>openai-bundled.staging-UUID] C --> D[清理旧 staging 或替换正式目录] D --> B B -- 是 --> E[正常使用 marketplaces 目录] C -. 失败重试无清理机制 .-> C style C fill:#ffcccc

03 | 解决方案：三步清理，恢复空间

由于前面通过 lsof 已确认无任何活动进程在占用写入该路径，可以直接进行删除：

cd
rm -rf ~/.codex/.tmp
mkdir -p ~/.codex/.tmp

image.png

清理完成后，系统数据占用恢复正常，空间告警也随之消失。

04 | 注意事项与预防建议

  • 删除前务必确认无进程占用：使用 lsof +D <路径> 检查是否有程序正在写入。若存在活动进程，应先退出 Codex 或相关进程再清理，避免数据损坏。
  • .tmp 目录可安全删除：该目录本质是临时文件存放区，删除后 Codex 会在需要时重新创建。删除后重建空目录是为了避免某些程序因目录不存在而报错。
  • 若问题反复出现：说明 Codex 的插件市场同步机制存在缺陷（下载/解压失败后未正确清理 staging 文件）。可尝试更新 Codex 版本，或检查网络环境是否导致下载不稳定。
  • 定期检查缓存目录：开发工具（Codex、Colima、Docker 等）的缓存目录是 macOS“系统数据”膨胀的高发区。建议定期用 du -sh ~/.?* 2>/dev/null | sort -rh | head -n 10 检查，及时发现异常增长。

05 | 总结

本次空间告警的根因是 Codex 在同步预装插件市场时，因下载/解压失败陷入重试死循环，在 .codex/.tmp/bundled-marketplaces 下不断生成约 120MB 的 staging 文件夹，最终堆积出 156GB 的垃圾数据。排查路径为：系统数据异常 → 用户目录空间排序 → 定位 .codex → 深入 .tmp → 确认 staging 死循环 → 清理。

如果你也遇到类似问题，不妨按这个思路排查一下 Codex 的缓存目录。核心经验是：当 macOS 系统数据异常膨胀时，优先检查开发工具的缓存与临时目录，往往能快速定位问题。

关注我，和AI一起成长~