[Desktop] Governor eviction silently drops a session from cross-session messaging; on resume it re-registers under a different name and ref

Environment

• Claude Desktop 2.110.0 (macOS), embedded Claude Code 2.1.271
• Several local Code-tab sessions open at the same time (memory-pressure evictions are routine on this machine)

What happened

1. Session A (title set in the desktop sidebar since the morning) ran ListAgents at 22:37 local time. It reported: This session is tmp-52 [41dcb0]. So the peer name was an auto-generated one, not the desktop title.
2. Session A spawned several sessions with spawn_task. It expected to be reachable by them via SendMessage.
3. Main log, 11 minutes after A's last turn:

``
22:49:08 [CliGovernor] pressure evicting local_7bebc33c-… (idle 286s)
22:49:08 [CCD] Pausing session local_7bebc33c-… (governor_evict)
22:49:09 Session local_7bebc33c-… query iterator completed
``

1. For the next 9.5 hours A had no process, so it had no inbox socket. It was absent from every peer's ListAgents. The sidebar still showed it as an ordinary open session.
2. When the user typed in A the next morning, the app logged Resuming session local_7bebc33c-… and started a new process. ListAgents then reported This session is <desktop title> [6915af]. The name and the ref had both changed. The session ID, the transcript and the conversation were unchanged.

Why it matters

• SendMessage addresses the process, not the session. A peer that saved A's name or ref, or was told it in a brief, cannot reach A once A is evicted. After A resumes, the saved name is also wrong. Nothing tells either side.
• notify_when_idle in either direction dies with the evicted process. The docs promise a 12-hour expiry notice for a subscription that never fires. When the subscriber itself is evicted, there is no process left to receive that notice.
• The desktop channel handles the same case well. mcp__ccd_session_mgmt__send_message with the local_… session ID wakes an evicted session and starts a turn. It queues the message when the target is busy. We verified both today. get_session("self").parentSessionId also gives a spawned session a stable pointer to its parent. The two messaging surfaces therefore behave very differently for the same target.
• The peer name is inconsistent. The first start used an auto-generated name, the resume used the desktop title.

Expected

Pick one of these, in order of preference:

1. SendMessage to a paused (evicted) desktop session routes through the app and resumes it, as ccd_session_mgmt.send_message already does. ListAgents lists such sessions as paused, similar to how offline is shown for Remote Control sessions.
2. At minimum:

• A desktop session gets the same peer name on first start and on resume, preferably its sidebar title.
• The cross-session-messaging docs say that desktop sessions can be evicted and are then unreachable by name.
• The docs point to the session-ID channel as the durable option.

Related

• #82663 (CliGovernor hard cap)
• #85160 (SendMessage: accept a session ID as address; closed as stale)
• #71773 (parent observes spawned children; closed as stale, now partly covered by parentSessionId)