Codex CLI 0.152.0 更新详解：MCP 输出限制到底改变了什么

Codex CLI 0.152.0 于 2026 年 9 月 1 日发布，共带来 6 项新功能。但这次更新真正解决的，是长时间运行、频繁调用工具的任务中如何划定边界。最重要的变化是：现在可以分别限制每个 MCP 工具送入模型的输出量，不必再让所有工具共用同一套兜底策略。

先看结论

这是一次聚焦控制力和可靠性的更新，不涉及新模型，也没有价格调整。如果只是把 Codex 当作终端编程智能体使用，最直观的改进是：限流提示更有用、凭据恢复状态更清楚，以及可以在长草稿中使用 Vim 搜索。

如果通过 MCP 将 Codex 连接到外部系统，或基于 Codex app server 开发，这次更新的分量就更重。MCP 是 Model Context Protocol（模型上下文协议）的缩写，它充当连接层，让 Codex 能调用文档检索、Figma、GitHub 或内部服务等工具。0.152.0 允许为每个工具单独设置输出预算。

下面把这次发布的 6 项新功能，按真正会受影响的人群梳理出来：

真正值得吃透的是第一项。它改变了 Codex 工作期间会继续携带多少工具返回内容。

Codex CLI 的 MCP 输出限制到底做了什么

一个 MCP 工具可能一次返回大量内容。文档查询可能带回几篇长文，日志搜索也可能吐出很多行。Codex 必须把这些结果放入工作上下文，也就是模型处理当前任务时使用的短期记忆。

如果没有按工具设置，MCP 输出仍会回退到当前模型的常规截断策略。到了 0.152.0，可以在特定 MCP 服务器的特定工具下加入新的 output_token_limit 配置项。随后，Codex 会按照配置的 token 预算裁剪该工具提供给模型的结果。

关键在于面向模型（model-facing）。MCP 服务器并不会因此少做工作，Code Mode 仍然可以拿到原始结果。限制发生在结果进入模型上下文和对话历史时。恢复会话以及处理工具调用后的 hook 响应时，Codex 也会沿用同一个有效预算，因此重新打开会话不会悄悄恢复更大的载荷。

为什么这项限制很重要

过去要问的是：“这个模型能承受多少工具输出？”现在可以换成：“这个具体工具完成任务究竟需要多少？”库查询和生产日志转储终于不必采用同一个答案。

这里有两道护栏。配置值必须为正，因此 0 和负数都会被拒绝。如果插件策略和自己的配置同时设定了限制，取较小值。工具审批是另一回事：缩小输出预算既不会批准工具，也不会改变 Codex 在调用前何时征求许可。

谁适合使用，应该怎么配置

被文档工具“刷屏”的独立开发者

独立 SaaS 开发者可以防止宽泛的文档搜索挤占后续编程轮次。给会返回长页面的工具设定明确预算，精准查询工具则保持不变，便能把更多工作上下文留给代码库、计划和 diff。

这是 0.152.0 最干净利落的使用场景，因为边界直接设在噪声源头。没必要因为一个工具返回太多，就把所有工具的预算一起压低。

运行 app server 长任务的平台工程师

新的 timeoutMs 字段 属于 app server 的 thread/shellCommand 方法，并不是 MCP 的 tool_timeout_sec 配置。

这个区别很重要。MCP 工具目前的默认运行超时是 60 秒；如果省略 timeoutMs 或将其设为 null，app server shell 命令仍保持默认的一小时。现在，如果 app server 客户端知道构建、迁移或测试套件需要更久，就可以请求更长的截止时间。把 timeoutMs 设为 0 会立即超时，无效的负值也会被拒绝。

这个辅助命令超时，并不会停止智能体的当前轮次。客户端需要自行决定：让该轮次继续工作、发送新指令，还是另行中断。

用 Vim 写长任务说明的开发者

Vim 模式现在可以直接搜索草稿。/ 向前搜索，? 向后搜索，n 或 N 循环跳转匹配项。搜索还能与删除、修改和复制操作组合使用，同时不会把查询内容混入提示词文本。

如果只写几行，这项改动看起来很小；但当终端里的任务说明长达多个段落时，就不必为了查找并修改一个重复名称，先把全文复制到编辑器了。

