{"version":"2.1.238","anchor":"mcp-connect-results-are-stamped-with-the-account-that-starte","canonical_anchor":"mcp-connect-results-are-stamped-with-the-account-that-starte","heading":"MCP connect results are stamped with the account that started them","tier":"soon","area":"MCP","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238\/e\/mcp-connect-results-are-stamped-with-the-account-that-starte","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238","markdown":"### MCP connect results are stamped with the account that started them\n\nMCP connections that finish after you switch accounts get dropped, but almost all of it is dark.\n\n**What**\n\nEvery connect attempt is tagged with the account in effect when it began; results that settle after a switch are dropped and their sockets closed instead of being written into the app's server list. Also new: cached servers are re-dialled and adopted on lazy connect, and a disable or policy denial landing mid-flight replaces the row rather than losing to the connect. Only the policy-blocked path runs on a default build; the rest sits behind the discovery cache, which is off.\n\n**Details**\n\n- An account change bumps a process-wide counter and fires a one-shot telemetry event.\n- Mid-flight denials produce a `disabled` row or a `POLICY_BLOCKED` failed row.\n\n**Evidence**\n\n`applyConnectionResult: disposing connect that settled after a disable`\n\n- Area: MCP\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}