[BUG] ListAgents lists dead sessions as "idle" and SendMessage to them returns success

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

`ListAgents` listed a peer session as `Remote Control · idle` for over an hour after that session
had ceased to exist. During that time it cycled `idle → running → idle`, accepted sends, and
returned `success: true` for each. Nothing was ever delivered, and nothing in the result
indicated the target was gone.

The `SendMessage` tool documentation states:

> A listed peer is alive and will process your message.

In this environment that does not hold, and there is no signal distinguishing a live peer from a
dead listing.

What happened: a peer named `MRX.Trader-Dev01_gate-Tester [69517c]` appeared in Machine A's
`ListAgents` output. Machine B — the machine that session had run on — reported at the same
moment that no session by that name, or by that ref, existed on its side under any name.

Three sends were attempted from Machine A:

| Attempt | Result |
|---|---|
| 1, with `notify_when_idle: true` | `success: false` — correctly refused for an unrelated reason (not supported cross-machine), and explicitly stated the message was not delivered |
| 2, same address, option removed | `success: true` — `"→ MRX.Trader-Dev01_gate-Tester (a Claude session on another machine, over Remote Control)"` |
| 3, sent after the row flipped to `running` | `success: true` — same |

Nothing arrived at any live session. The row was still listed, still labelled `idle`, more than
an hour later.

The `running` transition is the part I cannot account for: it suggests something was actively
updating the state of a row with no session behind it, rather than a value simply left stale.

This is the most damaging of the failure modes I hit while testing cross-session messaging,
because every other one announced itself.

### What Should Happen?

A listing should not report `idle` for a row with no live session behind it. `offline`, or
removing the row, would let a sender act on it.

And `success` should not be returned where delivery is unverified. The tool already does this
correctly for one address form: sending to a **bridge id** returns

accepted by the server for that session, but delivery is not confirmed: it has not
reported that it can receive cross-session messages and may be on an older version
that cannot

while sending to a **name from `ListAgents`** returns a bare `success: true` with no caveat. That
caveat also disappears once the target has demonstrated it can receive, so it tracks real state
rather than being boilerplate. Extending it to name-addressed sends would remove the false
confidence entirely.

### Error Messages/Logs

```shell
# There is no error. That is the bug.

# ListAgents on Machine A, more than an hour after the session had ceased to exist:
MRX.Trader-Dev01_gate-Tester [69517c] · Remote Control · idle

# SendMessage to that row:
{"success":true,"message":"\u201ccross-machine channel test\u201d \u2192 MRX.Trader-Dev01_gate-Tester (a Claude session on another machine, over Remote Control)","msg_id":"1acc1c8c-1458-4062-85fb-4427fc2af152"}

# For contrast, the same tool sending to a bridge id DOES warn:
{"success":true,"message":"... accepted by the server for that session, but delivery is not confirmed: it has not reported that it can receive cross-session messages and may be on an older version that cannot"}
```

### Steps to Reproduce

1. On machine 1, from session A, run `ListAgents` and note a Remote Control peer running on
machine 2.
2. End that session on machine 2. (In my case the Claude Desktop app restarted, which also
renamed the session — its name changed three times in one morning.)
3. From session A, run `ListAgents` again.
Actual: the old row is still listed, and still shows `idle`.
4. `SendMessage` to that row's name.
Expected: an error, or a delivery caveat.
Actual: `success: true`, with nothing indicating the target no longer exists.
5. Confirm on machine 2 that no session received it.

I only discovered the failure because the operator of the other machine told me, out of band,
that nothing had arrived.

### Claude Model

Opus

### Is this a regression?

No, this never worked

### Last Working Version

_No response_

### Claude Code Version

Windows, Claude Desktop 1.52386.3.0 (MSIX, sideloaded from claude.com), CCD 2.1.266

### Platform

Other

### Operating System

Windows

### Terminal/Shell

Windows Terminal

### Additional Information

**Reproduced on the current build, not a stale one.** Both machines run Claude Desktop
1.52386.3.0 with CCD 2.1.266. Seen from Desktop-hosted sessions and from a terminal session
alike.

| | Machine A | Machine B |
|---|---|---|
| Host | Windows 10 Pro 19045 | Windows 10 Education 19045 |
| Claude Desktop | 1.52386.3.0 | 1.52386.3.0 |
| Claude Code CLI | 2.1.266 | 2.1.266 |

**A related observation: refs appear to be observer-scoped.** At one moment, one live session was
seen differently from the two machines:

| Observer | Row |
|---|---|
| Machine A | `MRX.Trader-Gate_gate-Tester` **[58ad10]** · `interactive` |
| Machine B | `MRX.Trader-Gate_gate-Tester` **[39d1d9]** · `Remote Control` · `idle` |

Same name, same instant, different ref and different transport label. If refs are view-local
handles rather than identifiers, they cannot be exchanged between sessions even while both are
live — and a listing carrying a row with no counterpart in any other view is the degenerate case
of that same property. The tool documentation invites sessions to pass refs to each other, which
on this reading cannot work.

I also saw one name occupied by five separate rows in a single listing (`Mirentix-Gate` ×5), only
one of which was reachable, which makes a bare name unusable as a cross-machine address.

**Why this matters for handoff workflows.** Silence from the other side is indistinguishable
between three cases: the peer is working on it, the peer received it and did not reply, or the
address was dead and nothing was delivered. Since `success: true` is returned in the third case,
the sender cannot tell which.

**Suggested fixes**

1. Do not report `idle` for a listing with no live session behind it.
2. Extend the delivery caveat already returned for bridge addresses to name-addressed sends.
3. If refs are view-local, say so in the tool documentation.

Start from the ListAgents and SendMessage tool paths mentioned in the report, using the two-machine Windows reproduction with Claude Desktop 1.52386.3.0 and CCD 2.1.266. Trace how Remote Control peers, names, refs, and delivery confirmation are represented. Done means dead peers are not shown as idle, or name-addressed sends return an error or delivery caveat instead of bare success.

Vom Indexierungsmodell aus dem Issue-Text verfasst.