[BUG] Remote Control: a session I never connected appears in the remote/phone session list, while sessions I do connect drop constantly

Summary

Two remote-control symptoms that are mirror images of each other:

1. A local session I never ran /remote-control on shows up in the remote session list on my phone / at claude.ai/code, without any action on my part.
2. **Sessions I do explicitly connect to Remote Control are disconnected constantly** — they drop on their own and I have to reconnect.

The net effect is backwards from what I want: the sessions I never asked to expose are the ones that stay visible, and the ones I deliberately connect are the ones that keep dropping.

Environment

• Claude Code CLI 2.1.156
• macOS Darwin 25.5.0 (x86_64)
• No custom --permission-prompt-tool / external approval shim / permission bridge in use (standard setup)
• Viewing from the phone app and from the session list at claude.ai/code

Symptom 1 — session appears without being connected

• I started a normal local session and never ran /remote-control on it.
• It nonetheless appeared in the remote session list on my phone.
• I did not expose it deliberately and I don't see a documented way to opt a session out of appearing there.

<!-- Please add, if you can: was it always ALL your local sessions, or one specific session? Does it appear immediately on session start, or only after some action? -->

Symptom 2 — connected sessions drop constantly

• Sessions I connect via /remote-control disconnect on their own after a short time and need to be reconnected manually.
• This part overlaps with existing reports (see below); I'm including it because the pairing with Symptom 1 is the actual complaint: exposure and reliability are inverted.

Expected behavior

• A session should appear in the remote/phone session list only when I have connected it (or, if auto-listing is intended, there should be a documented opt-out and it should be stated clearly that local sessions are surfaced remotely by default).
• A session I do connect should stay connected as long as the terminal is open and the network is available.

Related issues

• Disconnection side is well documented: #33041, #76477, #34255, #77340 (and closed regressions #32998, #34500, #50767).
• Closest phantom-appearance issue is #61336, but that is closed and specific to a custom --permission-prompt-tool injecting rows via the unauthenticated 127.0.0.1:7437/agent-state bridge. This report is a standard setup with no such tool, so the mechanism appears different.

Questions for maintainers

• Are local sessions intended to auto-register in the remote session list without an explicit /remote-control? If so, is there an opt-out?
• Is there any relationship between the two symptoms (e.g. the wrong session claiming/holding the remote channel)?