Custom session titles migrate across /clear and /branch onto unrelated conversations; agents-list resume attaches to the wrong session
Bug: custom session titles migrate across /clear and /branch onto unrelated conversations; agents-list resume then attaches to the wrong session
Environment
- OS: Windows 11 Pro (build 10.0.26200)
- Claude Code CLI (npm), versions spanning the incidents: 2.1.206 → 2.1.211 (the
/clearincident occurred on 2.1.209; the/branchincident on 2.1.206) - Background agents (
claude agents) in active use
Summary
The custom title set via /rename (or /branch <name>) behaves as a property of the terminal/background job, not of the conversation it was applied to. Whenever the session id rotates under the same job (/clear, /branch, resume-under-job), a {"type":"custom-title", ...} line carrying the old title is stamped into the new/other session's .jsonl. The resume picker and agents list present titles as conversation identity, so:
- the renamed transcript becomes unreachable by its name, and
- attaching via the agents list lands the user in a different conversation that has inherited the name — including delivering new user messages into the wrong conversation.
Two independent incidents, forensically reconstructed from the on-disk .jsonl files (both reproduced below with line-level evidence).
Incident A — /clear carries the title to a brand-new conversation
- 15 Jul 08:17Z — session
8c4ce3a8-e325-47b8-8a2f-12a5e4c17f6fstarts as a background job (job id192e3519), ai-title "Design job folder management and migration system". User renames it "FABLE NAS Folder Planning" (file contains matchingagent-name+custom-titleentries). - 15 Jul 08:50:16Z — user runs
/clearin that terminal. The session id rotates to55d175bb-4e52-4982-9e2c-8b17bb93f2aeunder the same job. Line 1 of the new session's.jsonlis:
``json`
{"type":"custom-title","customTitle":"FABLE NAS Folder Planning","sessionId":"55d175bb-4e52-4982-9e2c-8b17bb93f2ae"}
/clear
i.e. the old title is stamped onto a brand-new, completely unrelated conversation before its first message. (The command entry itself is logged at line 5 of the *new* file, "version":"2.1.209"`.)
- The user then had an entirely different conversation in that session. The agents list now shows the job as "FABLE NAS Folder Planning", but its head is the unrelated conversation; the actual renamed transcript (
8c4ce3a8…) is no longer surfaced anywhere by that name. - 16 Jul 12:09Z — user, wanting to resume the NAS work, finds "FABLE NAS Folder Planning" in the agents list, attaches, and sends a continuation message — which is delivered into the wrong conversation (the job's current head). Each re-attach appended further
custom-titlelines into the wrong session's file (5 occurrences, at lines 1/19/31/49/64 of a 77-line file).
Incident B — after /branch, the branch's name is stamped onto the original session at resume
- Session
ac0db3b3-8cc7-4a24-85be-21ad267b0eb9was custom-named "MASTER FABLE CONDCUTOR for masterful Orchestration". - 12 Jul 16:03Z (
2.1.206) — user runs/branch MASTER Opus CONDUCTOR for expert Orchestration→ new sessiona4267d17-6177-4b87-81e5-c779fdc0fd3f. The command stdout is correct: it says the original keeps its name and can be resumed by id. - 14 Jul 23:29Z — user resumes the original
ac0db3b3…(same job;~/.claude/jobs/ac0db3b3/exists). At resume time the following is appended to the original's file:
``json``
{"type":"custom-title","customTitle":"MASTER Opus CONDUCTOR for expert Orchestration","sessionId":"ac0db3b3-8cc7-4a24-85be-21ad267b0eb9"}
followed by a system-reminder turn telling the model "The user named this session 'MASTER Opus CONDUCTOR for expert Orchestration'" — the user never renamed it. The branch child's title was silently copied onto the parent.
- Result: both sessions now display the branch's name; the original's name is gone from the resume picker, and the user (and the model) can no longer locate "MASTER FABLE CONDCUTOR" by name. (The original's file also shows two different
bridgeSessionIdvalues across its lifetime, consistent with re-bridging on re-attach.)
Expected behaviour
- A custom rename should bind to the conversation it was applied to.
/clearshould not carry the previous conversation's custom title onto the fresh session (or should make the detachment explicit).- Resuming a session should never overwrite its stored custom title with another session's title.
- Attaching from the agents list should land in the conversation whose title was displayed.
Impact
- Renamed sessions become unfindable by name (the name points at different content).
- User messages get delivered into the wrong conversation after an agents-list attach.
- The injected "The user named this session …" system-reminder feeds the model false information about which conversation it is in.
Notes
- Searched for duplicates: #26964 (closed, different cross-contamination), #60984 / #68616 (different persistence regression). This appears to be distinct: it is specifically title/identity migration across session-id rotations under one job.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