[BUG] Desktop: restored sessions never re-register Remote Control after an app restart, despite remoteControlAtStartup: true

Status Closed — duplicate

Reported on v2.1.219

Maintainer reply None cached

Activity 6 comments · opened Aug 7, 2026 · closed Aug 20, 2026

Preflight Checklist

[x] I have searched existing issues — related to but distinct from #77022, see below
[x] This is a single bug report
[x] I am using the latest version

What's Wrong?

With remoteControlAtStartup: true, the Desktop app enables Remote Control for a session only when that session is opened. Restarting the app kills every existing bridge, and restored sessions never re-register on their own — they stay invisible from the mobile app and claude.ai/code until you click into each one individually.

The setting reads as "connect automatically when an interactive session starts", so the expectation is that after an app restart the sessions in the sidebar are reachable from the phone. In practice only the ones you happen to open are.

Evidence

The app was restarted this morning at 08:38:37. Every session in the sidebar had Remote Control enabled at some point, but only the two opened after the restart re-registered:

local_abada47d…   enabled 08-07 09:43:48   ← session created 08-05, re-registered when opened today
local_b83d397f…   enabled 08-07 09:33:25   ← opened today

local_4492287e…   enabled 08-06 14:29:15   ← never re-registered after the 08:38 restart
local_57e2de86…   enabled 08-06 14:37:09   ← "
local_e2702028…   enabled 08-05 16:57:02   ← "
local_50a82b57…   enabled 08-06 14:18:58   ← "
local_da070b66…   enabled 08-06 14:25:14   ← "

local_abada47d is the control case that isolates the trigger: it is a session from 08-05, its first log mention is 2026-08-05 20:34:36, and it re-registered at 09:43:48 today — the moment it was opened, not at app startup. So the mechanism works; it is just never invoked for sessions the user has not touched since launch.

No code 4090 occurrences today, so this is not the takeover failure and not a transport problem — the bridges are simply never created.

Why this is not #77022

#77022 is a live bridge being killed by a worker-epoch takeover (code 4090) and failing to recover. This report is the opposite situation: no bridge is ever established for the affected sessions after a restart, and the log shows no failure at all — just the absence of Enabling remote control lines.

Both produce the same user-visible symptom, which is probably why they get conflated: "my Desktop sessions are not in the phone's session list".

What Should Happen?

When remoteControlAtStartup is on, sessions restored at app launch should re-register their Remote Control bridge, the same way a freshly opened one does. Restoring a session already reconnects it to its transcript and worktree; the remote bridge is the piece left behind.

If eagerly bridging every restored session is too costly, the alternative is to make the state visible: today the sidebar gives no indication which sessions are reachable remotely and which are not, so the only way to find out is to check the phone.

Reproduction

Set remoteControlAtStartup: true in ~/.claude/settings.json.
Open several Code sessions in Desktop and confirm each logs Enabling remote control for session local_… and appears in the Claude mobile app.
Quit and relaunch the Desktop app.
The sessions are restored in the sidebar, but none appear in the mobile app.
Click into one — it logs Enabling remote control within seconds and appears on mobile. The untouched ones stay missing indefinitely.

Workaround

Open each session you want reachable from the phone; it registers in a few seconds.

Environment

Claude Desktop: 1.24012.11 (Linux beta, apt)
Embedded CLI: 2.1.219
Linux Mint 22.3 (Ubuntu 24.04 base), x86_64, X11, Cinnamon
remoteControlAtStartup: true in user settings

Session IDs truncated because this issue is public.

View original on GitHub ↗

5 Comments

felipekj · 20 days ago

Still reproduces on 1.24012.11 three days later, and two further observations from today's log sharpen the picture. The second one is probably the bigger half of the bug: an app restart is not required to lose the bridge.

1. Idle timeout disconnects live sessions, and they never re-register

WarmLifecycle:session disconnects sessions on an idle timer during normal use, and no Enabling remote control ever follows. Today alone:

110 Idle timeout reached, disconnecting local_… events
across 7 distinct sessions
against 18 Enabling remote control events, every one of which corresponds to a session being opened, never to a recovery after a disconnect

The same session is disconnected over and over on a fixed ~15-minute cycle:

09:17:48 Idle timeout reached, disconnecting local_5286f2df…
09:32:48 Idle timeout reached, disconnecting local_5286f2df…
09:47:48 Idle timeout reached, disconnecting local_5286f2df…
…
13:32:48 Idle timeout reached, disconnecting local_5286f2df…
13:47:48 Idle timeout reached, disconnecting local_5286f2df…

That session registered Remote Control once at 09:00:48 and was then disconnected roughly every 15 minutes for the rest of the day without ever being re-bridged. The repetition on an already-disconnected session also suggests the handler keeps firing rather than settling.

