Stale Remote Control pairings (800+) truncate cross-session reachability scan

Summary

Bug: Remote Control pairing records are never expired or pruned, so hundreds accumulate over
time (800+ observed) almost all tagged offline. The cross-session ListAgents/SendMessage
reachability scan walks this entire backlog and truncates ("session list too long to check
completely") before reaching genuinely live CLI sessions, causing SendMessage to fail against a
session that is live and running right now.

Expected behavior

A stale/offline Remote Control pairing should either be expired server-side after some reasonable
period of inactivity, or at minimum be skipped cheaply by the ListAgents/SendMessage
reachability scan so it cannot crowd out real, live, currently-running sessions from the same
bounded scan.

Actual behavior

Two independent Claude Code CLI sessions on two different machines, coordinating via the built-in
ListAgents/SendMessage tools, both hit the same failure mode on the same day:

1. A session on macOS attempted SendMessage to a named live session on a Linux machine. It

failed cleanly, twice in a row: No agent named '<target>' is reachable... session list too
long to check completely. The target session was genuinely live and actively working at the
time.

1. The Linux-side session's own ListAgents call the same day returned 786 peer sessions total —

5 genuinely live, named, interactive sessions, followed by a long tail of auto-generated
adjective-noun-named entries all tagged Remote Control / offline (output truncated by the
harness itself for size, well past 780 stale entries). A separate reading the previous day
recorded 838 peer sessions, 837 tagged Remote Control, 830 offline.

1. A SendMessage call from the Linux-side session to another live named session succeeded,

but the tool's own result carried an explicit caveat: "your session list was too long to check
completely, so a same-named session beyond what was searched would not have been seen" — i.e.
even a nominally successful call silently under-scans and could miss a real match.

Minimal reproduction

1. Accumulate Remote Control pairings over time by using Remote Control (mobile/desktop pairing)

normally across many session launches — no special action needed, this happens by default as
part of ordinary use.

1. From any Claude Code CLI session, call ListAgents or attempt SendMessage to another

genuinely live, named peer session once enough stale pairings have accumulated (roughly
several hundred, based on this report's data).

1. Observed: ListAgents truncates its own output for size well before listing every live

session distinctly, and SendMessage either fails outright ("session list too long to check
completely") or succeeds with an explicit under-scan caveat, against a target that is
genuinely live and reachable.

Environment

• Product and version: Claude Code CLI 2.1.248
• OS and version: Fedora Linux 44 (Workstation Edition), kernel 7.1.8-200.fc44, x86_64 (primary

report); corroborating repro from a second session on macOS, exact build not captured

• Model / resolved model ID: Not model-specific — this is a session/reachability-registry defect,

independent of the active model.

• Runtime context: Long-lived interactive terminal CLI sessions (tmux-managed), coordinating

cross-machine via the built-in ListAgents/SendMessage tools.

• Authentication/provider path: Claude subscription (OAuth), interactive CLI, on both machines.

Diagnostics

ListAgents output on the affected session (sanitized — auto-generated pairing names shown as a
representative sample, not exhaustive):

Peer sessions (786):
  <5 genuinely live, named, interactive sessions>
  <machine-name>-<adjective>-<noun>  ·  Remote Control  ·  offline
  <machine-name>-<adjective>-<noun>  ·  Remote Control  ·  offline
  ... (output truncated by the harness itself for size; well over 780 further entries in this
  same shape)

Every truncated entry follows the identical <machine-name>-<adjective>-<noun> naming pattern
Remote Control's own UI uses for paired devices — confirming these are native Remote Control
pairing records, not anything from third-party CLI tooling.

Regression and controls

• Fresh process/session: Reproduces — observed independently on two different sessions, two

different machines, same day.

• Last known good version: Unknown — this appears to be a long-standing accumulation (830+

entries implies many months/launches of unpruned growth), not a recent regression.

• Relevant control: A SendMessage to a session with a distinctive enough name still succeeded in

one case, but only with an explicit under-scan caveat attached to the result — the underlying
incomplete-scan defect is present even on the "success" path, not only the outright-failure
path.

Hypothesis

The Remote Control pairing list is server-side and re-fetched fresh on each launch (independently
confirmed by #73675 — local cache/storage deletion has no effect), and appears to have no
server-side expiry for an offline pairing. Separately, the ListAgents/SendMessage
reachability scan that walks this list for cross-session-messaging purposes appears to have a
bounded budget (time, count, or output size) that it exhausts iterating dead entries in whatever
order the server returns them, rather than either deprioritizing already-offline-tagged entries
or paginating/filtering them out before consuming that budget. Fixing either half (server-side
expiry, or a cheaper live-first scan order) would resolve the cross-session-messaging symptom;
fixing both would also resolve #73675's UI-clutter symptom.

Related public reports

1. https://github.com/anthropics/claude-code/issues/73675 — "Ghost remote sessions persist in

'Remote Control' panel with no way to dismiss them." Same root defect (server-side pairing
records with no expiry, confirmed not stored/removable client-side) at a much smaller scale (2
entries) and a different consequence (UI panel clutter, no dismiss control) rather than a
functional break in cross-session tooling. This report is the same underlying defect
generalized to scale, plus a second, distinct contributing defect in the reachability scan
itself.

1. https://github.com/anthropics/claude-code/issues/89882 — "Long-running multi-session

coordination: peer identity/reachability via ListAgents degrades after idle gaps." Related
symptom family (reachability degradation under ListAgents) but a different specific trigger
(idle gaps rather than pairing-list volume) — cited as a plausible sibling mechanism, not
verified to be the same root cause.

1. https://github.com/anthropics/claude-code/issues/87154 — "Cross-machine session directory

never populates: ListAgents shows only local sessions despite both machines being
RC-connected." A related but distinct symptom (under-population rather than truncation by
volume) in the same general area of cross-machine session-directory reachability.