Codex会话会占满C盘吗?Codex本地会话数据清理指南

前几天我打开 Windows 用户目录下的 .codex\sessions，看到里面排着一批这样的文件：

rollout-2026-08-03T13-54-22-019fc630-....jsonl

有的文件只有几百 KB，有的却有几十 MB，其中一个甚至超过了 100 MB。再想到自己已经在 Codex 里建了不少对话，自然会担心：这些是什么文件？长时间聊天会不会让上下文越来越大？如果一直新建对话，C 盘是不是迟早会被吃满？

我把本机相关目录拆开看了一遍。结论是：这些文件确实属于 Codex 的本地会话记录，但对话不是 C 盘占用的唯一来源，甚至未必是最大的来源。上下文压缩、归档对话和删除文件，也分别解决不同的问题。

rollout-*.jsonl到底是什么

.codex\sessions 里的 rollout-*.jsonl，可以理解为 Codex 为每个任务保存的事件流水。

文件名中的 rollout 表示会话记录；中间的日期和时间通常对应任务创建时间；最后一长串字符是唯一的线程 ID。.jsonl 是逐行 JSON 格式，每一行记录一个事件，便于程序持续追加和恢复。

里面可能包含用户消息、模型回复、系统与项目指令、工具调用、命令输出、文件引用、上下文摘要和会话状态。它不是每说一句话就创建一个文件，通常一个文件对应一个线程。短时间内出现多个文件，也可能来自新任务、会话分支、重试或子代理线程。

如果文件名显示任务在 8 月 3 日创建，资源管理器里的修改时间却是 8 月 4 日，通常只是说明这个任务第二天又继续使用了。

这些文件可以用文本编辑器打开，但不适合手工修改。它们可能包含项目路径、命令输出和聊天内容，分享前也应当按敏感资料处理。

为什么一个会话能长到上百 MB

日常问答本身通常没有那么大，真正容易推高会话文件体积的，是工具输出。

例如一次递归搜索可能返回几千行结果，一段构建日志可能持续输出几分钟，网页抓取可能带回大段文本，图片也可能留下引用或编码数据。Codex 为了让任务能够恢复，会把许多过程事件写入本地记录。

这也解释了为什么两个聊天时间差不多，文件大小却能相差几十倍。一个只讨论方案的对话可能很小，另一个反复运行命令、读取日志和处理图片的任务，增长速度会快得多。

上下文压缩不等于磁盘清理

长对话会受到模型上下文窗口限制。为了继续工作，Codex 可以对较早内容进行压缩，把大量历史整理成更短的摘要，再把摘要和近期内容交给模型。

这解决的是“模型一次能看多少内容”的问题，不是“硬盘保存了多少文件”的问题。

压缩之后，模型不必在每一轮重新读取全部原始历史，但本地的会话流水通常仍需保留，用于显示记录、恢复任务和维护状态。因此，一个对话已经发生过上下文压缩，并不代表对应的 JSONL 文件会立刻缩小。

压缩还有一个现实代价：摘要会保留主要目标和关键决定，却不可能保证每个早期细节都原样留下。如果后续工作高度依赖某个旧版本参数、具体报错或临时约定，最好把它写入项目文档，而不是只放在一段越来越长的聊天里。

Codex 的本地数据不只在sessions

Windows 上，Codex 的主要状态默认位于：

%USERPROFILE%\.codex

常见内容大致分为几类：

这些名称来自当时使用的 Codex 版本和本机观察，后续版本可能调整目录与数据库结构。它们适合帮助理解和排查占用，不适合据此编写自动删除脚本。

这里还有一个容易混淆的概念：会话历史和“记忆”不是一回事。

会话历史记录某个线程发生过什么；记忆则是经过整理、可能在其他任务中复用的信息。删除一个对话、清理界面缓存和管理跨会话记忆，不能简单视为同一个操作。

我这台电脑上，真正占空间的是什么

下面是 2026 年 8 月 9 日 01:23（UTC+8）对这台 Windows 电脑进行一次完整只读扫描得到的结果。正文表格、配图和后面的 PowerShell 输出都使用同一次扫描数据。它只能代表当时的使用快照，不能当作所有人的固定标准。

三个主要目录合计占用约 1.976 GiB：

继续拆开 .codex 后，较大的项目包括：

桌面界面的 web 目录占用 336.30 MiB，Cache 目录占用 31.91 MiB，两者合计 368.21 MiB。当前会话和已归档会话合计 385.20 MiB，与插件规模接近，但仍不是唯一的大项。

所以，“新建很多对话会吃满 C 盘”只说对了一半。对话确实会积累，尤其是带有大量工具输出的长任务；但插件、沙箱、日志、临时文件和界面缓存同样会增长。有时候删除十几个短对话，还不如清理一次失控的日志或临时缓存释放得多。

归档只是整理列表，不是释放空间

Codex 对任务的归档和删除是两种不同操作。

归档会把任务日志移入归档目录，方便把不常用任务从活动列表中收起来，之后仍可恢复。文件依然存在，因此磁盘占用通常不会明显下降。

删除才是永久移除持久化任务记录的操作。为了避免会话索引和 SQLite 状态不一致，更稳妥的做法是在 Codex 界面中删除任务，而不是在应用运行时直接删除某个 JSONL 文件。

