Sweep 19 Sep 2026 · 02:36Z Build v2.1.278 500 read Stable v2.1.267 Latest v2.1.278 Next v2.1.278 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.274 ·

403 retry and design-consent handling gated by an additional origin check

Bearer-token 403 retry logic and the design-consent MCP error path now both require an extra same-origin check (Nk) before triggering.

TierUnder the hoodhow much it should matter to you
Useful1my rating, 1 to 5
Signal1worth watching, 1 to 5
AreaAuthwhat it touches
KindImprovementsin v2.1.274,
Group of 2 Under the hood

Bearer-token 403 retry logic and the design-consent MCP error path now both require an extra same-origin check (Nk) before triggering.

What

  • The fetch wrapper that retries a request after a 403 response with a sent bearer token now also requires a new check (Nk) to pass, in addition to the existing check that the response was a 403 with a token sent.
  • The same check now gates whether a 403 response gets turned into a needs_consent design-MCP error, restricting that behavior to first-party design MCP endpoints.

Why This narrows when the 403-retry and design-consent behavior kicks in, preventing them from firing for responses that aren't actually from the first-party design MCP service.

How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtWhat condition the new Nk(s) check actually verifies is not specified.

See this entry in the whole of v2.1.274 →