The practical consequence is worse than the original report: it is not only that restored sessions stay unbridged after a restart. A session you bridged this morning and left running silently drops off the phone a quarter of an hour later, and stays off. From the user side, Remote Control appears to work for a few minutes after opening each session and then stop.

2. Duplicate registration for the same session

One session registered twice, 9 seconds apart:

10:32:39 Enabling remote control for session local_99429016…
10:32:48 Enabling remote control for session local_99429016…
10:33:05 [remote-control] bridge_state: ready
10:33:05 [remote-control] bridge_state: connected

Only one ready/connected pair follows. Worth flagging because the failure in #77022 is a worker-epoch takeover — a second registration superseding a live connection is exactly the shape that produces code 4090, so this may be a path into that bug rather than a harmless duplicate.

Environment

Unchanged from the original report: Claude Desktop 1.24012.11 (Linux beta, apt), embedded CLI 2.1.219, remoteControlAtStartup: true. No code 4090 today, so none of the above is the #77022 failure — these sessions lose their bridge with no transport error at all.

felipekj · 19 days ago

Correction to my previous comment. I claimed the idle timeout was "the bigger half of the bug" and that an app restart is not required to lose the bridge. That is wrong, and testing today isolates the cause more narrowly than the original report did.

The idle lifecycle does not affect Remote Control reachability at all.

Session local_905aa1d1… registered at 08:39:15 today, seconds after the app started at 08:39:00. Since then it has taken 36 Idle timeout reached, disconnecting events, the last at 13:12:07. At 13:26 it was still listed as an addressable Remote Control peer, and it accepted and processed a cross-session message sent to it:

13:26:28 [Stop hook] Query completed for session local_905aa1d1…
13:26:28 [WarmLifecycle:session] Starting idle timeout for local_905aa1d1…: 900s

So a session can be idle-disconnected three dozen times and remain fully reachable. WarmLifecycle is tearing down the warm process, not the bridge, and the two are independent. (That log line also pins the interval: 900s.)

Conversely, the unreachable sessions were never idle-disconnected today at all.

local_bff479f6…   last registration 08-10 13:22:58   idle disconnects today: 0   not addressable
local_eeaec74e…   last registration 08-10 10:13:27   idle disconnects today: 0   not addressable
local_99429016…   last registration 08-10 10:32:48   idle disconnects today: 0   not addressable

Their last registration predates today's restart, they never warmed up again, and they are absent from the peer list entirely — no address, so nothing can reach them, including cross-session messaging from another session.

What this narrows down

The only event that loses the bridge is the app restart, and the defect is exactly and only the one in the original report: restored sessions never re-register. Nothing in the idle path needs changing, and the periodic-disconnect noise in my earlier comment is a red herring — I'd disregard that half of it.

That also makes the user-facing shape simpler than it looked: reachability is decided once per app start. Sessions opened after the restart work all day regardless of idleness; sessions carried over from before are unreachable until manually opened, no matter what happens afterwards.

Still worth keeping from the earlier comment: the duplicate Enabling remote control for the same session 9 seconds apart, given the worker-epoch takeover in #77022.

louij2 · 19 days ago

Corroborating data point on macOS — this doesn't look Linux-specific, and I have a variant that's arguably worse than the reproduction steps describe.

Environment: macOS 26.6, Claude Desktop 1.26832.0, embedded CLI 2.1.222, Apple Silicon. remoteControlAtStartup: true in ~/.claude/settings.json.

Observed: Restarted the Desktop app (Cmd+Q, relaunch) at 17:25:19. Prior to the restart, Enabling remote control for session <id> fired reliably in the logs every time a session was opened/used throughout the day (confirmed multiple instances across several hours). Since the restart:

Log shows [buddy] starting bridge / [buddy] bridge started once, at 17:25:19.
Zero Enabling remote control for session ... lines logged afterward — not for restored-but-untouched sessions, and not for the one session I've had in continuous active use since the restart.
That active session sent/received multiple messages over 21+ minutes post-restart with no registration line ever appearing, versus pre-restart behavior where opening/using a session triggered the Enabling remote control log within seconds.

So on this machine it's not just "restored-but-unopened sessions stay unregistered" (the reported repro) — even a session that's been opened and actively used since the restart never re-registers. Possibly the same root cause, just a slower/more complete failure to re-trigger the bridge logic after a restart, rather than it firing selectively on session-open as described. Happy to pull more of the log around [buddy]/sessions-bridge/remote-control if useful.

felipekj · 19 days ago

Traced the exact trigger, which is narrower than "when a session is opened" and makes the fix location clearer.

