Codex 开放 1M 上下文后，我折腾了一圈才发现：新版根本不是网上教的那样配置

最近看到不少人在讨论 Codex 的 1M 上下文，我第一反应也是：这个得开。

对于平时只是让 AI 写个函数、改个 SQL 的人来说，几十万上下文可能已经够用了。但如果真拿 Codex 做项目级开发，尤其是 Java / Spring Boot 这种动不动几十个模块、几百个类的项目，上下文大小还是挺重要的。

以前经常碰到一种情况：刚让 Codex 把项目架构摸清楚，继续改几个文件之后，前面分析过的东西就开始被压缩。再继续聊，它甚至会重新搜索之前已经看过的代码。

所以看到 1M 上下文之后，我就准备直接给 Codex 配上。

结果没想到，第一步就踩坑了。

一、网上搜到的 1M 配置，直接把 Codex 搞启动不了了

我最开始找到的配置方式很简单，说是在 Codex 的 config.toml 里面增加：

toml 复制代码

model_context_window = 1000000
model_auto_compact_token_limit = 900000

一个控制上下文窗口，一个控制什么时候开始自动压缩。

看起来挺合理。

我当时的想法也很简单：既然最大支持 100 万 Token，那就把上下文设置成 1000000，然后到 90 万左右再让 Codex 自动 compact，理论上还能留一点空间给模型输出。

于是直接打开配置：

bash 复制代码

vim ~/.codex/config.toml

加完配置，保存，重新执行：

bash 复制代码

codex

然后 Codex 没起来，直接给了我一个错误：

text 复制代码

Error loading config.toml: invalid type: integer `1000000`, expected a boolean
in `features`

看到这个错误的时候，我第一反应还以为是 Codex 新版本不支持 1000000 这个值。

后来仔细看才发现，真正关键的是最后这一句：

text 复制代码

expected a boolean
in `features`

也就是说，Codex 把我配置的 1000000 当成了 [features] 下面的一个配置项，而 features 里面要求的值应该是：

toml 复制代码

true

或者：

toml 复制代码

false

结果我塞进去一个整数 1000000，配置解析当然直接失败。

这也是 TOML 配置文件特别容易踩的一个坑。

二、为什么明明写了两行配置，Codex 却认为它们属于 features？

问题其实出在 TOML 的结构上。

假设原来的配置类似：

toml 复制代码

model = "gpt-5.6-sol"

[features]
some_feature = true

如果你直接在 [features] 后面继续加：

toml 复制代码

model_context_window = 1000000
model_auto_compact_token_limit = 900000

最终实际上相当于：

toml 复制代码

model = "gpt-5.6-sol"

[features]
some_feature = true
model_context_window = 1000000
model_auto_compact_token_limit = 900000

Codex 解析的时候自然会认为：

model_context_window 是一个 feature。

而 feature 应该是布尔值。

于是：

toml 复制代码

model_context_window = 1000000

就会出现：

text 复制代码

expected a boolean

这个问题跟数字是不是 1000000 其实没有直接关系。

你改成：

toml 复制代码

model_context_window = 500000

一样报错。

因为错的是配置层级，而不是数字大小。

如果某个版本确实支持这些根级配置项，那么至少应该放到 [features] 之前，例如：

toml 复制代码

model = "xxx"

model_context_window = 1000000
model_auto_compact_token_limit = 900000

[features]
some_feature = true

不过折腾到这里，我又发现了第二个问题：对于新版 Codex 来说，不能简单照着网上的旧教程硬改配置。

三、先别急着配置，第一件事应该是看 Codex 版本

我重新进入 Codex，然后执行：

text 复制代码

/status

得到的信息是：

text 复制代码

OpenAI Codex (v0.145.0)

Model:              gpt-5.6-sol
                    (reasoning low, summaries auto)

Directory:          ~/.config/clash

Permissions:        Workspace (Ask for approval)

Collaboration mode: Default

这一步其实非常重要。

因为现在网上搜"Codex 1M 上下文配置"，能搜到很多不同时间的文章、帖子和配置示例。

问题在于 Codex CLI 更新非常快。

你看到别人几个月前能用的：

toml 复制代码

xxx = true

或者：

toml 复制代码

model_context_window = 1000000

不代表你现在安装的版本还需要这么配置。

所以以后碰到 Codex 配置问题，我建议第一步永远不要先复制网上的 config.toml。

先执行：

bash 复制代码

codex --version

