如果你在搜 com.openai.codex.code_sign_clone，大概率不是想读一篇技术散文，而是磁盘莫名变小、du 之后翻到一堆奇怪的文件夹，想搞清楚这玩意儿是不是病毒、能不能删、删了会不会把 Codex.app 弄坏。先把答案给你：它不是报错，也不是被入侵，是 Codex 桌面应用每次启动都会留下来的临时目录，每次大约 1 GB 左右，从来不清理。
更扎心一点：这是 Chromium 上游设计意图，OpenAI 把它继承下来但没补上”退出时清理”的那一步。所以这篇要做两件事——把 code_sign_clone 到底是什么讲清楚，再把一行清理命令交给你，外加聊一聊在 macOS 上长期跑 AI CLI 工具链需要注意的几个磁盘陷阱。
先把误解纠正：code_sign_clone 不是错误码
很多人第一次看到 com.openai.codex.code_sign_clone，是在某个磁盘清理工具的报告里，或者 du -sh ~ 之后看到 /private/var/folders/ 下出现一堆陌生目录。名字里又是 openai、又是 code_sign、又是 clone，怎么看都像权限错误或者签名校验失败。
它其实就是一个临时目录的名字。完整路径长得像这样：
/private/var/folders/xx/xxxxxxxxxxxxxxxxxxxxxxxxxx0000gn/X/com.openai.codex.code_sign_clone/code_sign_clone.XXXXXX/Codex.app
里面是一个完整的 Codex.app：Info.plist、可执行文件、Frameworks、所有 Helper，应有尽有。整个目录大概 100 MB 到 1 GB 之间。Codex 每次启动都会生成一个新的，旧的不会被删。如果你装了 auto-update 又长期不重启 macOS，这个目录数能从 5 个滚到 60 个，磁盘很容易就被吃掉几十 GB。
所以没有任何”错误”发生。它的英文字面意思已经写清楚了：code sign clone，”代码签名克隆”。但这不是失败的克隆，而是一次主动复制 + 保留签名状态的正常操作。
它从哪儿来：Chromium 的 App Bundle Clone 机制
code_sign_clone 不是 OpenAI 发明的，它来自 Chromium 浏览器项目里一个叫 code_sign_clone_manager 的子模块。Chromium 引入这套机制的初衷，是为了解决一个非常具体的工程问题：当应用进程仍在跑、auto-updater 准备替换磁盘上的 .app bundle 时，怎么让正在跑的进程继续保持有效的代码签名？
macOS 的签名校验既有静态的（启动时验 Info.plist + 可执行文件哈希），也有动态的（运行中校验载入的库、helper、子进程）。如果 updater 把旧的 .app 直接覆盖掉，正在跑的进程一旦触发任何动态校验——比如加载一个 Framework、spawn 一个 Helper——就会因为签名不匹配崩掉。
Chromium 的解法是利用 APFS 的 clone 特性：在临时区克隆一份 .app（实际上是 hard link + 写时复制，几乎不占新空间，10 毫秒级完成），然后用这份 clone 跑业务。Updater 想换 .app 就换 .app，反正运行中的进程读的是 clone 路径，签名永远稳定。这个设计本身是漂亮的。
Codex 桌面端是 Electron 应用，内核就是 Chromium，于是这套 clone 机制原封不动被继承下来。问题在 Codex 没接好 Chromium 留出来的清理钩子——没有在 quit 时调用 clone manager 的回收逻辑，也没有 atexit 注册。Chromium 浏览器自己关掉是会清的，Electron 套壳里多了一层生命周期，链路就断了。
真实用户的现场：几十 GB 不是个段子
如果你不信单次启动能留 1 GB，可以自己跑一行：
du -sh /private/var/folders/*/X/com.openai.codex.code_sign_clone/* 2>/dev/null
社区里报上来的数据基本都很难看。有人 35 个目录 35 GB，有人单一目录 1.2 GB，最夸张的一例是 62 GB——这位老兄装了 Codex 几个月，从不重启 mac，每天用 auto-update，几个月堆下来直接把 SSD 吃干净。
可以叠的几个观察：
- 100% 来自 Apple Silicon：Intel Mac 几乎没人报告，不是因为 Intel 用户少，是因为 Codex.app 主力分发就是 arm64，且 APFS clone 在 Apple Silicon 的 SSD 上更便宜，触发频率更高
- macOS Sequoia 15.x 和 Tahoe 26.x 集中爆发：不是这两个版本的锅，是 Chromium M125+ 才引入这套 clone 策略，Codex 用的 Chromium 内核刚好是 M148，所以任何能跑 Codex 的 macOS 版本都会中招
- 跟你装没装杀软、有没有开 SIP、Gatekeeper 配置无关：这个目录是 Codex 自己写的，签名状态正常，没有任何系统组件会去拦它，也不会主动清
GitHub 上跟这件事相关的 issue 至少 5 个，其中 #25667、#27536、#27789、#28518、#26797 都是同一件事的不同复述。OpenAI 官方至今没有任何 maintainer 回应，最新一个被关掉只是因为标记成了”重复 issue”，没有 fix commit。
一行清理命令
直接给你能跑的：
rm -rf /private/var/folders/*/X/com.openai.codex.code_sign_clone
注意：
- 路径里的
*是必须的。/var/folders/下面是按用户哈希分桶的，不是固定路径 - 删之前可以先
du -sh看一眼省了多少，给自己一点心理安慰 - 删完不需要重启，Codex 下次启动会重新生成一个新的（约 100-200 MB 起步，跑久了再涨）
- 如果你用 zsh 且开了
nullglob，路径里*没匹配到东西不会报错，正常
不放心的话可以两步走：先 ls 看清楚要删什么，再 rm：
ls -lah /private/var/folders/*/X/com.openai.codex.code_sign_clone/
rm -rf /private/var/folders/*/X/com.openai.codex.code_sign_clone
不要去碰下面这些，跟 code_sign_clone 没关系，乱删会出问题：
/private/var/folders/*/T/下面任何东西（系统应用各种缓存全在这）~/Library/Application Support/Codex/（你的对话历史、配置）~/.codex/（CLI 的 token 和会话记录）/Applications/Codex.app/本体
为什么 OpenAI 至今没修
这个问题第一次有人报上去是 2026 年 5 月，到现在两个月过去，OpenAI 团队连一句官方回应都没给。按它今年的版本节奏，几乎每周一个 release，但所有 release notes 里都没出现过 code_sign_clone、cleanup、temp directory 之类的字眼。我的猜测是这样：
- 它不是 P0：Codex 用户绝大多数是 dev 群体，磁盘量都不小，1 GB 一次的泄漏没到逼着你立刻处理的程度。社区自救一行 rm 就能解决，反推回去就是优先级压不上去
- 修起来要碰 Electron lifecycle 的脏区：Electron 应用关闭路径分主进程退出、Renderer 退出、Helper 退出三段，要在哪一段调清理才不卡用户操作，不是一行代码能搞定的事
- 真正的修复点可能在 Chromium 上游：Codex 团队不一定愿意 patch 自己的 Electron fork，更愿意等 Chromium / Electron 上游统一处理
如果你想让这事推进得更快，去那个还 open 的 issue（27789 是最活跃的一个）点个 +1、贴一下你自己的 du 数据就够了。OpenAI 内部排优先级，多半也是看 reaction 数。
一个很容易被忽视的副作用：备份和同步工具也跟着遭殃
/private/var/folders/ 默认不在 Time Machine、Arq、Backblaze 的备份范围里——但iCloud Drive、Dropbox、OneDrive 在某些配置下会扫到。我见过有人发现 Dropbox 客户端 CPU 永远在 30%，排查半天才发现是 Codex 每天新生成的几 GB 临时文件被错配进了同步队列，后台一直在算 hash 看要不要传云端。
这种二阶效应更难察觉，因为表象不是”磁盘满”而是”风扇响、CPU 高、电池掉得快”。如果你看到上述症状又恰好装了 Codex.app，先去 Console.app 看一眼是不是 bird（CloudKit）或同步客户端在频繁读写 /private/var/folders/。修法跟前面一样：清 clone 目录，并且在同步工具里把 /private/var/folders/ 加进排除清单。
几个名字相近但完全无关的真问题
经常有人把以下这些跟 code_sign_clone 混在一起，搜出来的修复方案胡乱套用，越搞越乱。这里划一下界线：
1. CLI 启动报 “App is damaged” 或权限拒绝
你装的是 codex CLI（不是 .app 桌面端），第一次跑就直接被 macOS Gatekeeper 拦了。这是 com.apple.quarantine 扩展属性的问题，跟 clone 机制无关。解法是：
xattr -d com.apple.quarantine $(which codex)
或者更彻底：
xattr -dr com.apple.quarantine /opt/homebrew/bin/codex
具体路径取决于你怎么装的。Homebrew 装在 Apple Silicon 上是 /opt/homebrew/bin/，Intel Mac 是 /usr/local/bin/。npm 全局装的话路径在 $(npm config get prefix)/bin/codex。
2. codesign --remove-signature 不要乱用
我看到有教程教大家用 codesign --remove-signature /Applications/Codex.app 来”修签名”。这跟 code_sign_clone 完全没关系，反而会把签名状态彻底破坏，下次 auto-update 失败、Helper 不能 spawn、CUA service 直接 SIGKILL。除非你知道自己在做什么（比如调试 entitlements），别碰这个命令。
3. SkyComputerUseService、CUA Helper SIGKILL
这是另一类完全不同的问题，跟 macOS 的 Launch Constraints 系统有关。如果你在 macOS 26.x（Tahoe）上跑 Codex 的 Computer Use 功能看到 SkyComputerUseService 或 com.openai.sky.CUAService 被 SIGKILL，那是 Apple 收紧了 Helper 的允许启动规则，需要 Codex 团队更新签名配置。社区里也有 issue 跟，跟磁盘泄漏不是同一件事。
4. ~/.codex/ 越来越大
CLI 模式下 ~/.codex/ 会存放对话历史、Session token、模型缓存。如果你高频用 Codex CLI，这个目录也会涨，但单位是 MB 不是 GB。要清的话直接进去看 sessions/ 和 cache/ 子目录，按时间删旧的，不会影响登录态。
临时方案 vs 中期方案
短期能做的：把这行加到你的 crontab 或 launchd plist 里，每天凌晨 3 点清一遍：
0 3 * * * rm -rf /private/var/folders/*/X/com.openai.codex.code_sign_clone 2>/dev/null
或者写成一个 .zshrc 别名，每次开终端的时候手动 cleancodex 一下：
alias cleancodex='du -sh /private/var/folders/*/X/com.openai.codex.code_sign_clone/* 2>/dev/null; rm -rf /private/var/folders/*/X/com.openai.codex.code_sign_clone'
如果你想做得更工程化一点，可以把这条命令放进 launchd .plist，让它跑得比 cron 更稳——cron 在睡眠状态下不会唤醒系统，launchd 会。StartCalendarInterval 设凌晨 3 点，LowPriorityIO 设 true，跑起来既不抢盘也不会被电量管理误杀。这套做法在自动化 AI 工具链运维上挺通用，我在 OpenClaw 自动化 Agent 运维实战：从 Cron 报错到系统性治理 里展开过一次完整的 cron → launchd 迁移踩坑记录，思路是一样的。
中期能做的：
- 关闭 Codex.app 的自动更新。Settings → General → Automatic Updates 关掉。这不会减少单次启动的克隆量，但能减少每次更新触发的额外克隆——auto-update 流程会先 clone 一份新版本，再 swap 旧版本，整套下来克隆数翻倍
- 改用 Codex CLI。如果你的日常工作流不强依赖桌面端的 UI（编辑器集成、对话历史浏览），CLI 完全没有这个问题，因为 CLI 不是 Electron 应用，不走 Chromium 那套 clone 机制。Codex CLI 的本地部署可以参考 不等 Cursor 企业版：Codex CLI 本地部署完整实战。CLI 和桌面端在心智模型上其实是两套东西，Claude Code CLI 最新指令集：别再只会 /clear 了 这篇文章里聊过同类的 CLI 优先论：长期跑 AI 工具的人，CLI 永远比桌面端更省事、更可控、更可脚本化
- 定期重启 macOS。
/var/folders/在系统重启时会清掉一部分（按purgeable space规则），不靠谱但有用
长期方案：等 OpenAI 在 Codex 的 Electron 主进程 quit 路径接好 clone manager 的清理调用。从历史经验看，这种”用户日常会撞但不影响核心功能”的 bug，OpenAI 修复周期通常在 3-6 个月。
顺手看：macOS 上”clone-on-update”为什么成主流
我顺着这件事去看了一圈，发现 macOS 桌面应用最近两年大量在用同一套模式：APFS clone + 临时目录跑业务 + 写时复制。Chrome、Edge、Discord、Slack、VS Code、Cursor，凡是基于 Electron 或 Chromium 的应用，几乎都引入了类似机制。
这件事还有一段前情。早年 macOS 桌面应用做”无感更新”，主流方案是 Sparkle 框架——一个第三方更新库，原理是下载新版 dmg/zip、退出当前应用、解压覆盖、重启。Sparkle 体验已经不错，但它的核心矛盾是必须退出当前应用。对短任务工具问题不大，对长会话型应用（浏览器、IDE、IM）就要命：你正在跟 AI 对话到一半，应用提示要重启更新，体验上是个明显的中断。Chromium 这套 clone-on-update 是为了把”必须退出”这一步也去掉，让更新对用户彻底无感。我之前在 Telegram macOS 安装踩坑全记录 里也聊过类似的更新策略对比，可以看到不同应用为了”无感更新”做了多少奇技淫巧。
这本质上是为了解决一个产品决策矛盾：
- 用户希望应用更新无感、不打断当前操作
- 但 macOS 签名校验要求运行中的进程二进制不能被替换
APFS 的 clone 是个非常便宜的原语（10 毫秒级别、不消耗额外块空间），所以这套模式天然适合 macOS。问题是 macOS 系统层没有提供”我克隆出来的临时副本什么时候该清”的生命周期标记。每个应用都得自己接 atexit、自己处理崩溃恢复，于是泄漏是普遍现象，只是程度不同。
我手头那台用了一年的 M2 MacBook，跑 du -sh /private/var/folders/*/X/ 一下出来 12 GB，里面有 Codex 的 1 GB，有 Cursor 的 800 MB，有 Discord 的几百 MB，剩下都是各种 Helper 进程的临时缓存。这不是 Codex 独有的坑，是整个 Electron 生态在 macOS 上的通病。Codex 只是因为单次克隆体量更大、更新更频繁，被先骂出圈。
在 macOS 上长期跑 AI CLI 工具链需要注意的事
借这次的事讲两句更系统的看法。如果你在 macOS 上长期用 Codex、Claude Code、Cursor、Cline 这一类工具，会发现磁盘消耗远比想象中快。原因不止 code_sign_clone：
- 每个 CLI 都有自己的 cache、log、session。
~/.codex/、~/.claude/、~/.cursor-server/等等，加起来很容易上 GB - 依赖装在 node_modules / .venv 里。如果你给不同项目都装
@anthropic-ai/claude-code全家桶，本地 node_modules 加起来非常恐怖 - Electron 桌面端的 cache。
~/Library/Application Support/下各 AI 应用动辄几百 MB 起步 - 模型权重不算少。本地跑 Ollama 一个 70B 模型就是 40 GB，多装几个能瞬间把 SSD 干掉
一些可参考的实践：
- 用 Mac 磁盘清理工具 定期审计，看清楚哪些目录在涨，再有针对性地清
- AI 工具链管理上，Codex CLI 的全栈实战可以参考 Codex CLI 完整入门，里面包含安装、工作流、跟 Claude Code 协同
- 想看 Codex 和 Claude Code 的设计对比，Plugin 这一层：Codex 和 Anthropic 的新打包方式 是个不错的切入点；模型层的横向比较可以看 Opus 4.6 vs GPT-5.3-Codex：同一晚的两条路线
- Codex 在工程化上的几个亮点，比如执行历史里自动找补丁的能力，可以看 Codex 在自己的执行历史里找补丁 和 OpenAI Codex 现已支持录制工作流并自动生成可复用技能
- 如果你主力 Linux，但偶尔跑 macOS 验证，权限和沙箱模型差异比较大，可以参考 Linux 效率指南：解锁 Claude/Codex CLI 最高权限以绕过沙箱限制
macOS 排障思路：磁盘异常的几个常见根因
不光是 Codex，整个 macOS 工具链上磁盘异常的根因基本就那么几类，我按照踩过的频次排个序：
- Electron 应用的临时 clone——也就是这次的 code_sign_clone 一类，1-50 GB 量级
- Homebrew 的依赖混乱——升级链路里某个老依赖没清，新依赖又装了一份。这种问题我在 OpenClaw 在 macOS 突然”全挂”排障实录：Homebrew 动态库 ABI 漂移 里详细写过，本质是 brew 的依赖管理在多个大版本切换时容易残留
- 本地模型权重忘记清——Ollama、LM Studio、MLX 跑过的模型不会自动清理。彻底卸载 macOS 上的 Ollama 里有一份手动清理路径列表
- node_modules 累积——尤其是 CLI 工具全局装时，多次升级会留下旧版本副本
- iCloud Drive 本地缓存——这是另一类很难察觉的，单文件几百 MB，攒起来惊人
排查节奏一般是这样：先 df -h 看哪块满，再 du -sh /* 找大头，再往下逐层 du -sh dir/*。不要直接信桌面端的”关于本机 → 储存空间”，它经常把”其他”算得很离谱。
写在最后
code_sign_clone 这个名字看起来吓人，本质就是 Chromium 上游一套”App Bundle 克隆 + 写时复制”机制的副作用，Codex 桌面端是 Electron 套壳所以继承了它，只是没接好清理钩子。修复的事 OpenAI 还在拖，目前最有效的方案就是那行 rm -rf 命令，或者干脆挂到 cron 里。
更大一层的看法是：Electron 把”跨平台桌面”做到了能用，但 macOS 这套生命周期 + 签名 + 临时目录的设计，本来就没有为”频繁热更新的 GUI 应用”做优化。这类磁盘泄漏未来还会反复出现在新的 AI 工具上，不是 Codex 独有。养成定期审计磁盘 + 用 Mac 磁盘清理工具 之类的工具盯一下大块异常增长的习惯，对长期跑 AI 工具链的人是个值得做的功课。
回到工程审美的层面想：好的工具应该让用户感知不到自己的运行成本。一个每次启动悄悄写 1 GB 进 /var/folders/ 还不清的应用，技术上能跑，但工程心智上是不及格的。这种细节决定了一款工具是”能用一年的生产力工具”还是”装上吃灰一周就卸的玩具”。希望 Codex 团队尽快把这块补上——毕竟从 Codex CLI 完整入门 看，整个 Codex 产品线在能力上确实是顶尖的，缺这一脚拼图太可惜。
如果你想顺着这条线继续看 AI 工具的工程化，Claude Code 在做减法 和 Agent Harness 到底是什么？万字入门 是两篇值得读的。前一篇讲产品收敛的思路，后一篇讲怎么把 AI 工具组装成可以自己跑的系统。再往前一步，从写 Prompt 到写 Loop 讲的是从对话式工具往循环式 Agent 的过渡——这一波 AI 工具链整体的演化方向，跟磁盘泄漏这种细节看起来不挨着，但都是同一个母题：工具的工程心智到不到位。
