Claude Code 2.1.233: Three Gateway Changes Every Operator Must Know

The most operationally impactful releases are often the ones without a headline feature. Claude Code 2.1.233, shipped this week, is that kind of release. Three changes buried in the changelog touch the gateway layer in ways that matter for any engineering team running Claude Code at scale through a proxy or cloud backend.

What changed in 2.1.233

forward_user_identity — per-developer identity now reaches your proxy

The apps gateway on Anthropic upstreams now supports an opt-in forward_user_identity setting. When enabled, the gateway stamps each outbound request with the signed-in developer's identity as request headers: user.id, user.email, and user.groups derived from the gateway-issued JWT.

Before this setting existed, a proxy sitting behind the apps gateway received the same opaque upstream credentials for every request, regardless of which developer originated it. Spend attribution per developer required intercepting and decoding the JWT yourself, then correlating it with usage logs — a workaround that was brittle across Vertex AI, Foundry, and Claude Platform on AWS, each of which surfaces credentials differently.

With forward_user_identity enabled, the gateway does the attribution wiring. Your proxy receives structured identity headers on every request and can write them directly into billing records, cost dashboards, or per-user quota enforcement without touching the JWT flow.

Why this is opt-in matters. Identity header forwarding adds a surface for header injection if the downstream proxy does not validate the header origin. Anthropic chose opt-in precisely because not every operator wants identity flowing downstream — some organizations have data-separation policies that treat developer identity as sensitive metadata. Before turning this on in production, confirm your proxy validates that these headers originate from the gateway, not from arbitrary upstream clients.

400/413 error forwarding from Vertex, Foundry, and AWS — and an auto-compact bug

Until 2.1.233, errors returned by upstream backends on Vertex, Foundry, and Claude Platform on AWS were being swallowed by the apps gateway layer. When the upstream returned a 400 (bad request) or 413 (payload too large), operators saw a generic gateway error without the upstream's own diagnostic message.

This matters most for two failure modes. First, context-length overruns: a request that exceeds the upstream's max_tokens or context limit returns 413. Without the upstream message, you could not distinguish a token-limit violation from an oversized payload or a malformed request. Second, and specifically mentioned in the changelog: a bug in auto-compact on apps gateway was also silenced by this swallowing behavior. Teams that enabled auto-compact and noticed it misbehaving had no error to act on.

The fix means upstream error messages now arrive at the operator proxy unmodified. If your alerting or retry logic keys on error message content, add handling for Vertex, Foundry, and AWS error formats — they are not uniform across backends.

MCP v2 subscribe stream — infinite reconnect on serverless hosts

MCP v2 servers on serverless hosts (Cloud Run, Lambda, anything that drops long-held HTTP connections on a fixed timeout) were triggering an infinite reconnect loop in Claude Code: the server terminates the subscriptions/listen stream on timeout, Claude Code reopens it, the server closes it again, and so on. In practice, this meant Claude Code burned connections and CPU without any meaningful work getting done, and surfaced no error to the operator.

The fix prevents the reconnect loop. If you run MCP v2 servers on serverless infrastructure, this patch is the reason to update now.

The gateway picture across upstreams

The three fixes together point to a pattern: the apps gateway architecture on Vertex AI, Foundry, and Claude Platform on AWS is gaining operational depth with each Claude Code release, but the behavior across backends is not identical.

On Vertex AI, the gateway uses workload identity federation; forward_user_identity maps the authenticated Vertex principal. On Foundry (Azure), identity flows through AAD token scopes. On Claude Platform on AWS, credentials derive from Bedrock access policies. The upstream error message formats also differ: Vertex returns structured JSON errors, Foundry returns Azure API Management error shapes, and AWS returns Bedrock error shapes.

If your proxy handles errors uniformly, 2.1.233 may surface more error variance than before. The tradeoff is worth it — you now have actionable diagnostics instead of generic gateway failures.

What operators should do now

Enable forward_user_identity if you run per-user billing or quota enforcement. The setting is in the apps gateway configuration for Anthropic upstreams. Enable it, confirm your proxy validates header origin, and wire user.email or user.id into your cost attribution pipeline. This replaces any JWT-extraction middleware you may have written as a workaround.

Review your error handling for 400/413 shapes from each upstream. If you relied on error message strings to route or alert, test against the actual Vertex, Foundry, and AWS error formats now that they pass through.

Audit MCP v2 server deployments. If you host MCP v2 servers on serverless infrastructure, update Claude Code to 2.1.233. Check your server logs for repeated subscriptions/listen requests — that pattern indicates the reconnect loop was active before this fix.

Note the todo-tools change. TaskCreate, TaskGet, TaskUpdate, TaskList, and TodoWrite are no longer available by default on Opus 4.8, Sonnet 5, Fable 5, Mythos 5, and newer models. If your CI or automated scripts used these tools, set CLAUDE_CODE_ENABLE_TODO_TOOLS=1 or expect silent failure on recent model tiers.

What TheRouter users should watch

If you route Claude Code traffic through TheRouter and then onward to Vertex, Foundry, or Bedrock, the 400/413 fix is immediately relevant: you will now see upstream error details rather than opaque gateway errors. Review how your routing config handles model-specific context limits on each backend.

The forward_user_identity header contract also implies an ordering constraint for proxy chains: the headers must be added by the apps gateway, not by an intermediate router, or the origin-validation guarantees break. If you insert TheRouter or another proxy between Claude Code and the apps gateway, ensure the identity headers are appended at the gateway layer and preserved as-is through any intermediate hop.

More on routing Claude Code traffic through enterprise gateways: TheRouter docs.