再进入 Codex 看：

text 复制代码

/status

先搞清楚三个东西：

Codex CLI 是什么版本、当前使用什么模型、当前账号是什么套餐。

版本对不上，后面的教程参考价值至少先打个折。

四、1M 上下文真正需要搞清楚的是"模型能力"

这里也是我一开始理解有偏差的地方。

所谓 Codex 支持 1M 上下文，很容易让人理解成：

Codex 有一个隐藏开关，打开以后上下文从几十万变成 100 万。

实际上不能这么简单理解。

上下文窗口首先是模型能力。

也就是说，真正决定你能不能获得超长上下文的核心因素，是当前 Codex 给你使用的模型以及产品侧是否为这个模型开放了相应能力。

比如我当前 /status 显示的是：

text 复制代码

Model: gpt-5.6-sol

那么首先应该确认的不是：

"我怎么强行把它改成 1000000？"

而应该是：

"当前这个模型在 Codex 中到底支持多大的上下文，以及 Codex 当前版本如何管理它？"

这两个问题完全不是一回事。

新版 Codex 越来越倾向于根据模型能力和产品策略自动管理上下文，包括什么时候进行 summary、什么时候 compact、保留哪些文件内容，而不是让用户随便在配置文件里写一个数字，就真的把模型能力改掉。

换句话说：

toml 复制代码

model_context_window = 1000000

即使某个版本允许这么写，也不代表你能把一个原本只支持较小窗口的模型"魔改"成 1M。

配置文件不是显卡超频。

模型本身支持多少，才是基础。

五、怎么判断自己到底在用什么模型？

最简单的方法就是进入 Codex：

bash 复制代码

codex

然后执行：

text 复制代码

/status

像我这里显示：

text 复制代码

Model: gpt-5.6-sol (reasoning low, summaries auto)

这里其实还透露了另外两个信息。

一个是：

text 复制代码

reasoning low

说明当前推理强度偏低。

另一个是：

text 复制代码

summaries auto

说明 Codex 本身就在自动管理对话和上下文摘要。

这也是为什么我现在越来越不建议为了追求那个"1M"的数字，随便修改一些来源不明的参数。

对于 Agent 类编程工具来说，"模型最大支持 1M Token"和"每次任务真的把 1M Token 全部原封不动塞进去"，完全是两个概念。

Codex 会搜索代码、读取文件、执行命令、重新读取修改后的文件，还会维护任务状态。

真正重要的是它能不能在一个长任务里面持续保持对项目的理解，而不是状态栏有没有显示一个漂亮的：

text 复制代码

1,000,000 tokens

六、还有一个现实问题：1M 上下文不是免费的午餐

我这次 /status 里面还有一条信息特别醒目：

text 复制代码

Weekly limit: 17% left

也就是说，我这周 Codex 的额度已经只剩 17% 了。

而且启动的时候 Codex 已经主动提醒：

text 复制代码

Heads up, you have less than 25% of your weekly limit left.

这时候再去无脑追求超长上下文，其实就得考虑一个非常现实的问题：额度消耗。

假设你只是让 Codex：

帮我修改一下这个 Controller 的参数校验。

它可能只需要看 Controller、Service、DTO 和少量关联代码。

这种任务根本没必要把几十万甚至上百万 Token 的项目上下文全部维持在当前任务里。

真正适合长上下文的，是另外一类任务，比如：

分析整个 Spring Boot 项目的权限体系，然后把 RBAC 改造成支持数据权限；

或者：

梳理整个支付项目，从 Controller 到 MQ、Redis、数据库，把支付成功但是订单状态没更新的问题找出来；

再比如：

分析一个几十万行的老项目，给出模块拆分方案，并且分阶段完成重构。

这种任务需要跨几十甚至上百个文件保持关联关系，长上下文的价值才真正体现出来。

所以我现在对 1M 的态度已经从：

"必须打开。"

变成：

"有需要的时候再用。"

七、如果你也遇到 `expected a boolean`，怎么恢复？

如果现在 Codex 已经因为修改 config.toml 启动不了了，可以先执行：

bash 复制代码

cat ~/.codex/config.toml

重点找：

toml 复制代码

[features]

看看是不是把类似下面的配置写到了它后面：

toml 复制代码

model_context_window = 1000000
model_auto_compact_token_limit = 900000

如果是，先把这两行删除或者注释掉：

toml 复制代码

# model_context_window = 1000000
# model_auto_compact_token_limit = 900000