如果确实要手工整理目录，应先退出 Codex 并做好备份。auth.json、配置文件和 SQLite 数据库尤其不适合凭文件名猜用途后批量删除。

什么情况下应该新建对话

我现在更倾向于“一项明确成果对应一个对话”。

同一个项目、同一个问题、同一份文档仍在连续迭代时，保留原对话很有价值。Codex 能沿用之前的决定、报错和修改记录，不需要每次重新解释。

出现下面这些情况时，新建对话通常更清爽：

• 已经换了项目、代码仓库或主题；
• 当前成果已经交付，准备开始一项独立任务；
• 对话里积累了大量过期方案和错误假设；
• 日志、网页内容和图片很多，任务明显变慢；
• 希望获得一次不受旧思路影响的独立审查。

切换之前，可以让 Codex 生成一份交接摘要，写清目标、已完成内容、关键决定、修改文件、遗留问题和下一步。新对话带着这份摘要开始，比把一个会话无限续下去更稳。

需要长期执行的项目约束，适合写入 AGENTS.md；需要保留的设计决定，适合进入项目文档。聊天记录更适合承载任务过程，不应该成为唯一的知识库。

图片和粘贴内容去了哪里

把截图粘贴进 Codex 时，Windows 临时目录里可能出现类似下面的文件：

codex-clipboard-一串唯一标识.png

这是应用为了读取剪贴板图片创建的临时副本，不等同于 .codex\sessions 里的会话文件。图片还可能在任务记录、附件目录或界面缓存中留下引用，因此“临时图片文件消失了”不代表相关会话记录也已经删除。

只要文字或图片需要由模型处理，相应内容就需要发送给当前配置的模型服务。若任务还调用了第三方插件、连接器或 MCP 服务，发送给第三方的数据受对方的数据处理规则约束。本机删除、账户侧删除和第三方数据清理属于不同层面，不能只根据 C 盘目录判断全部数据是否已经清除。

C 盘紧张时，按这个顺序处理

先在 Codex 中删除确认不再需要的任务。只想整理列表可以归档，但不要期待归档释放空间。

再检查 .codex、%APPDATA%\Codex 和 %LOCALAPPDATA%\Codex 各自的占用，判断增长来自会话、插件、日志还是缓存。不要只盯着 sessions。

下面这段 PowerShell 只读取 .codex 下各一级目录的文件大小，不会修改或删除内容：

$codexRoot = "$env:USERPROFILE\.codex"

Get-ChildItem -LiteralPath $codexRoot -Force -Directory |
ForEach-Object {
    [double]$bytes = (
        Get-ChildItem -LiteralPath $_.FullName -File -Recurse `
            -ErrorAction SilentlyContinue |
        Measure-Object -Property Length -Sum
    ).Sum

    [pscustomobject]@{
        Name   = $_.Name
        SizeMB = [math]::Round($bytes / 1MB, 2)
    }
} |
Sort-Object SizeMB -Descending

在这台电脑上执行后的结果如下：

这次命令与前面的完整扫描在同一时间执行。排在前面的分别是插件、当前会话、沙箱运行文件和临时文件，其中 sessions 为 368.90 MiB。由于 Codex 正在运行，当前会话、日志和缓存还会继续增长，因此读者复现时得到不同数字是正常现象。

结果最大的目录才值得继续检查。不要因为某个目录名字里带有 cache、tmp 或 logs，就在 Codex 运行时直接整目录删除。

对于特别长的任务，先保存交接摘要和关键项目文档，再新建对话。这样既能减少上下文负担，也能避免某个会话持续积累大量工具流水。

如果系统盘长期空间不足，可以考虑迁移 Codex 的主要后端状态。官方文档说明，CODEX_HOME 供 CLI、IDE 扩展、app-server 和安装程序使用，默认值是 ~/.codex，其中可以包含配置、认证、日志、会话和技能等数据；设置新位置前，目标目录必须已经存在。CODEX_SQLITE_HOME 则供 CLI 和 app-server 单独指定 SQLite 状态位置。

迁移时不要在应用运行过程中直接剪切目录。更稳妥的顺序是退出 Codex、复制完整目录、设置环境变量、重新启动并验证历史和配置正常，最后再决定是否删除旧副本。CODEX_HOME 并不等于桌面界面的全部数据目录，AppData 中的 Web 资源、界面缓存和应用日志仍可能留在 C 盘。

把三个问题分开，事情就简单了

遇到 Codex 会话越来越多时，可以先问自己三个问题：

• 模型是不是因为上下文过长而开始丢细节？这要靠摘要、项目文档或新对话解决。
• 本机是不是因为会话、日志和缓存而占用增加？这要靠检查目录、删除旧任务和清理缓存解决。
• 数据是否还保存在账户或第三方服务中？这要看对应的数据控制和保留规则，不能只看本地文件。

rollout-*.jsonl 只是 Codex 保持任务连续性的基础。真正需要调整的，是把一个对话无限续下去、把归档误认为删除，以及在没有确认用途时直接清理整个 .codex 目录。

到此这篇关于Codex会话会占满C盘吗?Codex本地会话数据清理指南的文章就介绍到这了,更多相关Codex会话数据清理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章，希望大家以后多多支持脚本之家！

最新评论