Local-only sessions are auto-registered with cloud Remote Control, so a dead local process reports as computer_unreachable

Status Open
Reported on v2.1.246
Maintainer reply None cached
Activity 4 comments · opened Aug 31, 2026

Split out of anthropics/claude-code#90172, which reports eight interconnected defects arising from
one root cause: the desktop app restarts itself to apply an update and destroys the running Claude
Code sessions. That issue holds the shared context and the manual recovery addendum. This is
defect 8 of eight.

Product: Claude Desktop (Claude Code desktop app)
App version: 1.37937.3 (bundled CLI 2.1.246)
Platform: Windows 11 Pro 10.0.26200, x64
Reported: 2026-08-27

The defect

Every local session on this machine is registered with the cloud Remote Control bridge, with no
opt-in step. All five session records carry remoteControlAutoEligible: true and every one was
issued a bridge session:

| Session | remoteControlAutoEligible | bridge session |
|---|---|---|
| Reconciliation bias and stale checkouts | true | session_015SgtBq... |
| Session resume error with popup | true | session_01XoVjgZ... |
| Session message popup method | true | session_013KP2dF... |
| CCD replacement sessions method | true | session_01NSuuWN... |
| Server Startup | true | session_01AkEhFK... |

None of these sessions ever left the machine. There is no second host anywhere in this setup. The
app enables the bridge unconditionally:

2026-08-27 12:04:53 [info] Enabling remote control for session local_<id>-...
2026-08-27 12:04:57 [info] [remote-control] bridge_state: "connected"

Users running only local sessions may not expect each one to be registered with a cloud bridge, and
nothing in the app says it is happening.

It is also how the wrong error message gets chosen

When the local CLI process dies, the app has no local session to route to, so it falls back to the
bridge. The bridge has one vocabulary for a host it cannot reach, so the user is told their computer
is unreachable:

Can't reach your computer It may be asleep or offline. This session will reconnect when it's back. Remote Control host unreachable (computer_unreachable)

That message is false, and it is wrong for cases that involve no restart at all. That half is
filed separately as #90877
, with the measurements: the machine was awake, online, and running the
very app displaying the message, and a --bg session that exited normally after 7.4 seconds
produces the same card.

This issue is about the registration being automatic and invisible. #90877 is about the card and the
message.

Requested

Make Remote Control registration for purely local sessions opt-in, or at least visible.

On the existing opt-out

disableRemoteControl exists as a Claude Code setting:

"Disable Remote Control (claude.ai/code, claude remote-control, --remote-control/--rc, auto-start, and the in-session toggle). Typically set in managed settings."

It is all-or-nothing in the same way as disableAutoUpdates in defect 7 (#90873). Turning it off to
stop local sessions being cloud-registered also removes claude.ai/code entirely. There is no setting
for "local sessions stay local, remote stays available."

The nine defects

Eight were reported together in #90172, because they come from one root cause. The
ninth was carved out of defect 8 once the evidence showed it is reachable with no
restart involved. Each is filed separately so it can be triaged and closed on its own.

| Defect | Issue | What it is |
|---|---|---|
| 1 | #90867 | The update restart kills running sessions. The relaunch restores the window, not the sessions. Core defect. |
| 2 | #90868 | The relaunch does not preserve CLAUDE_CONFIG_DIR, so sessions register into the default config directory. |
| 3 | #90869 | Every installed profile restarts at once, because their update timers stay in lockstep. |
| 4 | #90870 | The restart fires without user action, even with an update banner staged and unactioned. |
| 5 | #90871 | No update policy downloads an update and waits for the user to install it. |
| 6 | #90872 | The restart fires long before the autoUpdaterEnforcementHours deadline. |
| 7 | #90873 | disableAutoUpdates also hides Help > Check for Updates, removing the manual update path. |
| 8 | #90874, this issue | Local sessions are auto-registered with the cloud Remote Control bridge, with no opt-in step. |
| 9 | #90877 | A session card renders as live when no process backs it, and the failure is reported as computer_unreachable. Carved out of defect 8; reachable with no restart involved. |

Shared context, impact, and the manual session-recovery addendum stay on the umbrella
issue #90172. The updater mechanism underneath defects 1 to 7 is filed separately as
#86556: a staged Squirrel build is applied on any relaunch, not only on the
"Relaunch to update" consent gate.

View original on GitHub ↗

3 Comments

wshallwshall · 1 month ago

Still open. Defect 8 of the eight split out of #90172. The narrow fact is that every local session on this machine is registered with the cloud Remote Control bridge with no opt-in step.

All five session records carried remoteControlAutoEligible: true and every one was issued a bridge session. None of those sessions ever left the machine, and there is no second host anywhere in the setup. The app log shows the bridge being enabled unconditionally, then reporting bridge_state: "connected" a few seconds later.

Two reasons this matters separately from the restart cluster it was filed alongside. Users running only local sessions may not expect each one to be registered with a cloud bridge, which is a disclosure question rather than a bug. And it is why a dead local process surfaces as computer_unreachable rather than as a missing process, which is the failure #90877 covers in detail.

wshallwshall · 21 days ago

Still open. #91055, from another user, shows a consequence of this default from the other side. Opening a session created on another machine runs it on that machine, with nothing in the UI saying which host it is on. That is Remote Control working as designed, but it depends on every session being registered with the bridge whether or not the user ever asked for that.

An opt-in step, or at least a visible indicator on sessions that are bridge-registered, would address both reports.

wshallwshall · 13 days ago

Still open. #98480, from another user, reports the desktop app's device bridge dropping on a two-hour cycle on an unattended machine, and it lists this issue among the earlier bridge reports. It may not be the same bridge component as the one in this report, so I am not claiming a shared cause.

The link is the default. If every local session is registered with a cloud bridge without an opt-in, then bridge health becomes something every local session depends on, including sessions that never leave the machine. An opt-in, or a visible indicator on bridge-registered sessions, would still address this report.

Showing cached comments. Read the full discussion on GitHub ↗