Claude Code 2.1.233：三项 Gateway 变更，每个 Operator 都要知道

最有运营价值的版本，往往没有大标题。Claude Code 2.1.233 本周发布，就是这样一个版本。三处改动触及 gateway 层，对任何通过代理或云后端规模化运行 Claude Code 的团队都有直接影响。

2.1.233 改了什么

forward_user_identity 开发者身份现在能到达你的代理了

Anthropic upstream 上的 apps gateway 新增了一个可选设置 forward_user_identity。启用后，gateway 会在每条出站请求里打上当前登录开发者的身份请求头，包括从 gateway 签发的 JWT 中读取的 user.id、user.email 和 user.groups。

这个设置出现之前，坐在 apps gateway 后面的代理服务器收到的是同一套不透明的上游凭证，不管请求来自哪个开发者。想做按开发者的费用归因，只能在代理里自己截取并解析 JWT，再跟用量日志做关联，而且这套做法在 Vertex AI、Foundry 和 Claude Platform on AWS 三条链路上都得单独处理，脆而易断。

有了 forward_user_identity，gateway 来完成身份传递。代理服务器在每次请求里拿到结构化的身份请求头，可以直接写进账单记录、费用看板，或按用户执行配额限制，完全不需要碰 JWT 流。

这个设置之所以做成可选，原因很明确。身份请求头的传递，如果下游代理不验证来源，会形成 header injection 的攻击面。Anthropic 选择可选模式，正是因为不是每个团队都希望开发者身份流向下游。有些组织对开发者身份有数据隔离要求，把它视为敏感元数据。在生产环境打开之前，先确认你的代理能验证这些头来自 gateway，而不是来自任意上游客户端。

Vertex、Foundry 和 AWS 的 400/413 错误传递，以及一个 auto-compact 的 bug

2.1.233 之前，Vertex、Foundry 和 Claude Platform on AWS 上游返回的错误，会被 apps gateway 层吞掉。上游返回 400（请求有误）或 413（payload 过大）时，operator 看到的是一条通用的 gateway 错误，看不到上游自己的诊断信息。

这在两类故障场景里最为棘手。第一是 context 超长的情况。请求超过上游的 max_tokens 或上下文限制时返回 413，没有上游消息就无法分辨是 token 限制被触发、payload 格式有误，还是请求本身构造错误。第二，changelog 里专门提到，apps gateway 上 auto-compact 存在的一个 bug 也因为这个吞错机制而无声无息。开启了 auto-compact 并注意到行为异常的团队，根本拿不到错误去排查。

这次修复之后，上游的错误消息会原样到达 operator 代理。如果你的告警或重试逻辑依赖错误消息的内容做路由，记得补充对 Vertex、Foundry 和 AWS 各自错误格式的处理，三条链路的格式并不统一。

MCP v2 subscribe stream在 serverless 宿主上的无限重连

运行在 serverless 宿主（Cloud Run、Lambda，任何会在固定超时后断开长连接的平台）上的 MCP v2 服务端，会触发 Claude Code 的一个无限重连循环。服务端超时断开 subscriptions/listen stream，Claude Code 立即重新建立，服务端再次关闭，如此循环。实际效果是 Claude Code 持续消耗连接和 CPU，什么有效工作都不做，也不向 operator 暴露任何错误。

这次的修复阻止了这个重连循环。如果你在 serverless 环境运行 MCP v2 服务端，这个 patch 就是现在就应该升级的理由。

这个问题的根源是 MCP v2 协议的 subscribe 模型与 serverless 生命周期之间的结构性矛盾。serverless 平台为了节省资源会主动切断空闲长连接，而 subscriptions/listen 恰好是一个需要长期保持的 stream。2.1.233 的修复在客户端侧加了退避和终止条件，不要求服务端改变超时策略。对于已经在 Cloud Run 或 Lambda 上部署 MCP v2 服务的团队来说，不需要改动服务端配置，升级客户端就够了。

