{"version":"2.1.268","anchor":"bridge-session-fetch-now-blocked-for-third-party-providers","canonical_anchor":"bridge-session-fetch-now-blocked-for-third-party-providers","heading":"Bridge session fetch now blocked for third-party providers","tier":"notice","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/bridge-session-fetch-now-blocked-for-third-party-providers","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### Bridge session fetch now blocked for third-party providers\n\nBridge session fetches are now blocked outright for non-Anthropic providers\n\n**What**\n\nThe internal `bridge_session_get` helper, used to fetch a session over the bridge, now checks upfront whether the active provider is Anthropic itself (first-party). If it isn't, the fetch is refused immediately, returning `session:null` and logging a new telemetry reason (`bridge_session_get_3p_provider`). Separately, this helper gained a `useV2` override option, so it no longer always derives whether to use the V2 path solely from `isCcrV2SessionCrudEnabled`.\n\n**Why**\n\nThis stops session-fetch requests from going out to the bridge when a third-party provider is in use, rather than attempting a fetch that presumably wasn't meant to succeed in that setup.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}