The device bridge reports its whole connection lifecycle, but none of it fires yet.
Full connect/close/heartbeat telemetry exists for the device bridge but is gated behind tengu_violin_wood along with the bridge itself.
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.225: not a boolean we can read
These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.
Read once, for one account on one subscription tier, against v2.1.225. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
The bridge reports its full connection lifecycle, gated the same way as the bridge itself, so none of it fires in this build unless tengu_violin_wood is on.
- events:
tengu_device_bridge_started,_stopped,_skipped(with reasonsmissing_organdmissing_account),_start_failed,_connected,_rejected,_closed,_connect_failed,_pong_timeout,_reconnect_exhaustedand_heartbeat_unsupported - the connected event records the protocol version plus negotiated
hb_interval_ms,staleness_msandrpc_timeout_ms - repeated transport failures are de-duplicated before being reported
tengu_device_bridge_heartbeat_unsupported
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.229
Device tools moved into a de-duplicating registry
Both mention device bridge
-
v2.1.229
Device binding reports attestation and counts dropped events generically
Both mention device bridge
-
v2.1.235
Device bridge shuts down mid-session when its flag is turned off
Both mention device bridge