[Bug] Remote Control auto-enable is skipped on resumed sessions, so every session loses its bridge after an app update

Remote Control is not re-enabled on resumed sessions after an app update or restart

Summary

remoteControlAtStartup: true reliably enables Remote Control on newly created sessions, but the auto-enable path is gated behind a "not a resume" condition. Every session restored after an app update or app restart is a resume, so none of them re-bridge. With many concurrent sessions open, each one has to be opened manually and re-bridged with /remote-control after every update.

Environment

• Claude desktop app: 1.24012.9 (macOS)
• Claude Code: 2.1.201
• macOS 26.5.2, arm64
• remoteControlAtStartup: true set in both ~/.claude.json and ~/.claude/settings.json (user tier)

Steps to reproduce

1. Set remoteControlAtStartup: true.
2. Open several sessions in the desktop app and confirm each shows a claude.ai/code/session_... URL.
3. Let the app update itself, or quit and relaunch it.
4. Observe the restored sessions.

Expected: restored sessions re-establish their Remote Control bridge, matching the "Start Remote Control bridge automatically each session" setting description.

Actual: no restored session re-bridges. Each must be opened and /remote-control run by hand.

Root cause

In app.asar, auto-enable is gated on o:

this.emit("event", A),
this.previewIdleManager.registerSession(r),
this.replayPendingVisibility(r),
o && this.maybeAutoEnableRemoteControl(i, f)

The sibling call in the same function establishes what o means:

this.setupQueryHandlers(l, r, { isResume: !!u.resume || !o })

!o is treated as a resume, so maybeAutoEnableRemoteControl runs only for fresh sessions and is skipped for every resumed one.

A second condition compounds it. handleRemoteControlCommand rejects sessions with no active query:

if (!e.query) {
  const c = "Remote Control requires an active session. Send a message first.";
  return { ok: false, error: c, reason: "no_active_session" };
}

A restored, idle session therefore cannot be bridged even on an explicit attempt until a message is sent to it first.

Log evidence

Auto-enable fires correctly on fresh sessions:

2026-07-27 10:53:15 [info] [rcAutoEnable] verdict: enable=true source=explicit_pref
2026-07-27 10:53:15 [info] Enabling remote control for session local_fd2ead2f-673c-46c8-a09e-984995230c61
2026-07-27 10:53:21 [info] Remote control enabled: https://claude.ai/code/session_01VY7dsVtRYP3tG2FYhteVKF

No corresponding [rcAutoEnable] verdict is ever emitted for a resumed session.

Related, lower priority: slow bridge recovery after sleep

The transport layer does recover on its own, so this is a latency complaint rather than a correctness one. A representative sequence took 78 minutes to heal:

2026-07-22 22:21:23 [info]  Transport permanently closed for session cse_01TY5RWP8k6... code=401
2026-07-22 22:21:24 [error] Transport reconnect failed: registerWorker: HTTP 401
2026-07-22 22:21:24 [info]  Forcing session_ingress_token refresh (trigger=reconnect_401)
2026-07-22 22:21:24 [warn]  reconnectSession failed during ingress-token refresh:
                            Environment env_013rLJZ... not found.
2026-07-22 23:34:45 [warn]  Poll returned 404; re-registering (attempt 1/3)
2026-07-22 23:39:33 [info]  Environment registered: env_013rLJZ...
2026-07-22 23:39:35 [info]  Session cse_01TY5RWP8k6... reconnected successfully

The reconnect path refreshes the ingress token against an environment id the server has already reaped, and that specific failure is not retried directly. Recovery only arrives later via the independent Poll returned 404; re-registering path. Treating Environment ... not found during an ingress-token refresh as an immediate trigger to re-register would collapse that 78 minute window.

Suggested fix

Run maybeAutoEnableRemoteControl on resumed sessions as well, not just fresh ones. If the active-query requirement has to stay, enabling it lazily on the session's next query start would still remove the manual step.

Related issues

Several open reports describe symptoms that this gate would explain, none of them identifying the cause:

• #80457 — Remote control not established automatically on startup (win32, no root cause given)
• #79388 — Remote Control does not auto-reconnect after a network interruption
• #33041 — /remote-control disconnects frequently
• #77985 — feature request for machine-level Remote Control that survives session death

Happy to fold this into any of those if a maintainer prefers a single thread.

Workaround

None available outside the UI. toggleRemoteControl(sessionId, enable) is exposed only as Electron IPC on the LocalSessions interface. There is no CLI subcommand and no local control port, so the reconnect cannot be scripted.