前段时间我发现 C 盘空间掉得有点快。我平时写代码用 OpenAI Codex 比较多加上偶尔还会用 Claude Code 和 Cursor。虽然知道本地会有缓存但平时也没怎么管。直到有一天下依赖包提示磁盘空间不足我才顺手打开树状目录工具扫了一下发现 Codex 在本地攒下了相当大的一块体积。我第一反应其实很简单找到对应的目录全选Shift Delete。但真把资源管理器翻开的时候手停住了。如果你去看这些 AI 编程工具在 Windows 本地写的数据一般都在%APPDATA%、%LOCALAPPDATA%或者用户主目录下的隐藏文件夹里里面的东西其实挺杂的。以 Codex 为例里面堆着很多会话记录、日志、模型或上下文相关的缓存还有一些工具自身运行时的配置和索引。有些文件夹体积确实很大但你很难一眼看出来删掉它会有什么后果。删了会话历史之前的上下文是不是就丢了删了某些 cache下次启动会不会报错还是只是需要花点时间重新拉取或重新生成那些好几个月前写下的运行日志留着除了吃磁盘空间之外还有没有别的用处每个工具的做法也不一样。Codex 把东西堆在一处Claude Code 有它自己的组织逻辑Cursor 又是另一套结构。当时我就想要是我每次清磁盘都得把这几个目录一个个翻出来凭记忆去猜“这个文件夹能不能删”、“那个 sqlite 文件删了会不会坏”做个两三次人就烦了。我一开始真的没想做多复杂的东西甚至只打算写几个简单的脚本把 Codex 那些明确能删的缓存清掉。但脚本写着写着发现痛点根本不是“删除”这个动作而是怎么判断。真正麻烦的不是删除而是判断不能只看文件大小。很多普通的清理工具逻辑很简单扫描整块磁盘挑出大于 500MB 的文件或者无脑删临时文件夹。但在 AI 编程工具这个场景下这么做很容易踩雷。有些很大的文件是核心依赖或当前项目的上下文索引删了之后下次启动要么极慢要么配置错乱反而很多几百兆的旧日志、失效缓存散落在深层子目录里单个文件不大合起来却占了好几 GB。所以我给 CX Clear 设计清理逻辑时核心放在了分类与策略上。目前 CX Clear 主要支持 Codex、Claude Code 和 Cursor。针对不同的工具底层的扫描并不是简单地跑一个通用通配符而是针对每个工具的数据特性做适配。数据大致会被划分为几种情况确定安全的临时缓存、失效的旧日志、以及绝对不能动的用户配置和凭据。除了看它是什么还要看它存在了多久。一个今天刚生成的缓存删了大概率明天软件又要重新写一份除了白白增加 SSD 的写入损耗没有任何意义但一个三个月前某次调试留下的几个 G 日志以后几乎不可能再翻出来看。理清这套分类之后清理流程就变成了两步先识别与定级搞清楚这堆字节到底属于什么类型、安全级别多高、清理后有什么代价第二步才是展示与执行让用户在删除之前明确知道自己删的是能重新生成的缓存还是几个月前的旧日志。把这些逻辑封装起来之后我给它做了一个直观的 Windows 本地界面点一下能看明白每个工具各自占了多少勾选后清理。我自己的 C 盘空间问题确实解决了。但在日常用了一阵子之后我又想到了另一个问题。为什么我还要做 CLI桌面界面很好用点点鼠标就能看结果。但我平时大部分时间其实都停留在终端里而且随着日常用 AI 的方式变化我发现自己越来越少去主动打开一个清理软件。我更自然的使用习惯可能是写代码写到一半或者跑命令失败时顺口问一句 AI“我 C 盘好像有点紧是不是本地那些 AI 工具占的帮我看一眼。”如果只有 GUI这件事情是断掉的。用户必须跳出当前终端打开软件等待扫描自己看图表。但我后来觉得这种“检查磁盘占用并做决策”的事情本质上特别适合让 AI Agent 来做。前提是CX Clear 必须给 AI 提供一个它能读得懂、看得明白的接口。这就是我后来专门做 CX Clear CLI 的原因。我没有把它单纯当成一个给键盘流用户的替代品而是把它设计成了可以被外部程序或 AI 调用的接口。如果只是让人在命令行看只要把结果打印成带颜色的表格就行了但如果要让 AI 处理纯文本排版就是一种灾难。因此在 CLI 里我很早就加上了结构化的数据输出比如 JSON 格式。当 CLI 跑扫描时输出的不是一句模糊的“Codex 占了 3.2GB”而是一份包含元数据的结构。有了这些字段CLI 和前面提到的清理策略就真正拼到了一起CLI 负责采集与结构化呈现把 Codex、Claude Code、Cursor 的实际占用摸清楚打上风险标签AI 拿到这个 JSON 之后不需要去瞎猜路径代表什么它能看到风险级别和字节大小然后用自然语言向用户汇报用户确认后AI 再通过 CLI 调用清理命令完成真正的释放。没有这套策略分级CLI 给出的就只是一堆冰冷的路径和数字没有结构化输出AI 就只能靠正则去猜命令行打印的文本。两边结合起来这个小工具才算有了点现代工具的味道。回过头看CX Clear 的代码库其实并不宏大它本质上还是一个专注解决特定场景问题的小工具。目前它在 Windows 上稳定支持 Codex、Claude Code 和 Cursor。我自己本地写代码时它基本上已经接管了这几个工具的缓存管理。C 盘告急的时候要么顺手敲一行 CLI 扫一下要么直接通过终端调脚本处理。我没有给它画什么宏伟的蓝图也没打算把它包装成什么全能的系统管家。AI 编程工具现在更新得非常快今天改个目录结构明天换一种缓存策略适配这些变动本身就需要持续花时间去维护。如果你平时也在 Windows 下重度使用 Codex、Cursor 或 Claude Code遇到过类似的磁盘焦虑或者你也正在尝试用命令行与 AI Agent 协作来管理自己的本地环境可以去 GitHub 看看它的代码moumoum0/cx-clear: CX-Clear 是面向 AI 编程工具的本地缓存清理工具。支持 Codex、Claude Code、Cursor等软件代码里可能没有特别玄妙的算法但它确实是我在真实敲代码和清磁盘的过程中一行一行摸索出来的东西。 为了不再手动管理 Codex 的占用空间和对话,我直接去做了个清理软件——cxclear
前段时间我发现 C 盘空间掉得有点快。我平时写代码用 OpenAI Codex 比较多加上偶尔还会用 Claude Code 和 Cursor。虽然知道本地会有缓存但平时也没怎么管。直到有一天下依赖包提示磁盘空间不足我才顺手打开树状目录工具扫了一下发现 Codex 在本地攒下了相当大的一块体积。我第一反应其实很简单找到对应的目录全选Shift Delete。但真把资源管理器翻开的时候手停住了。如果你去看这些 AI 编程工具在 Windows 本地写的数据一般都在%APPDATA%、%LOCALAPPDATA%或者用户主目录下的隐藏文件夹里里面的东西其实挺杂的。以 Codex 为例里面堆着很多会话记录、日志、模型或上下文相关的缓存还有一些工具自身运行时的配置和索引。有些文件夹体积确实很大但你很难一眼看出来删掉它会有什么后果。删了会话历史之前的上下文是不是就丢了删了某些 cache下次启动会不会报错还是只是需要花点时间重新拉取或重新生成那些好几个月前写下的运行日志留着除了吃磁盘空间之外还有没有别的用处每个工具的做法也不一样。Codex 把东西堆在一处Claude Code 有它自己的组织逻辑Cursor 又是另一套结构。当时我就想要是我每次清磁盘都得把这几个目录一个个翻出来凭记忆去猜“这个文件夹能不能删”、“那个 sqlite 文件删了会不会坏”做个两三次人就烦了。我一开始真的没想做多复杂的东西甚至只打算写几个简单的脚本把 Codex 那些明确能删的缓存清掉。但脚本写着写着发现痛点根本不是“删除”这个动作而是怎么判断。真正麻烦的不是删除而是判断不能只看文件大小。很多普通的清理工具逻辑很简单扫描整块磁盘挑出大于 500MB 的文件或者无脑删临时文件夹。但在 AI 编程工具这个场景下这么做很容易踩雷。有些很大的文件是核心依赖或当前项目的上下文索引删了之后下次启动要么极慢要么配置错乱反而很多几百兆的旧日志、失效缓存散落在深层子目录里单个文件不大合起来却占了好几 GB。所以我给 CX Clear 设计清理逻辑时核心放在了分类与策略上。目前 CX Clear 主要支持 Codex、Claude Code 和 Cursor。针对不同的工具底层的扫描并不是简单地跑一个通用通配符而是针对每个工具的数据特性做适配。数据大致会被划分为几种情况确定安全的临时缓存、失效的旧日志、以及绝对不能动的用户配置和凭据。除了看它是什么还要看它存在了多久。一个今天刚生成的缓存删了大概率明天软件又要重新写一份除了白白增加 SSD 的写入损耗没有任何意义但一个三个月前某次调试留下的几个 G 日志以后几乎不可能再翻出来看。理清这套分类之后清理流程就变成了两步先识别与定级搞清楚这堆字节到底属于什么类型、安全级别多高、清理后有什么代价第二步才是展示与执行让用户在删除之前明确知道自己删的是能重新生成的缓存还是几个月前的旧日志。把这些逻辑封装起来之后我给它做了一个直观的 Windows 本地界面点一下能看明白每个工具各自占了多少勾选后清理。我自己的 C 盘空间问题确实解决了。但在日常用了一阵子之后我又想到了另一个问题。为什么我还要做 CLI桌面界面很好用点点鼠标就能看结果。但我平时大部分时间其实都停留在终端里而且随着日常用 AI 的方式变化我发现自己越来越少去主动打开一个清理软件。我更自然的使用习惯可能是写代码写到一半或者跑命令失败时顺口问一句 AI“我 C 盘好像有点紧是不是本地那些 AI 工具占的帮我看一眼。”如果只有 GUI这件事情是断掉的。用户必须跳出当前终端打开软件等待扫描自己看图表。但我后来觉得这种“检查磁盘占用并做决策”的事情本质上特别适合让 AI Agent 来做。前提是CX Clear 必须给 AI 提供一个它能读得懂、看得明白的接口。这就是我后来专门做 CX Clear CLI 的原因。我没有把它单纯当成一个给键盘流用户的替代品而是把它设计成了可以被外部程序或 AI 调用的接口。如果只是让人在命令行看只要把结果打印成带颜色的表格就行了但如果要让 AI 处理纯文本排版就是一种灾难。因此在 CLI 里我很早就加上了结构化的数据输出比如 JSON 格式。当 CLI 跑扫描时输出的不是一句模糊的“Codex 占了 3.2GB”而是一份包含元数据的结构。有了这些字段CLI 和前面提到的清理策略就真正拼到了一起CLI 负责采集与结构化呈现把 Codex、Claude Code、Cursor 的实际占用摸清楚打上风险标签AI 拿到这个 JSON 之后不需要去瞎猜路径代表什么它能看到风险级别和字节大小然后用自然语言向用户汇报用户确认后AI 再通过 CLI 调用清理命令完成真正的释放。没有这套策略分级CLI 给出的就只是一堆冰冷的路径和数字没有结构化输出AI 就只能靠正则去猜命令行打印的文本。两边结合起来这个小工具才算有了点现代工具的味道。回过头看CX Clear 的代码库其实并不宏大它本质上还是一个专注解决特定场景问题的小工具。目前它在 Windows 上稳定支持 Codex、Claude Code 和 Cursor。我自己本地写代码时它基本上已经接管了这几个工具的缓存管理。C 盘告急的时候要么顺手敲一行 CLI 扫一下要么直接通过终端调脚本处理。我没有给它画什么宏伟的蓝图也没打算把它包装成什么全能的系统管家。AI 编程工具现在更新得非常快今天改个目录结构明天换一种缓存策略适配这些变动本身就需要持续花时间去维护。如果你平时也在 Windows 下重度使用 Codex、Cursor 或 Claude Code遇到过类似的磁盘焦虑或者你也正在尝试用命令行与 AI Agent 协作来管理自己的本地环境可以去 GitHub 看看它的代码moumoum0/cx-clear: CX-Clear 是面向 AI 编程工具的本地缓存清理工具。支持 Codex、Claude Code、Cursor等软件代码里可能没有特别玄妙的算法但它确实是我在真实敲代码和清磁盘的过程中一行一行摸索出来的东西。