[BUG] Claude Desktop app: Remote Control never reattaches existing sessions after a WiFi drop — mints a new auth token per reconnect (99 accumulated, unrevocable); CLI works, Desktop app doesn't

Summary

The Claude Desktop app's Remote Control (Claude Code sessions controlled from the iPhone app) does not reconnect existing sessions after a network drop. When the Mac loses WiFi and comes back online — Mac awake, internet restored, Desktop app open — every previously-paired session stays offline in the iPhone app forever. Typing into an existing session does not bring it back online. Only starting a brand-new session shows as "connected."

Critically, this is specific to the Desktop app. The terminal CLI (claude remote-control) reconnects the same session fine on the same machine/account. So the host process that the Desktop app manages does not reattach the way the CLI does.

Token leak (key evidence)

Because every reconnect spins up a new session instead of reattaching, the app mints a new authorization token on every reconnect instead of reusing the existing one. Under Settings → Claude Code → "Authorization tokens," I now have 99 tokens (page 1 of 20), each labeled "Claude Code" with scopes user:file_upload, user:inference, user:profile, user:sessions:claude_code, the bulk reading "Connected 1 hour ago" / "48 minutes ago." These accumulated purely from repeated WiFi-drop reconnects over normal use — one dead token per drop.

The per-token revoke (trash icon) also does not work, so the list cannot be cleaned up.

Steps to reproduce

1. Start a Remote Control session from the Claude Desktop app (not the terminal CLI) and confirm it shows "connected" in the iPhone app.
2. Disconnect the Mac from WiFi briefly (well under the ~10-minute outage limit), then reconnect.
3. With the Mac awake, internet restored, and the Desktop app open, open the iPhone app.

Expected: the existing session reattaches using the existing token and shows online.
Actual: the existing session stays offline permanently. Typing into it does nothing. Only a new session connects, and a new auth token is minted. Old tokens pile up (99 and counting) and cannot be revoked.

Expected behavior

• When the Mac is awake, online, and the Desktop app is open, previously-paired sessions should reattach to the existing host process and token and return to "online" — matching the CLI's behavior.
• No new authorization token should be minted on a reconnect of an existing session.
• The revoke control on the token list should actually revoke.

Impact

High. Remote Control via the Desktop app is unusable for any session you intend to keep over a normal workday, because the first WiFi blip orphans every session and there is no way to get it back without creating a new one. The token leak compounds it (99 dead tokens, unrevocable).

Environment

• Surface: Claude Desktop app (macOS), latest version as of 2026-06-09 (auto-updated).
• OS: macOS (Darwin 25.5.0), Apple Silicon.
• Client: Claude iPhone app.
• Note: The terminal CLI claude remote-control on the same Mac/account reconnects existing sessions correctly — the bug is isolated to the Desktop-app-managed host.

Related issues

• #60100 — remote-control: allow reconnecting to existing session instead of creating new one (open)
• #28402 — Remote Control session not visible in session list, cannot reconnect after leaving (open)
• #66381 — [DOCS] "stuck on reconnecting" after resume / OAuth refresh race (the OAuth-race variant was fixed in v2.1.169, but this Desktop-app reattach + token-leak case is not covered by that fix; still reproduces on latest)

These existing issues don't pin the Desktop-app-specific angle: (a) a new auth token minted per reconnect, (b) ~99 unrevocable tokens accumulating, and (c) CLI works while the Desktop app does not on the same machine.