Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.234 ·

Artifact requests from cloud sessions can go via a gateway relay

Cloud sessions may route artifact calls through a gateway relay, falling back to direct calls on failure.

You'll notice Improvements
JSON All of v2.1.234
You'll noticeTier: how much it should matter to you
2Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
ArtifactsArea: what it touches
ImprovementsKind: in v2.1.234,
What probably matters to youSection of the release
What

When Claude Code is running as a remote session, calls to claude.ai for publishing, comments and reads may now be sent through /v1/code/agent-proxy/frame on the gateway using the session's own token, instead of calling claude.ai directly with OAuth. If the relay refuses or errors, the request falls back to the direct call and that request family is skipped for a cool-off period.

Details
  • Requests are grouped into families (boot, publish, comments, db) by method and URL shape; each family keeps its own decline and serve windows, with failures opening roughly a five-minute fallback to direct calls.
  • Replies carry route: "direct" or route: "relay" plus a flag saying whether the answer really came from claude.ai, derived from an x-ccr-relay-upstream header. Every caller now checks it, so a relay-level HTTP status is no longer read as claude.ai's verdict: a database write whose relay call failed reports the outcome as unknown rather than failed, and publish failures get their own advisory.
  • The relay path only engages when the session is marked remote with no environment kind set, and behind the tengu_cobalt_plinth_sorrel flag, whose built-in fallback is on when the server sends no value.
  • Frame-specific headers matching ^x-frame-[a-z0-9-]+$ are stripped on the relay path. Retry-after on 429/503 is honoured only when the response actually came from claude.ai.
  • Telemetry artifact_frame_relay records relay_unavailable, relay_refused, relay_error and request_error, tagged with the family.
Evidence

artifact_frame_relay, /v1/code/agent-proxy/frame, x-ccr-relay-upstream, tengu_cobalt_plinth_sorrel, db write outcome unknown (relay HTTP

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Read from
Feature flag
tengu_cobalt_plinth_sorrel On for this account, and not off by default

The flag server returned on for the one account this site reads, and nothing in this release compiles it off by default. The compiled default is shown below, and says which it is when we cannot read one: a fifth of gates compile in a string or a number rather than on or off, and most published releases have no gate table behind them at all. No client can see what the server returns for your account.

This account: on · anonymous baseline: on · compiled default in v2.1.234: on

Read once, for one account on one subscription tier, against v2.1.234. It isn't a statement about your account. What a flag value here can and cannot tell you

What has happened since
Flag reading moved The flag server now returns on for tengu_cobalt_plinth_sorrel, read as this account. A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.
Flag reading moved The flag server now returns nothing at all, having stopped carrying it for tengu_cobalt_plinth_sorrel, read as this account. A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.

See this across every release →

How sure we are
One source agreesOne thing we can check says the same as this entry.
The name it cites is new in this buildNew in this build: tengu_cobalt_plinth_sorrel

See this entry in the whole of v2.1.234 →

Feedback