No shared identifier between a session's identity (ListAgents/SendMessage name) and its title (what the UI actually shows)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

A session has two separate names that never meet: an identity (ListAgents/SendMessage name, e.g. blocking-7a) and a title (the human-facing label shown in a UI — a VS Code session list, a claude.ai task list entry, defaulting to "untitled" + machine name). The UI only ever shows title; cross-session tooling only ever shows identity. There's no way to look up one from the other.

Concretely: coordinating work in a VS Code extension session, ListAgents showed two peer sessions (blocking-fe, blocking-7a) active in the same repo. Neither was findable as a VS Code window. Resolving what they actually were required manually messaging each one and asking it to self-report — there was no UI path to check. It turned out:

• blocking-fe was real but only visible in claude.ai's task list ("untitled" + machine name) — nothing tied that entry back to the identity blocking-fe.
• blocking-7a was an identity that had been reused: a session by that name had done real work and was deleted, and a different, unrelated live session had since taken the same identity. When messaged, it described the deleted session's work in the first person, with nothing in its identity or title to indicate the name had been reassigned.

Net effect: a user has no reliable way to audit "what's actually running against my repo right now" without treating every peer's self-report as unverified.

Proposed Solution

Minimal fix: a tooltip on the title in any session/task list UI (VS Code, claude.ai) showing the underlying identity string, and conversely surfacing the title alongside identity in ListAgents, so the two can be correlated directly instead of by asking a peer "are you agent blocking-7a?" and waiting for it to self-report.

Also worth considering: whether identities should stay unique for the life of the session data (never reused after deletion) so a resolved name always points to the same session instance — or if reuse is intentional, surface an explicit "this identity was reassigned" signal.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_