{"version":"2.1.229","anchor":"teleporting-a-session-to-the-cloud-now-stops-the-local-remot","canonical_anchor":"teleporting-a-session-to-the-cloud-now-stops-the-local-remot","heading":"Teleporting a session to the cloud now stops the local remote bridge from reviving it","tier":"notice","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.229\/e\/teleporting-a-session-to-the-cloud-now-stops-the-local-remot","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.229","markdown":"### Teleporting a session to the cloud now stops the local remote bridge from reviving it\n\nAfter you send a session to the cloud, your terminal stops trying to reconnect to it.\n\n**What**\n\nOnce a session has been sent to the cloud, the local remote-control bridge no longer tries to reattach to it, re-mint its credentials or re-poll for recovery. Each of those paths now bails out early reporting \"Session teleported to cloud\" rather than reconnecting to a session that has moved.\n\n**Details**\n\n- Teleported session ids are held in a bounded set, so very old ids eventually age out.\n- Reattach is either suppressed or fails terminally depending on the path.\n- New counters: `bridge_repl_v2_revive_reattach_teleported` and `bridge_repl_v2_remint_loop_teleported`.\n\n**Evidence**\n\n`[remote-bridge] Reattach suppressed for teleported session `\n\n- Area: Remote Control\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}