发布日期：2026-09-04 | 信息口径：openai/codex 仓库 Issue 与 Release 记录、Codex 官方配置文档、OpenAI 负责人 X 平台说明，截至 2026-09-04

Codex 上下文爆满，指的是 OpenAI 编程智能体 Codex 在长会话中把上下文窗口填满，触发自动压缩、遗忘约束、用量异常消耗的一组现象，2026 年 7 月至 9 月在 openai/codex 仓库集中爆发。根源不是模型窗口不够大，而是三件事叠在一起：订阅用户实际拿到的 GPT-5.6 Sol 窗口被服务端目录限制在 272K，折算有效窗口只有 258,400 个 Token，远小于 API 标称的 105 万；自动压缩会把旧图片一并保留，压完依然很大，负责人 Thibault Sottiaux 在 8 月 22 日承认这是用量消耗过快的原因之一并重置了全体额度；再加上工具输出和后台自动摘要持续占用窗口。本文按时间线梳理这三个月发生了什么，给出用 /status、config.toml 和 0.153.0 新增笔记式上下文管理止血的实操步骤。

先看现象：为什么 Codex 用着用着就"变蠢"

如果你最近在 Codex CLI 或桌面端里跑过持续两三个小时的任务，大概率遇到过这几件事。屏幕上突然出现一行"Context compacted"，接着模型忘了你半小时前定下的"只改 src 目录、其余只读"的约束；同一个测试失败它反复排查三遍，因为前两次的结论已经被压进摘要里丢了细节；用量面板上的五小时窗口比以前掉得快得多。国内技术媒体 8 月底集中出了一批"如何避免 Codex 越用越蠢"的文章，给出的原因高度一致：所有提问、代码、工具返回和调用记录全部累积，Token 越多，模型注意力被历史稀释，临近上限才压缩，压缩前已经明显降智。

这些描述都对，但停在了使用层面。真正让 7 月以来的抱怨集中爆发的，是 openai/codex 仓库里几条被顶到上百个赞的 Issue 揭开的两个事实。

第一个事实：你的窗口只有 258K，不是 1M

7 月 9 日，一位 Pro 用户在 Issue 中贴出 Codex 客户端从服务端拉到的模型目录原文。GPT-5.6 Sol 在这份目录里的字段是这样的：

{
  "context_window": 372000,
  "max_context_window": 372000,
  "effective_context_window_percent": 95,
  "auto_compact_token_limit": null
}

Codex 核心按 372,000 乘以 95% 计算，得到 353,400 个 Token 的有效窗口，桌面端显示的"约 353K"就是这么来的。自动压缩阈值则按原始窗口的 90% 推导，即 334,800。而 OpenAI 开发者文档给 GPT-5.6 Sol 标的是 105 万上下文、92.2 万输入、12.8 万输出。

四天之后情况变得更糟。7 月 13 日同一位用户更新：在 Codex CLI 0.144.1 上重新拉取目录，字段变成了 272,000，折算有效窗口 258,400。他用 codex debug models 命令和 App Server 的用量事件互相印证，确认这不是显示问题，本地也没有任何覆盖配置。这条 Issue 收获 62 个赞后被关闭，评论区的关键词是"自动压缩疯了一样地触发"和"没有任何通知"。关联的几条 Issue 至今仍开着：要求 Codex 支持 1M 上下文的那条有 168 个赞，要求恢复 372K 或提供可选开关的有 23 个赞，要求对自动压缩参数给出控制权的有 112 个赞。

这就是"上下文爆满"的第一层原因：订阅用户的窗口被目录限制在 API 标称值的四分之一左右，而 Codex 客户端会尊重服务端目录，本地把 model_context_window 写成 100 万也会被夹回去。第二层原因更隐蔽。

第二个事实：压缩本身在消耗上下文

8 月 22 日，Codex 与 ChatGPT 团队负责人 Thibault Sottiaux 在 X 平台发文回应用量消耗过快的投诉，列出三个已经查实的问题：一是长会话里使用图片并多次触发上下文压缩时存在效率问题；二是 Computer History 功能在 P95 以上分位的使用量异常；三是原本用来生成对话标题的功能用量超出预估。他宣布次日太平洋时间下午两点前后为所有 Codex 订阅用户重置额度，修复随后跟进。

第一条的机制值得展开。Codex 的压缩本意是把旧对话压成摘要腾出空间，但此前压缩时旧图片会继续留在上下文里。结果就是为了变小而压缩，压完还是很大，大到可能马上再触发一次压缩，压缩本身开始消耗上下文和额度。8 月 27 日发布的 0.150.1 版本把修复回移到了稳定分支：远程压缩默认把保留的图片计入 Token 预算，必要时裁掉更早的图片。9 月 1 日的 0.152.0 又补上了"Guardian 历史中丢弃超大图片时保留用户文本"和"单个 MCP 工具可以设置 output_token_limit"两项。

