Recents does not distinguish remote from local sessions (P0); causes silent delete and no-op model picker

Title

Recents does not distinguish remote from local sessions (P0) — leads to silent/asymmetric delete and no-op model picker

Summary

The Recent sessions list renders local sessions and remote-control sessions in a
single, undifferentiated bucket with no icon, badge, label, or grouping to tell them
apart. This single missing signal is the root cause of two further bugs (a silent,
asymmetric delete and a no-op remote model picker). The differentiation fix is the
keystone: until the user can tell which kind of session a row represents, every action
taken on that row is ambiguous.

Severity / sequencing

• P0 — Distinguish remote vs. local sessions in Recents. Ship independently. This is

the precondition that makes every other session action legible.

• P1 (depends on P0) — Make delete semantics explicit and symmetric.
• P1 (depends on P0) — Make the remote model picker drive the session or clearly no-op.

Environment

• Surface: claude.ai/code Recent sessions list
• Session type: remote-control session attached to a local Claude Code instance
• Not model-specific (observed on Opus 4.8 1M context)

P0 — Reproduction

1. Create several local Claude Code sessions.
2. Start (or have running) a remote-control session attaching the browser to a local

instance.

1. Open the Recent sessions list.
2. Observe: there is no way whatsoever to tell a local session from a remote session.

They are visually identical — no glyph, badge, color, or section heading.

Expected

Remote and local sessions are immediately distinguishable at a glance (icon/badge and/or
separate grouping), so the user can reason about what any action on a row will do.

Actual

Local and remote sessions are pixel-for-pixel indistinguishable. With multiple local
sessions plus a remote session in the list, the user cannot identify which row is the
remote connection.

P1 (dependent) — Silent, asymmetric delete

Deleting a remote session from Recents removes the row but has no effect on the
remote/source-of-truth side — the underlying session is untouched and simply vanishes
from view. Because of the P0 gap, the user can't even tell they were deleting a remote
session in the first place.

Remediation: Either tear the session down on both sides, or relabel to
"Remove from Recents" and reflect the change on the source-of-truth side, with a
confirmation that names the consequence (e.g. "This will end the remote session on
<host>").

P1 (dependent) — Remote model picker is a silent no-op

Switching the model on the remote side does not drive the attached local session (the
local instance is the source of truth), and there is no feedback that the change was a
no-op or deferred to the next session boundary. A model change only takes effect at a
session/turn boundary (e.g. after a reconnect), never on a response already in flight.

Remediation: Have the remote picker drive the live session, or disable it / label it
"reflects local session" with feedback when a change is deferred.

Why P0 first

The delete and model-picker bugs are only dangerous because of the P0 gap:

• The silent delete is a trap only because the user can't tell the row is remote.
• The model-picker no-op is confusing only because the user can't tell the picker is

attached to a remote session whose model lives elsewhere.

Fix the differentiation and the remaining two degrade from "actively misleading" to
"minor rough edges." All three share one root cause: the remote-control surface presents
controls and rows that imply parity with local sessions without actually distinguishing or
acting on them.