Cross-session messaging: peer addresses die silently on every process restart — stable session IDs already exist, use them for addressing

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

Claude Code sessions on the same machine can message each other (ListAgents / SendMessage), which enables powerful multi-agent setups: in our case one long-lived "supervisor" session coordinating 3-5 worker sessions across four repositories.

The addressing layer undermines this. Peers are addressed by an auto-generated name (derived from the working directory plus a rotating suffix, e.g. myrepo-4f) backed by a per-process pipe. Both the name and the pipe die on every process restart: machine reboot, closing/reopening the terminal window, app update — even context compaction has rotated the address in our experience. The failure is silent on both sides: the counterpart only discovers the link is dead when its next send bounces ("No agent named X is reachable"), and any report composed against the dead link is lost from the sender's perspective.

Meanwhile a stable identifier already exists: every session has a persistent session GUID (visible in transcript file paths) that survives restarts and --resume. It is simply not usable as a messaging address.

Proposed Solution

Make the persistent session GUID the durable messaging address:

• SendMessage(to: <session-guid>) resolves at delivery time to the session's current live process; if the session is not running, fail explicitly (or

queue until resume).

• ListAgents lists the stable GUID alongside the display name; names remain human-friendly aliases.
• A session's own stable ID should be visible to itself, so it can hand out a durable address proactively.

This would turn every "the agents lost you" incident into a non-event: the address printed once in a handshake would remain valid for the life of the chat, exactly like the transcript it belongs to.

Alternative Solutions

_No response_

Priority

Low - Nice to have

Feature Category

Other

Use Case Example

1. Session A (supervisor) sends a message to session B; B stores A's reply address ("From" link).
2. Restart session A's process (close/reopen the window, or reboot).
3. B replies to the stored address: the send fails. Nothing notified either side in between.
4. A's name in ListAgents has also rotated, so B cannot re-derive the address without human mediation.

Additional Context

Impact (measured over a 3-day engagement)

• ~6 address rotations, each requiring a human to notice ("the agents lost you"), relay the fact, and the supervisor to re-handshake every active

session with identity-guarded messages.

• Worker reports composed against dead links bounced and had to be resent.
• Broadcast re-handshakes are not an acceptable mitigation when many parked sessions exist: a message wakes a session, so re-linking must stay targeted.