SendMessage rejects a background session's launch id after the session auto-renames itself, while claude logs/claude stop/agents --json still accept it

Environment

• Claude Code 2.1.241 on both the sending and receiving side (macOS, Darwin 25.5.0)
• Both sessions started with claude --bg
• Verified 2026-08-23

A first run of this had the sender on 2.1.234 and the receiver on 2.1.241. It was re-run with both sides on 2.1.241 to remove the version mismatch; the result was identical, so the behavior is not a cross-version artifact.

What happens

Launching a background session prints an id and suggests commands built from it:

backgrounded · 0a2fe69c (idle — send a prompt to start)
  claude attach 0a2fe69c    open in this terminal
  claude logs 0a2fe69c      show recent output
  claude stop 0a2fe69c      stop this session

Once the session receives its first task it renames itself from the task's subject. After that rename, the launch id is still accepted everywhere except SendMessage:

| Using the launch id 0a2fe69c after the rename | Result |
|---|---|
| claude logs 0a2fe69c | works |
| claude stop 0a2fe69c | works |
| claude agents --json → the session's id field | still reports 0a2fe69c |
| ListAgents peer row | inter-session messaging test [582764] · says it was 0a2fe69c until 49s ago |
| SendMessage to "0a2fe69c" | fails |
| SendMessage to "inter-session messaging test" | works |

Verbatim failure:

No agent named '0a2fe69c' is reachable.
Use ListAgents to see everyone you can message.

Reproduction

1. cd <any project> && claude --bg — note the printed id, call it $ID.
2. From another session, SendMessage to $ID with any task. This succeeds (the session has not renamed yet).
3. Wait for the session to process the task; it renames itself from the task subject.
4. SendMessage to $ID again → fails with the error above.
5. SendMessage to the new display name → succeeds.
6. claude logs $ID and claude stop $ID → both still work.

Negative control — the rename is the sole cause

A separate background session was driven into a blocked state (status: waiting, waitingFor: permission prompt, state: blocked) by asking it to read a file outside its working directory. Because it blocked before producing any output, it never renamed itself — claude agents --json still showed "name": "7c548a4c", identical to its launch id.

SendMessage to 7c548a4c in that state succeeded.

So being blocked does not make a session unreachable, and reachability does not depend on session state. The only variable that changes the outcome is whether the session has renamed itself. This also explains why the first message to a fresh background session always works: the session has not yet renamed, so its id is still its name.

Within-subject before/after on a single session

That same session was then unblocked: claude attach 7c548a4c rendered the pending permission dialog, and pressing Esc cancelled it. (Only cancellation was exercised — an affirmative approval was not tested.) The session then drained the message queued during the block, replied, returned to background, and in doing so renamed itself to cross-session diagnostic request. Messaging the identical address again:

SendMessage to "7c548a4c"  →  No agent named '7c548a4c' is reachable.

Same session, same process, same build, same address string — reachable before the rename, rejected after it. Nothing else changed between the two measurements.

Expected

Either the launch id keeps working as an alias for the session's lifetime, or the failure says the session was renamed and gives the current name — rather than reporting it as unreachable.

Why this matters

The error states the session is not reachable, but the session is alive and working. Anything that launches a background session, captures the id, and messages it later hits this on the second message, and the error points away from the real cause. ListAgents displaying says it was 0a2fe69c until 49s ago makes the id look like a usable address when it is not.

The rename appears to replace the id-as-name rather than aliasing it. A session observed its own name change from b6deec9a to cross-session addressing verification mid-run, keeping the same ref [11cf54], and ListAgents reported its own addressable name accordingly before and after.

Relationship to existing issues — believed distinct

• #88846 (/rename does not propagate to how the session appears in ListAgents on peer sessions): the reported symptom is peers seeing the stale name. Here the peer listing updated promptly and correctly, with an explicit bridge annotation. The failure is in the addressing layer, not the display layer.
• #88193 (background sessions: resume-by-id fails, four sessions share one name): concerns claude --resume and name collisions. resume was not tested here; this is specifically SendMessage rejecting an id that other surfaces accept.

If maintainers consider this the same root cause as either, it can be folded in — the reproduction above should still be useful, since it is on 2.1.241 and isolates the addressing layer from the display layer.

Not verified

• claude attach $ID and claude --resume $ID with the stale id were not tested; the "still works" column covers only logs, stop and the agents --json id field.
• Whether an explicitly user-set name (--name, /rename) behaves the same as an automatic rename.