MCP 数据流不再“裸奔”
接入的 MCP 服务器越多，AI 的“视野”就越依赖服务器返回值。数据库查询、网页抓取、内部 API，返回什么模型就看什么——这个环节长期缺少校验。8月29日发布的 Codex 0.151.0 改变了这一现状：扩展第一次有机会在工具结果进入模型之前完成检查和改写。
这次更新没有大张旗鼓的新功能，三个改动都针对实际痛点：MCP 扩展中间件、MCP 服务器独立宽限期、嵌套子代理 token 纳入根预算。分开看都是小修小补，合在一起却让多代理工作流可控不少。
关键更新：给工具结果加一道“安检门”
此前扩展只能等模型拿到结果后再做补救。0.151.0 添加的 on_mcp_tool_result 钩子把拦截点提前：外部 MCP 服务器的返回内容，要先经过扩展处理，才能送进模型。这个机制和已有 PostToolUse 体系位置相似，但走的是专用 MCP 通道。
这一改动可以直接用于四类场景。
首先是脱敏。数据库查询返回的手机号、邮箱等敏感字段，在交给模型前先打码；其次是压缩，超大 JSON 响应可被提炼成摘要，减少上下文窗口占用；第三是审计，为结果附加延迟、服务器标识等元数据；第四是测试，CI 环境下用固定数据替换真实响应，保证可重复。
配置不算复杂。在 ~/.codex/extensions/result-sanitiser/manifest.toml 中声明扩展名称与钩子命令即可。处理器从标准输入读取原始 JSON，从标准输出返回修改结果；如果退出码非零，该结果会被拒绝并向 agent 报错。不需要改动 config.toml。
这个中间件设计最值得注意的地方是“可替换”而非“只读”。它意味着扩展不仅能做过滤，还能主动改写数据。对有敏感信息治理需求、或想控制上下文规模的团队，是一个相当实用的抓手。
细节完善：慢服务器不拖后腿，预算不再“局部失控”
MCP 服务器一多，启动慢就成问题。工具发现阶段会阻塞第一轮对话，直到超时。旧版本只能依赖全局超时参数，无法按服务器区分。0.151.0 允许在 [[mcp_servers]] 中单独设置 grace_period_ms：例如给启动缓慢的内部服务器配置 2000 毫秒，到期无响应就跳过，而不是干等默认的 30 秒。快服务可以设到数百毫秒，慢的则多留一些余量。
预算方面也有修复。多代理任务里，子代理以前的 token 消耗只记在自己的账上，根级 /goal 预算无法察觉。0.151.0 之后，budget_tokens 会把所有嵌套子代理的花费合并计算。举个例子：根代理消耗 11.2 万 token，两个子代理各花 4.5 万和 6.7 万，如今总账是 15.3 万，超限会触发暂停或终止。对长时间自主跑批、按量计费的用户来说，这个变化直接决定成本控制是否有效。
别高兴太早：边界仍然清晰，升级后要做的事
值得注意的是，中间件只能拦截 MCP 工具结果，无法约束 MCP 服务器启动阶段的行为。服务器自己跑的代码不在扩展视野内。脱敏脚本一旦写得不好，可能把正常错误也打码，反而掩盖真实问题。此外，/goal 只管 token，管不了 API 调用次数和外部服务费用。信任边界依然在 MCP 服务器本身。
升级本身简单：npm install -g @openai/codex@latest，然后 codex --version 确认版本。Codex Cloud 和应用服务端会自动更新。
升级后最值得做的是四件事：先给连数据库的 MCP 服务器写一个脱敏钩子；给启动慢的服务器配上 grace_period_ms；用 /goal 跑长时间任务时观察对账是否准确；最后用日常最重的会话完整跑一遍，确认工具调用和计数没异常。逐步验证之后再铺开，比一次全量切换更稳妥。