{"version":"2.1.251","anchor":"bridge-child-sessions-record-the-account-that-launched-them","canonical_anchor":"bridge-child-sessions-record-the-account-that-launched-them","heading":"Bridge child sessions record the account that launched them","tier":"soon","area":"Remote Bridge","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251\/e\/bridge-child-sessions-record-the-account-that-launched-them","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251","markdown":"### Bridge child sessions record the account that launched them\n\nBridge worker sessions record which account launched them, but the bridge is off.\n\n**What**\n\nA session spawned as a bridge worker now has the launching account and organization identifiers stamped into its environment by the supervisor, and reads them back at startup to record who owns it. The bridge feature itself is off in this build, so nothing reaches this path by default.\n\n**Details**\n\n- only applies to workers whose environment kind is `bridge`\n- the whole bridge feature is gated on `tengu_ccr_bridge`, which defaults to off\n\n**Evidence**\n\n`CLAUDE_CODE_BRIDGE_OWNER_ACCOUNT_UUID: te?.accountUuid`\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: 1\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}