Cloud sessions can expose your local tools to the remote worker and sign events with a device key.
Served-tool channel and device-key event signing are wired into attach but require server enablement.
tengu_violin_wood Off in both readingsThe 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: on
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's wrong with this entry?
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.
- 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,reconnectedandtools_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.
deviceEventSignerOnceBoundHere, eventSigner, requestAnnounce("worker_init", {
Strings lifted out of the shipped bundle, so the claim above can be checked against them.