使用 Bedrock 的企业团队

过去，提供商凭据过期时，看起来很像任务卡死。现在，Codex 会为提供商认证恢复发出稳定的开始与完成通知，并在交互式 TUI 和 codex exec 中显示进度。

对于通过 Amazon Bedrock 路由模型的工程团队，直接收益是运维状态更清晰。CI 日志无需再从漫长的停顿中猜测，就能区分“智能体正在工作”和“提供商会话正在重新认证”。

需要保留真实包名的插件作者

MCP 服务器名称现在可以使用 :、@、/ 和 .。像 npm:@modelcontextprotocol/server-sequential.thinking 这样的名称，可以原样通过 mcp add、get、list 和 remove，并在运行时工具命名空间与 OAuth 凭据中保持同一个身份。

这消除了一个恼人的别名来源。包坐标、配置名称和凭据身份可以始终保持一致。

经常触及用量上限的团队

现在，终端可以把限流通知变成下一步行动。受支持的横幅能够引导查看用量、额度余额、重置时间、通知所有者或管理套餐。恢复期间，Codex 会刷新用量、拒绝过期响应，并暂停排队的输入，直到状态更新完成。后端横幅还可以引导 Codex 切换到第一个可用的备用模型，而不必改写无关的会话设置。

这不会提高用量额度，但会让边界清晰可见，并把用户带到真正有用的处理入口。

一套完整的 Codex MCP 配置：接入真实服务器

理解新配置结构最快的方法，是把它用在真实服务上。这里选择 Context7：这是 Codex 设置指南中使用的文档型 MCP 服务器。它的 query-docs 工具会根据已知库 ID 获取文档，很适合明确设置输出预算。

1. 1

   安装这个版本

   锁定版本，确保新的配置键可用：

   npm install -g @openai/codex@0.152.0

2. 2

   添加 Context7

   使用当前 Codex MCP 指南中的原始命令：

   codex mcp add context7 -- npx -y @upstash/context7-mcp

3. 3

   设置工具预算

   打开 ~/.codex/config.toml，在 Context7 服务器配置项下方添加这张表：

   [mcp_servers.context7.tools.query-docs]
   output_token_limit = 30000

   30,000 这个值来自 Codex 自身的序列化测试。它展示的是可接受的配置形式，而不是适用于所有场景的建议。先从仍能保留提示词所需证据的最小结果开始；实际输出确实被截断时，再逐步提高。

4. 4

   检查连接

   运行 codex mcp list，确认服务器已完成配置。在终端 UI 内，/mcp 会显示当前会话可用的活跃服务器。

需要直说的限制

按工具截断是一道护栏，并不等于免费的压缩。限制设得太低，Codex 可能会丢失解释问题的关键日志行或文档中的限定条件。由于插件策略与用户配置重叠时取较小值，插件策略也可能让实际预算低于自己文件里写下的数字。

配置的预算还位于标准的 20% 序列化余量之前，这部分余量用于容纳把结果放入模型请求所需的额外结构。应把它视为实用预算，而不是承诺序列化后的每份载荷恰好包含那么多 token。

0.152.0 的其他内容属于实用的维护改进。调用方没有提供工作目录时，恢复的会话会找回已保存的目录；自动审批复核在历史压缩后会保留更多指令和有效授权；即使发生缓存刷新和远程插件变化，MCP 工具也更不容易丢失。这些变化都不会改变模型的编程能力、套餐价格或用量额度。

现在该怎么做

如果日常会运行多个 MCP 工具、嵌入 app server、用 Vim 模式编写长提示词、通过 Bedrock 路由，或经常触及用量上限，建议本周升级。这些改进会直接优化工作流，而且迁移范围很小。

如果所在组织集中锁定 CLI 版本，可以先等等。公开配置页面尚未跟进按工具设置输出限制的配置键，应给策略包维护者留出时间，让他们验证新字段，并根据真实输出选择限制值。

如果只在网页或移动端使用 ChatGPT，这次发布不会改变现有工作流。如果仍在判断 Codex 是否适合自己的交付方式，可以先看更完整的 Codex、Claude Code 与 Cursor 对比。

想继续获得用直白语言拆解、真正影响开发流程的版本更新，欢迎订阅邮件通讯。