Agent-to-agent messaging is fragmented across surfaces; ask for one addressing scheme and one transport

The individual pieces work. What is missing is that they form one network. Today, whether two Claude agents can talk depends on which surface each was started from, and the user has to know the whole matrix in advance to plan any multi-agent work. The practical consequence is that context has to be carried by hand between agents that are all running on the same machine, under the same account, at the same time.

## Measured on one machine, one account, 2026-09-04

Windows 10 Pro 19045, Claude Code v2.1.258, Opus 5, Claude Pro; desktop app plus CLI sessions plus SSH sessions to four Linux hosts.

| From → To | Works |
|---|---|
| CLI session → CLI session | yes |
| CLI session → Remote Control session on another machine | yes, with returned msg_id, target processed and answered |
| CLI session → Desktop app Code tab | yes, arrives as a `cross-session-message` block over `\\.\pipe\LOCAL\cc-msg-…` |
| Desktop app Code tab → anywhere | no — `SendMessage` is unavailable (see #92016) |
| Lead agent → its own running subagent | no — same restriction |
| `ccd_session_mgmt.send_message` → desktop session | delivers, but an idle target does not act until a human opens it |
| `ccd_session_mgmt.send_message` → CLI session | no — CLI sessions never appear in `list_sessions`, not even with `CLAUDE_CODE_FORCE_SESSION_PERSISTENCE=1` |
| `ListAgents` | lists 17 peers across all of the above, and names `SendMessage` as the way to reach them |

Note the asymmetry in row 3 against row 4: the desktop Code tab **receives** peer messages and appears in other sessions' agent lists as addressable, while it cannot send anything. Other sessions message it and wait for a reply that cannot come. That is worse than not participating in the peer network at all.

Note also that discovery and delivery disagree: `ListAgents` sees sessions that `ccd_session_mgmt.list_sessions` does not, and the short ids `ListAgents` prints are not accepted by the only send tool that is available (`Session not found`). And the ids from one namespace are not valid in the other.

## What is being asked for

1. **One addressing scheme.** An agent id that is valid regardless of where the agent was started — desktop tab, CLI, SDK, remote, cloud — and accepted by whatever send tool the session has.
2. **One transport, available on every surface.** If a surface must restrict outgoing messages, it should also not be discoverable as a target, so peers do not address something that cannot answer.
3. **Discovery and delivery over the same namespace.** Whatever a listing tool returns should be addressable by the send tool in the same session.
4. **Subagents reachable like peers.** A parent that spawns a subagent should be able to hand it a correction, not only read its final report.

## Why this matters in practice — three failures from a single working day, all on one machine

- A build subagent spent several minutes diagnosing "something external is power-cycling this machine". It was the lead agent and the user, performing a planned hardware change. Nobody could tell it.
- The same subagent later described the lead agent's own process as "an independent second agent" and cited it as independent confirmation of its own build.
- Two subagents collided on the same TCP port because the lead could not tell the second one that the first had it.

None of these needed clever tooling to avoid. They needed one sentence delivered to a running agent.

## Workarounds that exist and why they are not a substitute

Reading subagent transcripts from `~/.claude/projects///subagents/agent-.jsonl` gives visibility but is one-way; `tmux send-keys` over SSH gives a full back-channel but only for agents deliberately placed on a POSIX host; named pipes deliver but are not scanned for discovery (see #89658). Each of these covers a different subset, so the user ends up maintaining a mental matrix of which agent can reach which.

## Reference

#92016 (desktop Code tab auto-denies SendMessage), #89658 (Windows MSIX peer discovery does not scan `\\.\pipe\LOCAL\`), #90481 (`ListAgents` unavailable in the VS Code extension), and #35240, closed as completed on 2026-07-01 with #28048, #56449, #48160 and #42737 folded in as duplicates. Those are individual surface bugs; this issue is about the absence of a common contract behind them.

Related open issues approaching the same area from a different angle: #91541 (a proposed durable file-backed cross-runtime protocol) and #28300 (cross-machine agent-to-agent protocol). Both propose a transport; this issue is about the addressing and discovery contract that any transport would need to share.

Start by tracing the existing ListAgents, SendMessage, and ccd_session_mgmt discovery and delivery paths across desktop, CLI, and subagent sessions, using the behavior matrix and linked issues #92016, #89658, and #90481 as cases. Compare these with the one-way transcript path at ~/.claude/projects///subagents/agent-.jsonl. Done means discoverable agents use one address namespace and transport, including reachable subagents, or non-send-capable surfaces are excluded.

Rédigé par le modèle d'indexation à partir du texte de l'issue.