前几天我正写着代码系统突然弹了个磁盘空间不足的警告。排查了半天发现罪魁祸首不是 node_modules也不是 Docker 镜像——是 Codex 在本地攒下的会话记录、日志和缓存光~/.codex一个目录就吃掉了 4.7GB。以前遇到这种情况我只能手动删文件但每次都要纠结哪些能删、哪些不能删删错了就得重新登录、丢上下文。直到我试了 CX Clear 这个专门给 Codex 做清理的小工具才彻底告别了这种手动操作。这篇文章就跟大家聊聊 Codex 到底在本地留下了什么、手动清理为什么容易翻车以及 CX Clear 是怎么把这件事做稳妥的。1. Codex 的“隐形资产”清单会话、日志与缓存都藏在哪很多人以为 Codex 就是个跑在云端服务的 AI 编程助手本地不存什么东西。这个想法只对了一半。Codex 为了让会话恢复、断线重连、结果缓存等功能能跑起来会在本地写相当多的数据。这些数据不像 Docker 镜像那么显眼但日积月累下来体积一样非常可观。1.1 会话记录最容易被低估的存储大户Codex 默认会把每次对话的原始消息、上下文、历史命令结果都存在本地目的是让你关掉终端之后还能通过codex resume继续之前的会话。这些会话文件以 JSON 格式存储在~/.codex/sessions/目录下。单个会话文件看起来不大几十 KB 到几百 KB 不等但问题在于会话数量积累得极快。我因为每天高频使用一个月能产生上千个会话文件。有一次我跑了一个长时间的重构任务Codex 每轮补全都会把完整对话历史写进会话文件单个文件直接飙到 5MB 以上。几十个这种大文件堆在一起就把磁盘空间吃掉了很大一块。更隐蔽的是Codex 还会为每个会话生成对应的索引缓存和消息副本。你表面上只发起了一次对话本地可能同时写了会话原文、会话摘要、消息列表三份数据。所以很多用户发现sessions目录比logs目录还大就是这么来的。1.2 日志与缓存看似小文件架不住数量多如果说会话记录是大头那日志和缓存就是“蚂蚁搬家”式增长。Codex 的日志目录在~/.codex/logs/下。正常使用时日志文件不大但架不住写入频繁。尤其是在遇到配置错误、模型调用失败这类场景时Codex 会在终端里反复报错背后同时疯狂写日志。比如有段时间我在 Codex 配置文件里把模型名填错了配了一个不存在的模型Codex 每次请求都会失败然后在日志里记录完整的请求和响应内容。一个下午的时间日志目录膨胀了 300MB 多。缓存方面的压力主要来自~/.cache/codex/。Codex 会把一些响应结果、预编译的能力描述、模型能力元数据缓存在这里避免每次请求都重新计算。这类缓存文件更新很频繁而且不会自动清理过期内容时间一长就会积攒出大量冗余数据。1.3 桌面版与 VS Code 插件的额外残留如果你不只使用 Codex CLI还安装了桌面版或 VS Code 插件那本地数据的位置就更多了。桌面版在 macOS 上会把数据放在~/Library/Application Support/Codex/Windows 上则在%APPDATA%\Codex下。这里除了会话数据还有窗口状态、本地存储、崩溃报告等。VS Code 插件的数据一般落在工作区目录下的.codex/文件夹里包括插件自身的日志、临时脚本、本地技能文件等。这些文件和项目代码混在一起经常被 Git 版本控制误纳入团队协作时还会互相污染工作区。我把这些数据位置整理成了一个表格方便你对照检查自己的机器Codex 形态主要数据位置典型内容体积增长速度CLI 终端版~/.codex/会话记录、日志、auth 凭据、历史命令快高频使用时每月可增长数 GBCLI 缓存~/.cache/codex/响应缓存、模型能力元数据中等持续累积桌面版~/Library/Application Support/Codex/或%APPDATA%\Codex窗口状态、会话副本、崩溃报告中等取决于使用频率VS Code 插件工作区.codex/、~/.vscode/extensions/下插件目录插件日志、临时文件、技能脚本较慢但会持续存在搞清楚这些东西都在哪你才能明白为什么 Codex 的“占用”这么难缠——它不是集中在一个地方而是散落在系统各个目录里手动清理很容易顾此失彼。2. 手动清理为什么总翻车误删登录态与文件锁死我自己手动清理过不下十次 Codex 的本地数据翻车的次数占了将近一半。不是删不掉就是删完之后 Codex 出各种问题。这里我把踩过的坑拆开讲讲你就知道为什么需要专门的清理工具了。2.1 auth 文件与“清理后重新登录”的惨案我第一次手动清理的时候打开~/.codex/目录看到一堆看起来很“没用”的 json 文件就顺手删了。结果下次启动 Codex发现登录状态丢了提示我重新登录。后来才反应过来~/.codex/auth.json这个文件保存了登录凭据我把它当成普通缓存一起删了。如果你用的是 Team 或企业版账号重新登录可能还涉及组织配置同步、密钥轮换等环节不是输个密码那么简单。我有一次清理完之后折腾了将近半小时才恢复所有配置中间还因为反复登录触发了安全风控被暂时限制了会话创建。所以清理 Codex 时auth.json这类凭据文件必须是“禁区”。这也是 CX Clear 这类工具存在的意义——它能在清理前识别出哪些文件动不得。2.2 正在写入的日志与索引文件引发的进程崩溃比误删更隐蔽的问题是文件状态不一致。Codex 桌面版和插件在运行时会持续写入日志和索引文件。如果你直接手动删除这些文件正好碰上进程持有文件句柄在 macOS 和 Linux 上可能表现为“删除后空间不释放”在 Windows 上则直接报“文件被占用无法删除”。更严重的是如果 Codex 正在读写日志文件时你把日志目录清空了进程会在下一次写入时拿到一个错误的文件偏移量轻则写入失败重则整个进程退出。我有一次手动清了日志之后Codex 桌面版直接进入“正在重新连接”的死循环重启也没用最后把整个配置目录都删了才恢复。2.3 隐藏目录与权限问题删不干净的另一层原因Codex 的某些数据目录名以点开头比如~/.codex、~/Library/Application Support/Codex在 Finder 里默认不可见。如果你在图形界面里操作很容易漏掉这些目录导致清理不彻底。权限问题同样常见。Codex 的会话目录往往以默认权限创建跨用户共享时甚至会出现 root 属主的文件。我之前用rm -rf ~/.codex/sessions时遇到过几次“Operation not permitted”的报错原因就是某些子目录的权限位不允许当前用户直接删除。手动清理时你往往还得套一层sudo去处理风险又进一步放大了。手动清理翻车案例总结误删auth.json→ 登录状态丢失、重新走安全验证流程。热删除日志文件 → 进程奔溃、“正在重新连接”死循环。漏掉隐藏目录 → 清理不彻底空间很快又堆满。跨用户/权限受限 → 部分目录删除失败被迫用 sudo 增加风险。我在踩了这么多次坑之后才下定决心找一个能识别 Codex 数据边界、自动排除敏感文件的清理工具这才接触到 CX Clear。3. CX Clear 的工作原理扫描、分类与安全边界设计CX Clear 本质上做的事很简单扫描所有与 Codex 相关的本地数据按“可清理、可保留、禁止触碰”三类做分类然后把“可清理”的部分安全删掉。但它的价值不在于“删”本身而在于整套安全边界的判断逻辑。3.1 先扫描后清理dry-run 预览模式的价值CX Clear 的第一个核心设计是“先扫描后执行”。你运行扫描命令时它会遍历上文提到的所有 Codex 数据目录把每个目录的体积、文件数量、最后写入时间都列出来然后给出清理建议。你可以先看一遍它准备删什么再决定实际清理的范围。第一次跑 scan 时我看到的输出就很有信息量$ cx-clear scan [扫描完成] 共发现 Codex 相关目录 12 个总占用 4.72 GB 可清理项目 - ~/.codex/sessions会话记录 3.21 GB 保存了 3421 个会话 - ~/.cache/codex响应缓存 862 MB 缓存文件数 5732 个 - ~/.codex/logs日志 383 MB 日志文件 214 个 - 桌面版 Application Support 缓存 158 MB 临时文件 36 个 建议保留 - ~/.codex/auth.json登录凭据 2 KB 禁止清理 - ~/.codex/config.toml配置文件 8 KB 保留 - 最近 7 天的会话记录 约 290 MB 可配置保留这种“先看后删”的交互方式是 CX Clear 最值得借鉴的地方。通常我在手动清理时唯一能依赖的就是du -sh和find命令逐个目录去猜哪些能删。CX Clear 把这套判断标准化了它会根据目录名、文件类型、修改时间、文件锁状态综合判断而不是一刀切。3.2 白名单机制哪些文件无论如何都不能动CX Clear 内部维护了一份“禁止清理”的白名单。除了最核心的auth.json和config.toml它还会保护用户自定义的供电配置、企业策略文件正在被 Codex 进程占用的文件它会先检查是否有进程持有文件句柄最近 N 天内活跃的会话默认保留 7 天所有体积小于某个阈值但可能包含关键状态的小文件。白名单机制的意义在于清理工具最常见的翻车方式就是“把一个本来有用的文件当成垃圾删除”。CX Clear 的做法是“宁可少删也不错删”。它在扫描结果里会明确标注每个文件被判定为“可清理”的依据——超期、冗余、缓存、临时文件等。如果有疑问你可以手动把文件加入“保护目录”列表工具就不会碰它。3.3 清理规则的默认策略与可调参数对于“多大算旧、多少天算过期”这类问题CX Clear 提供了可配置的策略。默认策略比较保守会话记录保留最近 7 天的活跃会话7 天前的会话如果确认可以清理则删除。日志只保留最近 3 天的日志更早的一律清掉。缓存清空所有响应缓存因为这些重新请求就能拿回来。这些参数都可以通过配置文件调整。我是这样设置的# cx-clear 的默认策略配置示例 [cache] clear_all true [sessions] keep_days 14 # 保留最近 14 天的会话更早的会进入可清理列表 [logs] keep_days 7 # 日志保留一周方便回溯问题 [protected] paths [/path/to/my-skill, /tmp/important-codex-backup] # 额外保护路径工具清理时不会触碰我对默认策略做了一处调整——把会话保留天数从 7 天改成 14 天。原因是我的很多项目周期比较长两周内的历史上下文对继续开发很有价值超过两周的会话基本已经不需要恢复了清掉也不影响工作流。4. 实操从安装到完成一次安全清理的完整流程我目前用的 CX Clear 版本是 0.4.x不同版本参数可能有细微差别但整体流程是一致的。安装和使用都围绕三条命令展开scan扫描、clean清理、verify验证。下面是我从零开始跑通完整流程的记录。4.1 安装与首次初始化CX Clear 的安装方式因平台而异。我是在 macOS 上通过包管理器装的Linux 上也可以直接下载编译好的二进制放全局路径Windows 的安装包是单独的 msix 或 exe 格式。装完之后第一步是初始化。初始化不是让你注册账号而是让工具生成默认配置文件~/.config/cx-clear/config.toml同时自动检测机器上已经存在的 Codex 数据目录。如果检测到 Codex 桌面版和 CLI 同时存在它会把两处数据源都加入扫描范围。我在第一次初始化时遇到一个小问题工具默认认为 VS Code 插件的缓存也属于可清扫范围但我当时开着 VS Code 和 Codex 插件插件正在写入工作区临时文件扫描结果里那一项一直显示“文件被占用跳过”。后来我把 VS Code 关掉再跑初始化所有数据源才全部识别成功。所以一个很重要的经验是清理前先关闭 Codex 桌面版和编辑器插件。CX Clear 虽然会跳过被占用文件但只有完整退出 Codex 相关进程扫描结果才完整清理覆盖率才能拉满。4.2 一次标准清理的完整命令与输出解读安装并初始化完成之后我的标准清理流程是这样的# 1. 先扫描只读操作不会删除任何东西 cx-clear scan # 2. 确认扫描结果没问题后先跑一次 dry-run # dry-run 会完整执行清理逻辑但只输出“将删除哪些文件”并不真正删除 cx-clear clean --dry-run # 3. 实际清理 cx-clear cleanclean --dry-run这个步骤非常重要。它会模拟实际清理过程把将要删除的文件逐条列出来并给出每个目录释放的空间预估。我清理之前看到预计释放 4.1GB执行完之后实际释放 3.97GB差距很小。执行cx-clear clean之后工具会输出类似下面的内容[清理完成] 已释放 3.97 GB 磁盘空间 - 清理会话文件 3251 个释放 2.94 GB - 清理缓存文件 5568 个释放 846 MB - 清理日志文件 187 个释放 155 MB - 跳过受保护文件 46 个总计 26 MB看到“跳过受保护文件”这一栏心里会比较踏实——说明 auth.json、config.toml 和最近 14 天的活跃会话都没被动过。如果清理过程中有文件因为权限问题删不掉工具还会给你一个错误列表并建议你用sudo cx-clear clean --force处理。但我的建议是非必要别用--force。优先排查是不是有 Codex 相关进程没有退干净而不是直接强行删除。强行删除的风险是你没法确认这些文件当前是否正在被使用。4.3 针对不同 Codex 形态的专项清理命令除了整体清理CX Clear 还支持只清理某一类数据。这个细分功能在实际使用中非常省心# 只清理会话缓存保持登录状态 cx-clear clean --target sessions # 只清理日志文件 cx-clear clean --target logs # 只清理桌面版应用支持目录 cx-clear clean --target desktop # 只清理 VS Code 插件的本地缓存 cx-clear clean --target vscode我最常用的是cx-clear clean --target sessions --keep-days 30这个组合每个月手动执行一次把 30 天前的会话全部清掉。这样保留的历史会话足够我回看前面的项目脉络磁盘又不会因为频繁清理而反复删写同一个目录减少对 SSB 寿命的影响。如果你只是短期内存告急只想解决最占空间的那一块那直接--target sessions就够了。一次清理通常能释放掉 Codex 总占用的 60% 到 70%。5. 清理后要做的事验证、异常恢复与定时维护清理完成并不是终点。很多人在清理 Codex 本地数据之后出现“登录不上”“组织设置加载失败”“历史会话找不到”等问题大约 80% 和清理工具本身没关而是清理之后没有做验证和善后。5.1 清理后的健康检查清单我每次清理完会在终端跑一遍基础检查内容不多但很有效# 1. 确认登录状态还在 codex login status # 2. 确认核心目录存在并相对干净 du -sh ~/.codex ls ~/.codex/auth.json # 3. 开启一个简单会话验证上下文加载正常 codex ping重点看auth.json是否还在、sessions目录里是否还能看到最近几天的会话。如果这些都没问题基本可以判定清理是成功的。如果 Codex 桌面版之前还在后台挂着清理后建议彻底退出再重启一次让它重新加载配置而不是沿用旧的缓存状态。5.2 误删后的恢复手段与备份习惯虽然 CX Clear 的默认策略已经很稳健但保险起见我在大清理之前会手动备份 auth 和配置文件mkdir -p ~/codex-backup-2025 cp ~/.codex/auth.json ~/codex-backup-2025/ cp ~/.codex/config.toml ~/codex-backup-2025/这个习惯救了我不止一次。有一次我改配置时把model字段写错了导致 Codex 所有请求都报错。当时我以为需要重装后来直接从我自己的备份目录里把 config.toml 恢复回来一分钟就解决了问题。如果你已经清理完了才发现登录状态异常也别慌。先用codex login重新走一遍登录流程然后把 session 目录里剩下的事件文件看一遍确认没有把“未导出的工作上下文”全部删干净。实在恢复不了就接受现实——清理后会话本来就没了下次注意备份。5.3 让清理自动化定时任务与“清理后重装”组合拳CX Clear 支持与系统定时任务联动。我在 macOS 上用 launchd在 Linux 服务器上直接写 cronWindows 则可以用任务计划程序。每周日凌晨跑一次全量清理日常不再需要盯着磁盘。我目前放在 cron 里的清理脚本是这样写的#!/bin/bash # 每周清理一次 Codex 缓存与旧日志 cx-clear clean --target logs --keep-days 3 cx-clear clean --target cache --clear-all这样一来Codex 的本地占用基本长期保持在 1GB 以下。以前我是等磁盘报警了才手动清一次现在是它每周自己维护省心太多了。如果你遇到的是“Codex 安装卡死”或“配置损坏”这种更严重的问题我的经验是先用 CX Clear 完整清一遍再卸载重装。很多人重装失败就是因为本地残留了旧的会话索引和配置缓存导致新版本写入冲突。清理干净之后重装成功率明显更高。写在最后我在实际使用中的体会是CX Clear 并没有做什么“黑科技”它就是把每一条清理规则、每一个受保护文件都设计得明明白白。对于高频使用 Codex 的人来说能省下来的是每周手动翻目录的那一两个小时以及误删登录态之后的折腾成本。最后再分享一个小技巧把 CX Clear 的 dry-run 输出保存下来对比每次清理前后磁盘占用差异。当你发现单周积攒的数据量明显减少时其实说明 Codex 的日志或缓存异常写入已经减轻了——这也是一种判断 Codex 配置是否健康的间接信号。