[BUG] --name is not applied to the peer registry on 2.1.261; new sessions register under another session's generated title

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On 2.1.261, claude --name <name> no longer sets the name a session registers for cross-session messaging. The session's ~/.claude/sessions/<pid>.json entry is written with nameSource: "auto" and a name that is an AI-generated title copied from a different, unrelated session, about 100 ms after launch and before any prompt is sent. The transcript records the --name value as a custom-title line, but the peer registry, ListAgents, and the prompt-bar title all show the foreign generated title instead.

Because every new session on the machine picks up the same inherited title, many live sessions end up sharing one name. Scripts and hooks that hand a session a peer name to SendMessage (the documented convention, "a session answers to the name you set with --name") then address an ambiguous name, and the message lands on whichever session the sender's [ref] happens to pick.

Observed on one machine at the time of writing: seven live sessions across four different working directories, including three fresh scratch sessions launched with --name dup4cc4, all registered as the same generated title with nameSource: "auto". The string is not present in any file under ~/.claude other than the sessions/*.json entries and the transcripts, so it appears to be carried in a running process rather than read from disk.

Related but distinct: #91054 covers collisions between nameSource: derived default display names. This report is about an explicit --name being discarded and replaced by a generated title that belongs to another session.

What Should Happen?

Per the sessions and cross-session-messaging docs, --name should set the session name, replace any generated title, and be the name other sessions use to address it. A fresh session should never register under a title generated for a different session. If a collision must happen, the dedup rename to a two-word variant should apply, since this is a name the user set, not an AI-generated title.

Error Messages/Logs

Registry entry of a session launched with --name Hermit (fields trimmed):

{"pid":717713,"startedAt":1788628868046,"version":"2.1.261","kind":"interactive","entrypoint":"cli",
 "name":"Artifact skill trigger instruction passing","nameSource":"auto","nameSince":1788628868147,...}

First lines of the same session's transcript:

{"type":"ai-title","aiTitle":"Artifact skill trigger instruction passing",...}
{"type":"agent-name","agentName":"Artifact skill trigger instruction passing",...}
{"type":"custom-title","customTitle":"Hermit",...}

ListAgents from a peer, showing the collision:

Artifact skill trigger instruction passing [c53456]  ·  bg  ·  busy  ·  started 1h ago
Artifact skill trigger instruction passing [e1c327]  ·  interactive  ·  idle  ·  tmux probe-artifact-hook-a:@3.%3  ·  started 1m ago
Artifact skill trigger instruction passing [8b1593]  ·  interactive  ·  shell  ·  tmux hermit-x:@2.%2  ·  started 1h ago

SendMessage to the bare name after one of them was renamed with /rename:

{"success":false,"message":"No agent named 'Artifact skill trigger instruction passing [60e4ff]' is reachable. Did you mean: Artifact skill trigger instruction passing?"}

Steps to Reproduce

1. Have at least one other Claude Code session running on the machine that has a generated title.
2. In three empty scratch directories, launch claude --model haiku --permission-mode acceptEdits --name dup4cc4 in three separate tmux panes.
3. Before sending any prompt, read ~/.claude/sessions/<pid>.json for each new pid.
4. Observe name is not dup4cc4 but a generated title, nameSource is auto, and all three entries share the same title. The prompt bar in each pane shows that title too.
5. From a fourth session, call ListAgents: the three rows share the name and are distinguishable only by [ref] and tmux address.
6. Send with SendMessage to the bare name: delivery is ambiguous. Send to name [ref]: delivered to the one session with that ref. Rename that session with /rename other, resend to the old name [ref]: refused as unreachable.

Note on step 2: the trust dialog does not appear under --permission-mode, so no interaction is needed before reading the registry.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.251 (the same --name Hermit launch registered as Hermit [5fb191] in ListAgents on 2026-08-31)

Claude Code Version

2.1.261 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other