Remote Control: "unreachable" error omits the peer session / host name

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 12, 2026

What happened

I had a Remote Control peer session titled psyjak hard lock investigation,
hosted on a machine called psyjak. With psyjak powered off, trying to use that
session produced an error to the effect of "it can't reach the computer"
(paraphrased from memory — the exact string may differ, but it named no host
and no session).

Because nothing in the message identified the machine, I had to deduce which
host was meant before I could act on it.

Why this looks like a cheap fix

The name is already available at the point the error is raised. ListAgents
renders the same peer correctly:

psyjak hard lock investigation [b0e48d] · Remote Control · offline

So the session title — and by extension the host — is in hand. It simply is not
interpolated into the error.

Expected

An error that names the peer, e.g.:

psyjak is unreachable — the Remote Control session
"psyjak hard lock investigation" is offline.

Impact

Larger than it first appears for anyone running several machines. With multiple
peers, "the computer" gives no way to tell which one is down without a separate
investigation.

In my case the session existed specifically to investigate hard locks on the
machine hosting it — so "offline" was itself the diagnostic signal, and the
message withheld the one detail that would have made it meaningful.

Environment

  • Claude desktop app 1.52386.3 (Code tab)
  • Host: macOS, Darwin 24.6.0
  • Peer: Windows 11, reached via Remote Control, powered off at the time

Suggested fix

Interpolate the peer's session title and/or host name into unreachable/offline
errors for Remote Control sessions.

View original on GitHub ↗