Codex 配置避坑指南：为什么你的 1M 上下文只有 258K？

最近很多玩 AI 自动化的朋友都在折腾 Codex，尤其是用它来跑那些需要长上下文的任务。但不少人踩了两个大坑：一个是明明模型号称支持 1M 上下文，实际用起来却卡在 258K；另一个是浏览器插件接管功能时灵时不灵，甚至出现账号之间的诡异差异。

今天就来拆解一下这两个核心问题，帮你少走弯路。

一、 1M 上下文？别被宣传语骗了

很多用户发现，自己在 Codex 中配置了支持 1M 上下文的模型（比如传闻中的 GPT 5.5 或类似的超长窗口模型），但在实际对话中，一旦历史消息稍微多一点，系统就会抛出经典的报错：

"Codex ran out of room in the model’s context window. Start a new thread or clear earlier history before retrying."

更让人困惑的是，即便你在配置里强行修改了参数，Codex 界面显示的可用上下文上限也常常停留在 258K 左右，而不是预期的 1M 或 950K。

这到底是 Bug 还是 Feature？

经过多方测试和社区大佬的验证，这其实是一套严格的“额度扣除”逻辑。目前的理解是这样的：

1. 总容量 vs 可用容量：虽然模型基础能力支持 1M tokens，但平台方（Provider）在接入层做了限制。目前实际对外暴露的可用上下文往往被限制在 400K 左右。
2. 输出预留：为了生成回答，模型需要预留一部分 tokens 用于输出。通常这部分预留约为 128K。
3. 系统预留：平台自身可能还会预留少量缓冲（如 5%）。

计算公式大致如下：

实际可用输入窗口 = (400K 平台上限 - 128K 输出预留) × 95% ≈ 258K

这就是为什么你明明配置了更大的值，却依然在 258K 附近触顶的原因。这并非你配置错误，而是上游接口的硬限制。对于需要处理超长文档或复杂代码库的任务，目前的建议是：主动精简历史消息，或者在关键节点开启新对话，不要指望一次性塞入超千万字的文档。

二、 浏览器插件接管：Plus 用户 vs 普通用户

第二个让人头疼的问题是 MCP（Model Context Protocol）浏览器插件的兼容性。

很多用户使用代理工具（如 Any）配合 CCswitch 等插件来实现浏览器自动化。但近期不少用户反馈，Codex 更新后，浏览器接管功能频频失效，报错信息通常指向：

"当前这轮没有暴露它必需的 mcp__node_repl__js 调用面。"

更有意思的现象是账号差异性。

• Plus 账号：往往能稳定调用浏览器插件，功能正常。
• 普通/代理账号：可能突然失效，或者间歇性报错。

为什么会有这种差异？

这可能是 Codex 后端针对不同订阅等级实施了不同的权限策略或版本灰度测试。

1. 权限隔离：Plus 账号可能拥有更完整的 MCP 节点访问权限，而普通账号在某些更新中被限制了特定模块的调用。
2. 版本不同步：代理插件或客户端可能与服务端最新版本存在短暂的兼容性问题，而 Plus 用户可能率先获得了适配更新。

排查建议：

• 确认账号状态：如果你使用的是非 Plus 账号，尝试升级到 Plus 看看问题是否消失，以此判断是否为权限限制。
• 检查插件版本：确保你的浏览器插件和 CCswitch 等中间件是最新版本。Codex 的更新频率较高，旧版插件可能找不到新的 MCP 调用入口。
• 清除缓存与重启：有时“虚假”的连接状态会导致调用失败，尝试完全退出并重新登录 Codex 和代理插件。

三、 总结与建议

1. 接受 258K 的现实：在当前阶段，不要试图在单轮对话中突破 258K 的输入限制，合理规划对话结构，善用“新对话”和“总结历史”功能。
2. 关注账号权益：浏览器自动化等高级功能可能依赖于 Plus 订阅，普通用户若遇到持续性的 MCP 报错，升级账号是一个有效的排查步骤。
3. 保持更新：工具链更新极快，遇到兼容性问题，第一时间检查插件和客户端版本。

AI 工具的使用是一场与平台策略的博弈，理解这些“隐性限制”，能让你在使用 Codex 时更加从容，避免在配置上浪费过多时间。