[BUG] Desktop: sessions stay bound to dead Remote Control owner — no local re-home, Try-again loops, auto-RC toggle doesn't detach, local bypassPermissions suppressed

Preflight Checklist

• [x] I have searched existing issues — closest are #60790 (bot-closed as duplicate of #57361, which was closed not planned), #76070, #76477 (dead-owner variants), and #71518 / #29214 / #31908 (permissions over RC). This report covers three linked defects none of them cover: no local re-home for a present user, the auto-RC settings toggle not detaching existing sessions, and the local permission surface staying remote-restricted. Please do not dupe-close against #57361 — that issue was about Dispatch-shared sessions and was closed not-planned while this failure mode keeps being re-reported.
• [x] This is a single coherent bug report about one failure mode (sticky Remote Control binding in the Desktop app)
• [x] I am using the latest version of Claude Code (2.1.207)

What's Wrong?

When "auto remote control" is enabled, Desktop-app sessions get bound to a Remote Control owner process. That binding is permanent and one-way, which produces three defects:

1. No re-home to local — "Try again" loops forever against a dead owner.
After the owner process dies (app restart / reboot), reopening the session shows "Remote Control disconnected — Your terminal's Claude Code session stopped responding. Check your terminal for errors, then resend your message." Dismissing the banner and resending produces the same error indefinitely. The Desktop app never respawns a local owner or offers a "Resume locally" action — even though the full transcript is intact on disk and claude --resume <id> from a terminal works fine. The user is sitting at the machine that owns the session, typing into the Desktop app on that machine, and their input is still treated as remote relay to a dead process.

2. Turning OFF "auto remote control" does not unbind existing sessions.
The settings toggle only affects future sessions. Every already-bound session stays stuck in state (1) with no detach affordance anywhere in the UI.

3. While bound, the local permission mode is suppressed.
Sessions run with permissions.defaultMode: bypassPermissions (settings.json). Once a session is RC-bound, the Desktop window applies the restricted remote permission surface even for input typed locally on the owning machine — bypass permissions stops working for the local user. (Related to #71518/#31908, but those cover the remote client side; this is the local desktop losing its own configured mode.)

Steps to Reproduce

1. Enable "auto remote control"; use several Claude Code sessions in the Windows Desktop app with defaultMode: bypassPermissions.
2. Restart the machine (or the Desktop app) so the owner processes die.
3. Reopen any of those sessions in the Desktop app and send a message → "Remote Control disconnected" banner; "Try again"/resend loops with the same error.
4. Turn "auto remote control" OFF in settings → existing sessions remain bound and unrecoverable in the UI.

Expected Behavior

• The disconnected banner should offer "Resume locally" (spawn a fresh local owner attached to the same on-disk session), or the app should re-home automatically when the input originates on the owning machine.
• Disabling auto Remote Control should detach (or offer to detach) existing bound sessions.
• Input typed locally in the Desktop app should restore the locally configured permission mode.

Environment

• Claude Code v2.1.207, Claude Desktop app (Code sessions), Windows 11 Home 10.0.26200
• Sessions affected across multiple workspaces/profiles; transcripts intact and CLI-resumable throughout — this is purely a Desktop UI binding defect.

Impact

The intended Remote Control roundtrip (work locally → drive from mobile while out → resume locally with full permissions on return) is currently impossible to complete: the return leg strands every session behind a dead bridge until the user discovers CLI resume by trial and error.