The hop nobody tests

01The summary command works; the coding session fails

Claude Code 2.1.265 shipped on 8 September 2026. A gateway sign-in regression was repaired that evening in 2.1.266. A separate request-validation failure on third-party compatible endpoints remained until 2.1.268 on 10 September. Both could leave a coding session unusable, but they involved different contracts between the client and its destination.¹²⁴

Imagine a team routing its coding client through an intermediary. An engineer updates the client, runs a short non-interactive prompt and gets a response. Later, an interactive session fails with HTTP 400 before it edits a file. The engineer has tested the same backend twice, but the two requests need not carry the same tools. This is a hypothetical team, chosen to follow a failure that users actually reported.

In Claude Code issue #92964, the reporter described precisely that split: interactive requests failed against a third-party Anthropic-compatible backend while claude -p worked. Comparing captured bodies led them to the Artifact tool schema; removing one regex constraint made the request succeed. We read their reproduction account, not an independent run of it.⁷

The eventual 2.1.268 release note confirms a narrower product fact: since 2.1.265, a regex in that tool’s input schema could make turns fail with HTTP 400 on third-party compatible endpoints. It names ANTHROPIC_BASE_URL as the affected route. It does not establish that all gateways or every compatible backend failed.⁴

02A tool can break a turn without being called

The relevant schema constrained an identifier using Unicode property escapes such as \p{Cc}. In the reports, the downstream validator could not accept that expression. Rejecting the declaration rejected the request containing it, before the model could choose which tool to use. The user did not have to ask for an Artifact operation to encounter the failure.⁸⁹

For the imagined engineer, asking a simpler coding question would leave that declaration in place. Changing the task text could waste time without changing the rejected payload. The first report’s successful replay after removal of the constraint is useful because it isolates one difference; it is stronger evidence about location than a general claim that the new version stopped working.⁷

The issue authors considered the expression valid for an ECMA-262 engine with Unicode support and described the problem as a validator-dialect gap. That remains their technical account. We did not audit the downstream implementation or settle conformance responsibility. An endpoint can resemble an API at the message level yet disagree with one of the client’s newer schema constructs.⁸

03Two failures on different clocks

The same 2.1.265 release introduced a separate authentication regression. According to the 2.1.266 repair note, setting CLAUDE_CODE_USE_GATEWAY alone began forcing Cloud-gateway sign-in in configurations that used another credential route. The repair restored its previous dependence on both the base URL and auth-token settings. This concerned credential selection, rather than the Artifact schema.¹²

The gateway repair shipped about 3.3 hours after 2.1.265. The schema repair arrived about 47.9 hours after that release, including roughly 43 hours after the first issue was opened. Version 2.1.267 appeared between the reports and the repair. The table preserves the September timestamps so the comparison can be checked without turning the interval into a claim about the maintainers’ motives.^12346789

04The intermediary has its own responsibilities

The imagined team might operate a gateway for one reason and reach a compatible model endpoint for another. Those are distinct arrangements. A gateway forwarding Claude requests still has headers, authentication and feature support to preserve; a backend implementing an Anthropic-compatible format has its own interpretation of the payload. Calling both “the proxy” can conceal which component rejected the request.

Anthropic’s current gateway guide says third-party gateway products are not maintained or audited by Anthropic and need to keep pace with Claude Code capabilities. It also explicitly says routing Claude Code to non-Claude models through a gateway is unsupported. That current statement describes today’s documented support boundary; it does not retroactively prove the exact September policy or remove the regression acknowledged in the historical release note.¹⁰

For the engineer, the available evidence begins with the response origin and error category. A sign-in refusal and a schema-validation 400 can look like the same unusable terminal while needing different repairs. Retaining the client version, route and a sanitized error preserves that distinction without logging credentials or the contents of a private repository.

05Exercise the request that will do the work

A proposed upgrade check for this team would open an interactive session through its actual route, with the tools it normally exposes, and complete a harmless task in a disposable repository. A small print-mode prompt can remain a useful connectivity check. The report shows why it was insufficient evidence for this interactive payload.⁷

Keep the last known working client available for comparison. If the new version returns 400, compare sanitized tool declarations and the validator’s error before changing authentication or weakening schema checks. The authors’ request replays helped isolate the September defect, but manually stripping a constraint in production could change what identifiers are accepted. It is a diagnostic experiment, not a general deployment recommendation.⁸⁹

Then repeat the accepted task after the proposed repair. A successful login establishes access; a response from the model establishes that one request passed; a reviewed change establishes something about the complete task. These observations answer different questions. We have not performed that trial, and the public release note cannot substitute for the team’s own route and configuration.

06What the clocks cannot tell us

The two repair intervals are measurements from one release sequence. They do not establish a general ranking of gateway and third-party users, the relative difficulty of the fixes, or how quickly anyone began work. We have no internal triage record, installation counts or comparable series across later regressions. The earlier article inferred too much about support priority from elapsed time alone.

There is still a concrete consequence. The engineer’s direct connectivity result did not cover the interactive request, and the gateway-auth repair did not cover the schema rejection. In this historical case, 2.1.268 is the release that names the latter fix. For a current rollout, the useful evidence is a completed task through the intended route on the proposed build, rather than treating that September version as a present-day pin.²⁴