最近笔者总是需要清理电脑空间，起初就是不断地去删除大文件。结果后来发现，越来越离谱，大文件都清理了，怎么还时不时空间不够告警呢？
常规去看电脑的存储空间情况：
发现这里系统数据占用 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 缓存
① 定位用户目录中的空间大户
先用命令看看用户目录下到底谁占空间最大：
bash
% du -sh ~/.?* 2>/dev/null | sort -rh | head -n 10
156G /Users/alfredzhao/.codex
40G /Users/alfredzhao/.colima
...好家伙，Codex 一骑绝尘......而且此时又查了下空间，发现其实它一直都在增长，看起来是什么日志在疯狂输出。可是笔者电脑最近的 key 都用不了了，它到底在干嘛？
② 深入 Codex 目录，锁定 .tmp 隐藏目录
进入到 .codex 目录，发现一个隐藏目录 .tmp 占用巨大：
bash
% du -sh .*
344K .codex-global-state.json
344K .codex-global-state.json.bak
4.0K .personality_migration
156G .tmp进一步查看：
bash
.tmp % du -hs *
156G bundled-marketplaces
0B marketplaces
76M plugins
4.0K plugins.sha
0B plugins.sync.lock③ 确认无进程占用，排除"正在写入"的可能
确认无任何活动进程在占用写入该路径：
bash
% 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 文件夹内容，确认死循环堆积
确认是啥：
bash
% 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 ACodex 启动/同步插件市场 --> B{下载或解压是否成功?} B -- 否 --> C生成新的 staging 文件夹\
03 | 解决方案：三步清理，恢复空间
由于前面通过 lsof 已确认无任何活动进程在占用写入该路径，可以直接进行删除：
bash
cd
rm -rf ~/.codex/.tmp
mkdir -p ~/.codex/.tmp
清理完成后，系统数据占用恢复正常，空间告警也随之消失。
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一起成长~