Registration is tied to spawning the session's Claude Code process, not to session lifecycle or focus.

13:32:20 Using Claude Code binary at: …/claude-code/2.1.219/claude
13:32:20 [rcAutoEnable] verdict: enable=true source=explicit_settings
13:32:20 Enabling remote control for session local_e0b52bce…

rcAutoEnable evaluates at the moment the binary is spawned for that session. Every Enabling remote control in my logs is immediately preceded by that pair.

Focusing a session is not enough. I moved focus to a session whose last registration was the previous day:

13:56:47 [CCD] LocalSessions.setFocusedSession: sessionId=local_69f3686d…

Its last registration is still 08-10 13:22:06. No spawn, no rcAutoEnable, no bridge. The session was visible and selected in the UI and remained unreachable.

What this means for the bug. Restoring a session at app start restores its UI state without spawning its process, so rcAutoEnable never runs for it. The session looks completely normal in the sidebar while having no bridge, and nothing in the UI distinguishes the two states. A restored session only becomes reachable once something makes it actually run — i.e. when the user sends it a prompt.

So remoteControlAtStartup's documented behaviour ("connect automatically when an interactive session starts") holds only for sessions that execute something. For a restored session sitting idle, the setting silently does nothing.

Correction to the workaround I posted earlier. I wrote "open each session you want reachable". That is not sufficient — opening and focusing do not register. The session has to be given work. The accurate workaround is: send a prompt in each session you want reachable from the phone, once per app start.

Unrelated observation from the same log path, in case it is worth documenting: placing the setting in project-tier settings is silently ignored, with a clear reason —

[SettingsResolver] Ignoring remoteControlAtStartup from project tier —
only user or managed settings can auto-enable Remote Control

That is sensible behaviour (a checked-in file should not enable Remote Control for everyone), and it matches the settings docs, but the message only appears in main.log, so someone who sets it in .claude/settings.json gets no feedback anywhere in the UI.

felipekj · 19 days ago

Found the specific gap, and it corrects the workaround I posted earlier.

rcAutoEnable is evaluated on session creation, not on every process spawn.

Today's log has 9 Using Claude Code binary at: … spawns and only 2 [rcAutoEnable] verdict: evaluations — at 08:39:15 and 13:32:20, which are the two sessions that were newly created. The other seven spawns are restored sessions starting their process to run a prompt. For those, rcAutoEnable never runs at all. It is not deciding enable=false; the check is simply not on that path.

This invalidates the "just send it a prompt" workaround I suggested. Four prompts sent today to four restored sessions, none of which registered:

13:34:52 LocalSessions.sendMessage → local_bff479f6…  (8 chars)    no registration
13:39:32 LocalSessions.sendMessage → local_eeaec74e…  (110 chars)  no registration
13:58:06 LocalSessions.sendMessage → local_69f3686d…  (282 chars)  no registration
14:04:21 LocalSessions.sendMessage → local_50a82b57…  (25 chars)   no registration

For contrast, the same sendMessage → Enabling remote control pair fires in the same second when the session was created in the running app instance:

08-10 20:15:52 LocalSessions.sendMessage: sessionId=local_50a82b57…
08-10 20:15:52 Enabling remote control for session local_50a82b57…

Same session, same action, different app process — registers in one, silently doesn't in the other.

The enable path itself is intact. Running /remote-control manually in that very session, minutes after the prompt failed to register it, works immediately:

14:09:55 Enabling remote control for session local_50a82b57…
14:09:56 [remote-control] bridge_state: ready
14:09:56 Remote control enabled: https://claude.ai/code/session_01VJ…
14:09:56 [remote-control] bridge_state: connected

So nothing is broken about enabling, connecting, or the transport. The only thing missing is the rcAutoEnable evaluation on the restored-session path.

Summary of what is and isn't sufficient, since I got this wrong twice:

| Action on a restored session | Registers? |
| --- | --- |
| App restart with remoteControlAtStartup: true | no |
| Opening / focusing the session | no |
| Sending it a prompt (spawns its process, runs the query) | no |
| /remote-control typed in the session | yes, immediately |

The accurate workaround is therefore /remote-control once per session, once per app start. It takes about a second per session and survives idleness for the rest of that app process.

Showing cached comments. Read the full discussion on GitHub ↗

[BUG] Desktop: restored sessions never re-register Remote Control after an app restart, despite remoteControlAtStartup: true

Preflight Checklist

What's Wrong?

Evidence

Why this is not #77022

What Should Happen?

Reproduction

Workaround

Environment

5 Comments

1. Idle timeout disconnects live sessions, and they never re-register

2. Duplicate registration for the same session

Environment

Related Claude Code issues

Browse by topic