保存之后重新执行：

bash 复制代码

codex

如果能够正常进入，再执行：

text 复制代码

/status

确认 Codex 版本和当前模型。

也可以在终端执行：

bash 复制代码

codex --help

看看当前版本到底暴露了哪些参数。

这一点比直接复制网上的配置靠谱得多。

八、还有一个很容易忽略的地方：配置文件到底在哪？

大多数情况下，Codex CLI 使用的是：

text 复制代码

~/.codex/config.toml

所以可以直接：

bash 复制代码

cat ~/.codex/config.toml

或者：

bash 复制代码

vim ~/.codex/config.toml

不过也别看到终端当前目录是：

text 复制代码

~/.config/clash

就以为配置文件在：

text 复制代码

~/.config/clash/config.toml

这是两码事。

/status 中的：

text 复制代码

Directory: ~/.config/clash

表示的是 Codex 当前工作的项目目录。

比如你在：

bash 复制代码

cd ~/.config/clash

之后执行：

bash 复制代码

codex

那么 Codex 就会把 Clash 配置目录当成当前 Workspace。

它和 Codex 自己的全局配置文件不是一个概念。

九、为什么 1M 上下文对 Java 项目确实有吸引力？

虽然前面说了这么多坑，但我依然觉得长上下文对于程序员很有价值，尤其是 Java 后端。

一个稍微成熟一点的 Spring Boot 项目，很容易就有：

text 复制代码

Controller
Service
ServiceImpl
Mapper
Entity
DTO
VO
MQ Consumer
Redis
XXL-JOB
Feign
Config
Util
SQL
Nacos 配置

一个业务链路可能横跨十几个文件。

传统 AI 编程最烦的一件事就是：

你刚把 A 解释清楚，它忘了 B；

刚把 B 加进来，前面的数据库结构又被压掉了。

最后人反而成了 AI 的"上下文搬运工"：

"还记得刚才那个 UserService 吗？"
"结合我之前发你的表结构。"
"不是这个方法，是前面那个支付回调。"

这种开发体验其实很累。

长上下文真正解决的不是"让 AI 一次看 100 万字"，而是让 Agent 在一个持续一两个小时甚至更久的开发任务里，有更大的空间维护：

项目结构 + 已读取代码 + 用户需求 + 修改记录 + 测试结果 + 错误日志 + 后续计划。

这才是 1M 对 Codex 真正有意义的地方。

十、折腾完之后，我反而不急着手动开 1M 了

这次最大的收获不是终于找到某个神秘参数，而是把 Codex 的上下文机制想明白了。

如果你用的是新版 Codex，尤其是版本已经到了：

text 复制代码

Codex v0.145.0

这种比较新的版本，我建议不要看到网上有人贴：

toml 复制代码

model_context_window = 1000000

就直接复制。

正确顺序应该是：

先看：

bash 复制代码

codex --version

再看：

text 复制代码

/status

确认当前模型，然后根据当前 Codex 版本和模型实际支持能力决定是否还需要手动配置。

如果启动直接出现：

text 复制代码

invalid type: integer `1000000`, expected a boolean
in `features`

先别怀疑 Codex 坏了。

十有八九只是 TOML 配置层级放错了。

最后再说一个我现在使用 Codex 越来越明显的感受：

上下文当然越大越舒服，但上下文大小并不是 Agent 编程体验的全部。

以前我们用 ChatGPT 写代码，核心问题是：

"一次能喂进去多少代码？"

现在用 Codex 这种 Agent，问题正在慢慢变成：

"它能不能自己找到真正需要看的代码，并且在整个任务过程中不丢掉关键上下文？"

一个模型哪怕支持 1M，如果每次都把大量无关代码读进去，照样又慢又费额度。

反过来，如果 Codex 能准确找到 Controller → Service → Mapper → SQL → 配置文件这一整条调用链，可能几十万上下文就已经够用了。

所以 1M 值得期待，但真没必要为了状态栏里的"1000000"去强开。

尤其像我这次，1M 还没体验上，先成功把 Codex 配置文件干崩了一次。

也算是替大家把这个坑踩了。

如果你最近也在折腾 Codex，遇到 config.toml 报错，第一件事不是继续复制新的配置，而是先看看自己的 Codex 版本。

AI 编程工具更新太快了，很多时候教程没错，只是它已经过期了。

Codex 开放 1M 上下文后，我折腾了一圈才发现：新版根本不是网上教的那样配置