[BUG] /rename name survives into the pre-/clear conversation, so peers see the wrong session name

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?

A session presents itself to peer sessions under a name the user set for a different, discarded conversation in the same process.

/clear starts a new session id inside the running process. If you /rename there and then return to the pre-clear conversation, the process's entry in the live-session registry (~/.claude/sessions/<pid>.json) has its sessionId field updated back to the original conversation, but its name field is left holding the name from the discarded session. That stale name is what ListAgents reports and what receiving sessions render as the sender of a cross-session SendMessage.

Because an explicit name is present, the derived-name path never runs: the entry has no nameSource: "derived", so the session never falls back to the usual <dir>-<nn> name. The session's own ai-title is not consulted either.

Observed with two live sessions in the same project directory. The affected session ran for ~22 minutes advertising a name the user had set on a conversation that no longer existed.

What Should Happen?

Switching the conversation underneath a process should re-resolve the session's name. When the new conversation has no custom title of its own, the registry entry should drop the previous conversation's name and fall back to that conversation's own title (or the derived <dir>-<nn> name), rather than keeping a name that was set for a discarded session.

Error Messages/Logs

# The live-session registry entry for the affected process.
# sessionId is the ORIGINAL pre-/clear conversation; name came from the /clear-created one.
$ cat ~/.claude/sessions/22194.json
{
  "pid": 22194,
  "sessionId": "21a0968e-3fa8-474e-b2c5-b3a60be11b5d",   # original conversation
  "cwd": "/Users/me/code/blog",
  "startedAt": 1787411766588,                             # 15:16:06Z, matches 21a0968e's first entry
  "procStart": "Sat Aug 22 15:16:05 2026",
  "version": "2.1.240",
  "kind": "interactive",
  "tmux": "omc-blog-master-20260822151605:@0.%0",
  "messagingSocketPath": "/tmp/cc-socks/22194.sock",
  "name": "blog improvement",                             # only after a second, manual /rename
  "nameSince": 1787414849872,                             # 16:07:29Z
  "formerNames": [
    { "name": "this is hi", "until": 1787414849872 }      # <-- set in the DISCARDED session 6c08442a
  ]
}

# A healthy peer for contrast - note the nameSource field the affected entry lacks:
$ cat ~/.claude/sessions/50841.json
{
  "pid": 50841,
  "sessionId": "77200652-06b8-4587-a21f-127382919445",
  "cwd": "/Users/me/code/blog2",
  "name": "blog2-73",
  "nameSource": "derived",
  ...
}

# The name "this is hi" was written by a /rename issued in session 6c08442a,
# which /clear had created inside this same process 22 minutes earlier:
$ cat ~/.claude/projects/-Users-me-code-blog/6c08442a-.../custom-title.json
{"customTitle":"this is hi"}

Transcript evidence that both conversations belong to one process, and that the process moved between them (both files are under ~/.claude/projects/-Users-me-code-blog/):

# 6c08442a-....jsonl - created by /clear at 15:44:41, then renamed
line  3  15:44:41.781Z  attachment  hook_success: SessionStart:clear
line  8  15:44:41.577Z  user        <command-name>/clear</command-name>
line 30  -              custom-title {"customTitle":"this is hi"}
line 32  15:45:09.583Z  system      <command-name>/rename</command-name> <command-args>this is hi</command-args>
line 41  15:46:13.744Z  assistant   "No response requested."          # last activity; 42 entries total

# 21a0968e-....jsonl - the original conversation, resumed afterwards and still live
line 367 15:44:23.632Z  system      <command-name>/color</command-name>          # before the clear
line 369 15:44:39.696Z  system      <command-name>/resume</command-name>
line 371 -              last-prompt {"lastPrompt":"create a new menu named fun...","leafUuid":"..."}
line 373 15:46:02.520Z  system      <command-name>/color</command-name>          # AFTER the clear -> back here
line 378 15:58:57.466Z  attachment  async_hook_response: SessionEnd:resume
line 586 -              custom-title {"customTitle":"blog improvement"}          # the manual fix, 16:07Z
# Also: 20 x {"type":"ai-title","aiTitle":"Fun menu with fun facts"} - never used for the peer name.

Steps to Reproduce

1. Start claude in a project directory and give it a turn of real work, so it picks up an auto-generated title. Do not /rename it. Note its pid.
2. Confirm the baseline: cat ~/.claude/sessions/<pid>.json shows "nameSource": "derived" and a derived name like myrepo-4e. From a second session, ListAgents shows that derived name.
3. In the first session, run /clear. This creates a new session id inside the same process (its transcript opens with a SessionStart:clear hook).
4. Run /rename this-is-hi in the cleared session, and send it any prompt.
5. Return to the pre-clear conversation (/resume and pick it, or /rewind past the clear).
6. Inspect ~/.claude/sessions/<pid>.json.

Observed: sessionId is back to the original pre-clear conversation, but name is this-is-hi, nameSource is gone, and formerNames records the transition. From a second session, ListAgents reports the original conversation as this-is-hi, and cross-session messages it sends arrive with from-name="this-is-hi". Running /rename in the restored conversation fixes it immediately - same [ref], no restart - which confirms the registry entry is the source.

Expected: step 6 shows the original conversation's own name (its title, or the derived myrepo-4e), not the name set on the discarded session.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.240 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Scope: single process, single PID. This is not #86531 - that one is cross-process contamination via a shared CLAUDE_JOB_DIR, and here CLAUDE_JOB_DIR is unset on every live session on the machine (checked all four). It is also not #85064, which is observer-side staleness in ListAgents after a /rename.

Second symptom, likely the same root cause: after the same /clear -> resume transition, the scratchpad path injected into the system prompt stayed pinned to the /clear-created session id (.../6c08442a-.../scratchpad) while the conversation and transcript were the original session's. So the session switch re-derives the registry's sessionId but not the scratchpad path, and not the name. Happy to split this into its own report if preferred.

Note on the evidence: the live registry file was read after the corrective /rename, so the "name": "this is hi" state during the affected window is established by the formerNames entry (name held until 16:07:29Z) together with direct observation from a peer session - ListAgents showed this is hi, and the receiving session rendered the sender as this is hi. The user confirmed that name belonged to the other session.

Minor UX consequence: the /rename in the cleared session also injected The user named this session "this is hi" as a system reminder. After returning to the original conversation, that framing no longer matched the conversation the model was actually in.

Terminal note: sessions were running inside tmux under Terminal.app.