[BUG] A session cannot identify itself: ListAgents does not mark the current session's row, and no surface exposes its own name or address

Preflight Checklist

• [x] I have searched existing issues 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?

A session has no supported way to learn its own name or peer address. ListAgents returns peers only and marks nothing as the caller, and no other tool or prompt field reports it either.

The identity does exist, it is just never surfaced. A Bash call inherits CLAUDE_PID and CLAUDE_CODE_MESSAGING_SOCKET, and ~/.claude/sessions/$CLAUDE_PID.json holds the display name that SendMessage wrappers carry. Nothing points at either, so a session asked "what name do other sessions use for you?" falls back to forensics or to interrupting a peer. That is how this report started: a peer messaged me to ask what from-name its own messages carry, and answering it took a third session reading the attribute off the wrapper. My own address took a /proc walk from a Bash call up to my parent claude pid, matched against the socket filenames, which is Linux-specific and still does not give the name.

What Should Happen?

Mark the current session's row in ListAgents, or name the socket variable and the registry path where an agent will read them: in the ListAgents and SendMessage descriptions, or in the environment block of the system prompt next to cwd and model.

Workaround

Read the registry entry from a Bash call:

cat ~/.claude/sessions/$CLAUDE_PID.json

name is what peers pass to SendMessage, messagingSocketPath is the address. I wrapped that in a /whoami slash command, with a /proc walk up to the owning claude process as a fallback for builds that do not export CLAUDE_PID. It also warns when another live session shares the name, since the bare name is then ambiguous and needs its [ref].

Error Messages/Logs

# ListAgents from this session, whose name is httrack-windows-e0: 7 peer rows, no self.
# httrack-windows-6b is a different session in the same cwd, so cwd identifies nothing.
  httrack-com-d6 [889edb]        ·  interactive  ·  idle  ·  started 3d ago
  httrack-9e [ce1bf0]            ·  interactive  ·  busy  ·  started 3d ago
  httrack-android-a5 [d942b6]    ·  interactive  ·  idle  ·  started 3d ago
  httrack-fc [e2f33b]            ·  interactive  ·  shell ·  started 3d ago
  httrack-windows-6b [33ea23]    ·  interactive  ·  idle  ·  started 3d ago
  httrack-e5 [6ac58a]            ·  interactive  ·  busy  ·  started 2d ago
  coucal-7e [b674d5]             ·  interactive  ·  idle  ·  started 2d ago

# Yet a Bash call already inherits the pointers, and the registry holds the name:
CLAUDE_PID=3965644
CLAUDE_CODE_MESSAGING_SOCKET=/run/user/1000/cc-socks/3965644.sock

$ cat ~/.claude/sessions/3965644.json
{"pid":3965644,"cwd":"/home/roche/git/httrack-windows","kind":"interactive",
 "messagingSocketPath":"/run/user/1000/cc-socks/3965644.sock",
 "name":"httrack-windows-e0","nameSource":"derived","status":"busy"}

Steps to Reproduce

1. Start two interactive sessions on one machine with cross-session messaging enabled, A and B.
2. In A, ask: "what name and address do other sessions use to reach you?"
3. A runs ListAgents, gets peer rows only, and has nothing else to go on. Its only route is to message B and ask B to read the from-name off the wrapper it just received.

Claude Model

Opus

Is this a regression?

No, this never worked

Claude Code Version

2.1.227 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other (GNU screen, bash)

Additional Information

The workaround above holds from the user side, but finding it took reverse engineering, which is the part worth fixing.

Related issues, all about addressing other sessions rather than knowing yourself: #84894 (display names dropped by ListAgents, rejected by SendMessage), #85160 (session IDs in ListAgents and as a SendMessage address), #84768 (a recipient cannot resolve the sender to reply), and #85690 (sending to your own address succeeds silently, so an agent that could recognise its own row would not self-address by accident).