Nothing to try yetTier: how much it should matter to you
2Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
Remote BridgeArea: what it touches
In DevelopmentKind: in v2.1.251,
What probably matters to youSection of the release
Every bridge availability check reads one gate whose fallback is false.
What
Every availability check for the cross-session remote-control bridge reads the same tengu_ccr_bridge gate, whose built-in fallback is false, so the bridge stays off unless the server turns the gate on. Its resolved value now appears in the CLI's internal debug output next to the rest of the feature-flag state.
Details
The same gate feeds a remote_control_available telemetry field.
The debug line prints unset when no value has been resolved.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Read from
Feature flag
tengu_ccr_bridgeOff by default, switched on for this account
The shipped code defaults this off, and the flag server returned on for the one account this site reads on this version. That is the reading that makes the entry above worth a second look, and it still says nothing about your account.
This account: on · anonymous baseline: on · compiled default in v2.1.251: off
Flag reading movedThe flag server now returns on for tengu_ccr_bridge, 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 movedThe flag server now returns nothing at all, having stopped carrying it for tengu_ccr_bridge, 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.
