前几天我正写着代码，系统突然弹了个磁盘空间不足的警告。排查了半天，发现罪魁祸首不是 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 的“占用”这么难缠——它不是集中在一个地方，而是散落在系统各个目录里，手动清理很容易顾此失彼。

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 clean

clean --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 服务器上直接写 cron，Windows 则可以用任务计划程序。每周日凌晨跑一次全量清理，日常不再需要盯着磁盘。

我目前放在 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 配置是否健康的间接信号。