{"version":"2.1.251","anchor":"remote-control-bridge-still-gated-off-by-default","canonical_anchor":"remote-control-bridge-still-gated-off-by-default","heading":"Remote control bridge still gated off by default","tier":"soon","area":"Remote Bridge","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251\/e\/remote-control-bridge-still-gated-off-by-default","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251","markdown":"### Remote control bridge still gated off by default\n\nThe cross-session remote-control bridge stays off unless the server enables it; its state shows in debug output.\n\n**What**\n\nEvery 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.\n\n**Details**\n\n- The same gate feeds a `remote_control_available` telemetry field.\n- The debug line prints `unset` when no value has been resolved.\n\n**Evidence**\n\n`tengu_ccr_bridge=${String(o.tengu_ccr_bridge ?? \"unset\")}`\n\n- Flag `tengu_ccr_bridge`: Off by default, switched on for this account (read for one account on one subscription tier against v2.1.251; this account: on, anonymous baseline: on, compiled default: off)\n- Area: Remote Bridge\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}