三条上游的 gateway 图景

三处修复放在一起看，能看到一个趋势，Vertex AI、Foundry 和 Claude Platform on AWS 上的 apps gateway 架构，随着每次 Claude Code 版本迭代都在增加运营深度，但三条链路的行为并不完全一致。

在 Vertex AI 上，gateway 使用 workload identity federation，forward_user_identity 映射的是经过认证的 Vertex principal。在 Foundry（Azure）上，身份通过 AAD token scope 流转。在 Claude Platform on AWS 上，凭证来自 Bedrock 访问策略。上游错误消息的格式也各有不同。Vertex 返回结构化 JSON 错误，Foundry 返回 Azure API Management 的错误结构，AWS 返回 Bedrock 的错误结构。

如果你的代理统一处理错误，2.1.233 可能让你看到比以前更多的错误格式差异。但这个代价是值得的，拿到可操作的诊断信息，好过以前对着通用 gateway 失败一头雾水。

从 operator 的视角看，这次错误透传的修复还间接说明了一件事。apps gateway 原先设计时并没有把上游错误可见性当成一级目标，更多是一个透明代理。随着 auto-compact、spend limit、identity forwarding 这类功能陆续进来，gateway 的角色正在从透明代理变成有状态的 operator 策略执行层，错误诊断能力也得跟上来。2.1.233 是这个方向的一步。

其他値得注意的变更

CLAUDE_CODE_WEBFETCH_CACHE_TTL_MS 现在可以配置 WebFetch 会话 URL 缓存的 TTL（默认 15 分钟不变）。对于频繁抓取同一组 URL 的自动化任务，可以通过调长 TTL 减少冗余请求。

Linux 上的 Bash 工具命令新增了内存 cgroup 支持（CLAUDE_CODE_TOOL_MEMORY_LIMIT），失控的构建进程不再能卡住整个会话。这对在 Linux 容器里运行长时间编译或测试任务的团队尤为实用。

Operator 现在应该做什么

如果你在做按用户的账单或配额管理，打开 forward_user_identity。 这个设置在 Anthropic upstream 的 apps gateway 配置里。打开后，确认你的代理能验证头的来源，再把 user.email 或 user.id 接入你的费用归因管道。这可以替换掉你原来作为应急方案写的任何 JWT 解析中间件。

检查你对 Vertex、Foundry 和 AWS 各自 400/413 格式的错误处理。 如果你之前依赖错误消息字符串做路由或告警，现在需要针对三条上游的实际格式分别测试一遍。

审查 MCP v2 服务端的部署情况。 如果你在 serverless 环境托管 MCP v2 服务端，把 Claude Code 升级到 2.1.233，同时检查服务端日志里有没有重复的 subscriptions/listen 请求，那是重连循环存在的痕迹。

注意 todo-tools 的变更。 TaskCreate、TaskGet、TaskUpdate、TaskList 和 TodoWrite 在 Opus 4.8、Sonnet 5、Fable 5、Mythos 5 及更新的模型上已默认关闭。如果你的 CI 或自动化脚本用到了这些工具，设置 CLAUDE_CODE_ENABLE_TODO_TOOLS=1，否则在新模型层上会静默失败。

TheRouter 用户需要关注什么

如果你通过 TheRouter 把 Claude Code 流量路由到 Vertex、Foundry 或 Bedrock，400/413 修复马上就有影响，你现在能看到上游的具体错误信息，而不是不透明的 gateway 错误。检查你的路由配置如何处理每条后端上各自的模型上下文限制。

forward_user_identity 的请求头约定也带来了一个代理链的顺序要求，这些头必须由 apps gateway 添加，不能由中间的路由层添加，否则来源验证的保证就破了。如果你在 Claude Code 和 apps gateway 之间插入了 TheRouter 或其他代理，确认身份请求头在 gateway 层写入，并在每一跳中间保持不变地透传。

更多关于通过企业 gateway 路由 Claude Code 流量的内容，见 TheRouter docs。