{"version":"2.1.232","anchor":"remote-control-can-take-over-a-session-another-process-still","canonical_anchor":"remote-control-can-take-over-a-session-another-process-still","heading":"Remote control can take over a session another process still holds","tier":"notice","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232\/e\/remote-control-can-take-over-a-session-another-process-still","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232","markdown":"### Remote control can take over a session another process still holds\n\nResuming a session another process still holds now tells you to run \/remote-control to take it over.\n\n**What**\n\nResuming a transcript whose remote-control session is still served by a running local process no longer silently conflicts. By default the bridge declines and tells you that running \/remote-control here moves it; enabling remote control explicitly takes the session over.\n\n**Details**\n\n- The decline is logged as `restored_pointer_held_locally`; the takeover records `tengu_bridge_restored_pointer_takeover`.\n- A host-directed target re-checks the logged-in owner immediately before connecting and fails with `host_target_owner_recheck_failed` if it no longer matches.\n- Disabling remote control now releases the session record with `keepRecord` instead of deleting it, and the v2 transport close event carries `recovery_in_flight`.\n- All of this still sits behind the existing `allow_remote_control` permission check.\n\n**Evidence**\n\n`tengu_bridge_restored_pointer_takeover`\n\n- Area: Remote Control\n- Names: `\/remote-control`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}