还有第三个不太被注意的来源。0.151.0 引入了自动对话摘要：至少三轮对话之后，终端失去焦点或空闲三分钟，Codex 会另起一个临时线程、用当前模型再跑一轮结构化总结。8 月 30 日有人开 Issue 要求关闭它，两天内被顶到 41 个赞，9 月 3 日的 0.153.0 加上了 tui.auto_recap 开关。

把这三层叠起来，一个典型的爆满过程是：窗口本来只有 258K，工具输出和截图把它填到 90% 附近，自动压缩触发但图片没清干净，几分钟后再压一次，中间还穿插着后台摘要线程，额度和注意力一起流失。

实操：三步把上下文管住

下面的步骤在 Codex CLI 0.153 上验证过，桌面端的配置文件和命令名相同。

第一步，先弄清楚你到底有多大窗口。 在会话里输入 /status，输出里的 model_context_window 就是当前生效的有效窗口，界面底部的"N% context left"按它计算。想看服务端目录的原始数值，用调试命令：

codex debug models

如果显示的 context_window 是 272000，说明你和 Issue 里的情况一样，不用再试着在本地改大，先接受这个数字来规划任务。

第二步，用 config.toml 控制压缩时机和工具输出体积。 配置文件在 ~/.codex/config.toml，下面这几个键在官方配置参考里都有记录：

# 提前压缩，避免在 90% 处被动触发；单位为 Token
model_auto_compact_token_limit = 200000
# 只统计压缩前缀之后新增的内容，减少连续压缩
model_auto_compact_token_limit_scope = "body_after_prefix"
# 单条工具输出存进历史的预算，日志类命令必设
tool_output_token_limit = 8000
# 关掉后台自动摘要，需要时手动 /recap
[tui]
auto_recap = false

改完重开会话，日志、测试输出和 grep 结果会按 8000 Token 截断后再进历史，这是控制爆满最立竿见影的一项。对输出特别大的 MCP 工具，还可以在 mcp_servers..tools. 下单独设 output_token_limit。

第三步，主动压缩，或者换掉压缩。 在任务的自然断点手动执行 /compact，并在命令后面写清楚要保留什么，例如"总结本次需求、已改文件、剩余任务，丢弃调试失败记录"，效果比等自动压缩好得多。如果一段工作彻底结束，用 /new 开新会话，把 300 字以内的交接摘要粘过去。使用 ChatGPT Plus、Pro 或 Pro Lite 登录的用户，可以试 0.153.0 新增的实验开关：

[features.context_management]
experimental_mode = true

打开后 Codex 不再反复把历史压成一份摘要，而是让模型在不同上下文窗口之间写笔记，旧的完整历史保持可搜索，并新增 new_context 工具。发布说明明确写了 API Key 会话、自定义供应商和临时结构化线程暂不支持。这个机制就是 GPT-6 Astra 发布时官方提到的"跨窗口笔记"，目前的说法是数周内转为默认。

国内团队在做这类长任务时，有一个常见的补充做法：把一次性、结果可丢的探索性任务交给成本低的模型跑完，只把结论带回主会话。七牛云 AI 大模型广场提供 OpenAI 兼容接口，把 base_url 换成 https://api.qnaigc.com/v1、model 填 deepseek/deepseek-v4-pro-0813 或 z-ai/glm-5.3，就能在同一套脚本里做这种分流；多款主流大模型混用、月用量稳定的团队，可以顺手看一下 Token Plan 的企业订阅，把这部分分流成本按点数算一次。

下一步：Astra 时代的上下文策略

从 9 月 3 日 GPT-6 Astra 发布材料看，OpenAI 对 Codex 上下文问题的回答不是"把窗口开到 1M"，而是"换一种记法"。Astra 本身在最高档设置下输出 Token 比 Claude Opus 5 少约 65%，官方的说法是更少的书面步骤、更多的内部思考；Codex 侧则把长任务的记忆方式从有损压缩改成笔记加可搜索历史。两件事指向同一个判断：窗口再大也会满，关键是满了以后丢什么、留什么。

对用户来说，短期内三条 Issue 的诉求仍然没有完全落地：1M 窗口没有开放，压缩没有硬关闭开关，桌面端的上下文用量指示器在 5 月消失后靠 /status 顶着。但 0.150 到 0.153 这四个版本已经把最伤人的几处堵上了，剩下的部分靠配置和习惯可以管住大半。

以上信息取自 openai/codex 仓库 2026 年 7 月至 9 月的 Issue 与 Release 记录、Codex 官方配置参考，以及 Thibault Sottiaux 8 月 22 日在 X 平台的说明，Codex 版本迭代很快，具体字段以你安装版本的 /status 与配置文档为准。

延伸阅读