Codex 会话会占满 C 盘吗？我实测了本地记录、缓存和日志

Codex 会话会占满 C 盘吗？我实测了本地记录、缓存和日志

前几天我打开 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\sessions	保存任务流水和对话历史
已归档会话	.codex\archived_sessions	保存从活动列表归档的任务
状态数据库	.codex\state_*.sqlite、.codex\sqlite	保存索引、状态和分页历史
记忆	.codex\memories*	保存可能跨会话复用的本地上下文
日志与缓存	.codex\logs_*.sqlite、.codex\cache	运行诊断与缓存数据
插件和技能	.codex\plugins、.codex\skills	已安装能力与运行依赖
桌面界面缓存	%LOCALAPPDATA%、%APPDATA% 下的 Codex 目录	网页资源、界面缓存和应用日志

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

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

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

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

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

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

目录	当时占用
%USERPROFILE%\.codex	1,621.86 MiB（1.584 GiB）
%APPDATA%\Codex	371.69 MiB
%LOCALAPPDATA%\Codex	30.32 MiB

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

内容	当时占用
插件	376.50 MiB
当前会话，共 91 个文件	368.90 MiB
沙箱运行文件	304.68 MiB
临时文件	248.34 MiB
.codex 根目录文件，共 27 个	231.64 MiB
SQLite 状态目录	47.83 MiB
已归档会话，共 10 个文件	16.30 MiB

桌面界面的 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 目录。

参考资料

• OpenAI Codex 环境变量：https://learn.chatgpt.com/docs/config-file/environment-variables#core-locations
• OpenAI Codex App Server：https://learn.chatgpt.com/docs/app-server#api-overview