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.248 ·

Cloud sessions can serve your local tools to the remote worker and sign their events

Cloud sessions can expose your local tools to the remote worker and sign events with a device key.

Nothing to try yet Notable In Development
JSON All of v2.1.248
Nothing to try yetTier: how much it should matter to you
3Useful: my rating, 1 to 5
5Signal: worth watching, 1 to 5
Cloud SessionsArea: what it touches
In DevelopmentKind: in v2.1.248,
What probably matters to youSection of the release

Served-tool channel and device-key event signing are wired into attach but require server enablement.

What

Attaching to a cloud session now opens a second channel that lets the remote worker call tools running on your own machine, and signs the events the session sends back using a key tied to the device you bound to your account. The attach path loads both pieces in parallel and hands the session its served tools, a slot for a single in-flight served call, a callback for served-settings changes and the event signer. None of it runs in this build unless it is switched on server-side.

Details
  • Only sessions whose descriptor lists served tools open the channel; viewer-only sessions are skipped.
  • At most one served tool call is held in flight at a time.
  • State changes are announced to the worker with the reasons worker_init, attached, reconnected and tools_changed.
  • Events are signed by a signer keyed on the bound device id, and the headless send path uses the sibling signer keyed on the id bound to that session.
  • Gated behind the flag tengu_violin_wood, whose value compiled into this build is false, so the whole path stays dark by default; the signing and tool-serving also require the device to have been bound to your account, and with that gate off none of it runs.
Evidence

deviceEventSignerOnceBoundHere, eventSigner, requestAnnounce("worker_init", {

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

Read from
Feature flag
tengu_violin_wood Off in both readings

The flag server returned off for the account this site reads and for the anonymous baseline. A reading of off cannot rule out a rollout these two readings sit outside of.

This account: off · anonymous baseline: off · compiled default in v2.1.248: off

Read once, for one account on one subscription tier, against v2.1.248. 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 off for tengu_violin_wood, 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_violin_wood, 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 →

See this entry in the whole of v2.1.248 →

Feedback