Remote Control sessions disconnect over time and cannot be reconnected; /remote-control throws "failed to disconnect: Cannot read properties of undefined (reading 'session_url')"

I see this sometimes too. Remote-control overall where useful is very limited in its reliability for me.

• Remote-control never connects by default, even though I have that set.
• Remote-control drops if I ever /clear. So from the remote I always have to use /compact insteda.
• Remote-control mostly connects successfully... if I wait for the previous prompt to finish and baby the request through. If I don't, it often might not.
• Remote control will stay connected for several hours... but then fall off. And it gets into the state d-a-ryan describes above where it's not connected, but I can't reconnect it, and just see the useless error message Remote Control failed to disconnect: Cannot read properties of undefined (reading 'session_url') as described.

The duplicate-name rows in your table ("Testing / Connected / 4h" above "Testing / Disconnected / 6h") have a concrete mechanism, and this issue looks like two separable faults.

1. Why sessions drop — not gradual expiry. A session loses its bridge when the Claude Code process hosting it ends, most commonly a Desktop app relaunch including the automatic relaunch after an app update. It is not the idle timeout: pauseSession() returns early for sessions with a live bridge (Skipping pause for session … - remote control is active), so they are exempt from the 900s WarmLifecycle pause. On resume the process respawns, but the auto-enable predicate is never evaluated — it runs only at session creation — so nothing re-arms. Log evidence in #82140; see also #78730 and #78564. Your "recently active sessions are connected; older ones have all dropped" pattern is exactly what that produces: the older a session, the likelier it has been through a relaunch.

2. Why the duplicate rows appear. When a dropped session is re-armed, the new bridge handle is appended to bridgeSessionIds and the dead one is never retired, so the mobile list gains a second row rather than updating the existing one. That is the source of your two "Testing" rows. Filed as #83378.

3. Why /remote-control throws for you but not for me. On Claude Desktop 1.24012.9 / Claude Code 2.1.219 (Windows 11), on a session that had shown Disconnected since the previous day: I sent an ordinary message in the session and got a normal response, then ran /remote-control a few minutes later. It reconnected cleanly and restored full history on mobile.

The likely difference is which branch the toggle takes. It toggles on remoteControlEnabled, and the error text you quote is from the disconnect path (#77915, #78336). In my case the persisted session record had no remoteControlEnabled key at all after the process died, so the toggle took the connect branch and never dereferenced session_url. If your long-lived sessions retain remoteControlEnabled: true while the bridge is dead, the toggle attempts a disconnect first and reads session_url off a result that is gone.

If that holds, "cannot be reconnected" is a consequence of the missing null guard rather than a separate reconnect failure — meaning #77915's guard would fix the reconnect path here too. Worth splitting so that half does not block on the "drops over time" half.

Confirming on macOS (Darwin 25.3.0, Apple Silicon), Claude Code desktop app, CLI 2.1.227, "remoteControlAtStartup": true, claude.ai OAuth. Same pattern: sessions created days ago were remotely controllable at first, then dropped off the mobile app's device list one by one; only freshly created sessions show up. The mobile app reports "no devices connected recently" while several of those sessions are still running in the Desktop app.

One data point that complements @Smedis's process-restart mechanism: the presence can also be lost without any app relaunch. ~/Library/Logs/Claude/main.log shows the app running continuously (no gap in hourly updater checks from Aug 9 through Aug 11), yet on Aug 9 the bridge entered a reconnect loop it never recovered from:

2026-08-09 08:25:31 [info] [remote-control] bridge_state: reconnecting — presence heartbeats failing — reconnecting
2026-08-09 08:26:03 [info] [remote-control] bridge_state: reconnecting — presence recovery failed — retrying
2026-08-09 08:26:33 [info] [remote-control] bridge_state: reconnecting — presence heartbeats failing — reconnecting
2026-08-09 08:27:05 [info] [remote-control] bridge_state: reconnecting — presence recovery failed — retrying

After that, the affected sessions never re-registered. Two months of logs confirm what Smedis inferred: Enabling remote control for session <id> appears exactly once per session, at creation — never on resume, and notably not even when the user interacts with the session again. Example: session local_49206ef3-… was enabled at creation on Aug 5, dropped at some point, was actively used again on Aug 11 at 23:24 (visible SDK activity in the log), and no re-enable or bridge reconnect was attempted for it.

So the two faults compound on macOS too:

1. presence loss can happen in-process (heartbeat/recovery failure), not only via app relaunch;
2. nothing ever re-arms remote control for an existing session — the auto-enable predicate only runs at session creation, and the Desktop app has no equivalent of the CLI's /remote-control to do it manually.

Happy to provide fuller logs if useful.