Same session appears under three independently-generated names, breaking identification and cross-session addressing

Summary

A single Claude Code session is named independently by at least three subsystems, so the same session carries different names at the same moment. Users cannot tell whether two entries refer to the same session, and ListAgents / SendMessage addressing breaks.

Environment

• Claude Code Desktop 2.1.241
• macOS host, using the built-in SSH to run sessions on a Linux VM (Ubuntu 26.04, aarch64)
• Sessions on both hosts; Remote Control enabled globally

Note: session titles are auto-generated, and mine were generated in Korean. They are translated below, preserving the property that matters — same meaning, different wording.

Observations

1. Three names for one session, simultaneously. All three refer to sessionId 16d7d8a4-…, verified against ~/.claude/sessions/<pid>.json.

| Surface | Name shown |
|---|---|
| Desktop sidebar | "Loading the PDF reading skill" |
| Mobile app session list | "PDF file loading and plugin setup" |
| ListAgents, interactive row | docs-10 |

2. The derived name changes on every process restart. The same session was listed as docs-10, then docs-65, then docs-25 across two process restarts. sessionId was unchanged throughout, so this is one session with three names over a few minutes.

3. Derived names collide. Two distinct sessions were both listed as tas-20; only the [ref] suffix distinguished them.

4. A second instance of the same pattern. Another session appeared as "Worktree workflow guide" in the desktop sidebar and "Worktree workflow instructions" in the mobile list. Semantically identical, different wording — consistent with independent summarization rather than a stale or truncated title.

Impact

• Users cannot locate a session seen on mobile in the desktop sidebar. With many sessions open this makes Remote Control hard to use: you know the session exists, but not which row it is.
• Agents. SendMessage to a name that has since changed returns No agent named '…' is reachable. That message reads as "this peer cannot receive messages" rather than "your name is stale". While investigating cross-session messaging I misdiagnosed exactly this — I concluded that Remote Control peers were unreachable, and only found otherwise by re-running ListAgents and retrying with the refreshed name, which succeeded immediately.
• Determining which running process belongs to which session currently needs an out-of-band workaround: match the recently modified transcript under ~/.claude/projects/ and look its UUID up as sessionId in ~/.claude/sessions/<pid>.json.

Expected

Any one of these would resolve it:

• a stable identifier surfaced next to the name on every surface, so two entries can be compared;
• one canonical title synchronized across surfaces, plus a session-scoped rather than process-scoped name in ListAgents;
• at minimum, an error message that distinguishes "no such name" from "peer is offline", so a stale name is not mistaken for an unreachable peer.