[BUG] /clear inherits previous session name instead of resetting it, causing duplicate-named sessions in /resume

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27329
2. https://github.com/anthropics/claude-code/issues/26082

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

These both look like the same bug, but they're already closed (one completed in Feb, one stale). Since it works in v2.1.89 but not v2.1.146, this seems like a regression worth keeping open. Happy to share more details if useful.

Yes this bug is certainly still open or did re-appear. It is quiet annoying when you work a lot with sessions and have many duplicates of the same session name appearing under /resume 🫠 and you have to guess which was the one you actually meant and which were others which you did not explicitly rename.

Also reproducing on Windows 11 (PowerShell), Claude Code v2.1.181. Same repro as the original post. This issue is labelled platform:macos, but it's happening on Windows too, so it doesn't look macOS-specific. Might be worth adding platform:windows or dropping platform:macos to reflect that.

FYI for anyone following: this repo's stale bot exempts issues with 10+ 👍 reactions on the original post, so reacting there is the most useful way to keep this open.

Reproducing on macOS CLI, v2.1.179 (also affected, with quantified data).

Same bug, plain /clear in the terminal (no VS Code, no worktree isolation). Environment: macOS (Darwin 25.5.0), Claude Code v2.1.179.

I scanned all 55 of my session JSONL files to measure the blast radius. Findings that may help pin the mechanism:

• **The new post-/clear session's first records are duplicated custom-title entries carrying the previous session's name - written at line 0 and** line 2 of the new file, before /clear and before the first real prompt. This matches the now-closed #59237 ("custom-title written twice at the top"), so that report and this one are the same bug.
• The stale title propagates across multiple unrelated sessions. In my data a single custom title leaked onto 3 completely unrelated sessions created later via /clear (each on a different topic). All three showed up under that one name in /resume.
• It only sticks when you don't /rename afterward. Sessions I happened to /rename self-corrected; the ones I didn't stayed permanently mislabeled.
• The title is held in memory per-process and flushed into the new session on /clear. Evidence: a session started after a 6-day gap (guaranteed fresh process) got the correct title, never inheriting anything. So fully quitting and relaunching Claude Code instead of using /clear avoids the leak entirely - a fresh process has no cached title to flush. That is a more reliable workaround than re-/renameing, for anyone hitting this.

Confirming this is a CLI bug, not the VS Code last-prompt-override path (#32150/#40787). +1 to keep it open.

Confirming this regression also reproduces on Windows (not just macOS), on a newer version than reported here —
Claude Code v2.1.209, Windows Server 2022.

Working from a single long-lived project directory with many accumulated sessions, I found the same pattern
described above: several .jsonl session files with completely unrelated conversation content (different topics,
different dates, different session IDs) all sharing an identical customTitle value, with that value written as the
very first line of the file — before any conversation content exists — and no corresponding agent-name (manual
rename) event to explain it. One title string was reused across at least 3 sessions; another across 7 sessions
spanning multiple weeks. The /resume picker shows all of these as indistinguishable duplicate entries, matching the symptom in #59242.

This suggests the fix for #59237/#59242 either didn't fully address the root cause, or the regression reintroduced
it — and it isn't macOS-specific.

Possibly related: filed #81813 for what looks like the same underlying mechanism (a session's auto-generated name isn't freshly derived from its own conversation, but is instead carried over/reused from another, unrelated session), just triggered differently — opening a new session in a working directory another session was recently active in, rather than /clear within the same session.

Evidence in #81813: two sessions with different sessionIds, same cwd, ended up with the identical name. One session's name was a correct summary of its own (extensive) conversation; the other session — which never discussed that topic at all — inherited that same name anyway. The two sessions' active time windows were adjacent/overlapping.

If a maintainer confirms this is the same root cause as this issue, #81813 could probably be closed as a duplicate of this one — leaving that judgment call to you.

Correction to my earlier comment: #81813 turned out to be caused by a third-party UserPromptSubmit hook emitting hookSpecificOutput.sessionTitle on every prompt (title derived from a project file, identical for all sessions in the same cwd) — not by core title inheritance. It has been closed as not-a-Claude-Code-bug and is unrelated to this issue after all. Sorry for the noise.

Reproducing this as well (macOS). Also noticed the companion problem: /color has no way to persist across /clear or new sessions either — see the (closed as duplicate/not-planned) requests #28708, #41887, #50393. Both /rename and /color state seem to get lost or corrupted around /clear, would be great to see both addressed together since they're clearly related session-metadata issues.

Still reproducing on v2.1.227, macOS (Darwin 25.5.0), zsh. Adding a detail that I don't think is in the thread yet, because it makes the mechanism concrete and pins down where the name actually lives.

The carried-over name is persisted on disk, not just held in memory

An earlier comment describes the title as "held in memory per-process and flushed into the new session on /clear." The per-process part is right, but it isn't in-memory — there is an on-disk, PID-keyed registry at:

~/.claude/sessions/<pid>.json

Here is that record on my machine, taken from a session created by /clear (paths and the name redacted):

{
  "pid": 22908,
  "sessionId": "b7dee760-…",
  "cwd": "/Users/<me>/projects/<repo>",
  "startedAt": 1786476080580,
  "procStart": "Tue Aug 11 19:21:19 2026",
  "version": "2.1.227",
  "peerProtocol": 1,
  "kind": "interactive",
  "entrypoint": "cli",
  "messagingSocketPath": "/tmp/cc-socks/22908.sock",
  "name": "TICKET-123",
  "status": "busy",
  "updatedAt": 1786565710467
}

Note it holds both sessionId and name.

Timeline evidence that /clear rewrites one and not the other

• Process 22908 started Aug 11 12:21:19 — alive for over 24 hours, spanning many /clear cycles.
• The current session's transcript b7dee760-….jsonl was created Aug 12 12:34:23, by a /clear.
• The registry record above now points at sessionId: b7dee760-… (the new, post-/clear session), updatedAt seconds ago — while name is still the value inherited from a session started the previous day.

So on /clear this record is updated in place: sessionId is repointed at the freshly minted session, and name is carried across untouched — then re-stamped into the new transcript as the duplicated custom-title records at lines 0 and 2 that others have described. The process is the carrier, which is consistent with the observation that fully quitting and relaunching avoids the leak: a new process gets a new PID and a new registry entry.

Why the name is process-scoped at all

That same file carries messagingSocketPath, peerProtocol, and a live status field, and a second concurrent session in another directory is registered alongside it. So this registry is the live cross-session peer/messaging directory, and name appears to serve as that process's address there. That would explain why the name is scoped to the process rather than to the conversation. Flagging that as my reading of the artifact, not a confirmed root cause.

Blast radius here

Across 44 session transcripts in one project directory: 4 distinct leaked titles, the worst covering 6 unrelated sessions spanning three different git branches and two days of work. All 6 render as identical rows in /resume, distinguishable only by size/age/branch in the subtitle. Sessions predating the first /rename have no custom-title record at all and get correct auto-generated titles — the leak only affects the chain after a rename.

Minor surface discrepancy vs. the original report

The body reports the macOS title bar keeps showing the stale name with a * prefix. On v2.1.227 I see the opposite in the TUI: the session-name indicator in the input area clears on /clear, while both the registry name and the new transcript's customTitle still hold the old value. That's arguably worse than the title-bar case — the UI signals a reset that did not happen, so there's no cue to re-/rename, and the next /clear silently produces another duplicate.

Suggested direction

Decouple the conversation title from the process name. /clear already mints a new session ID and a new transcript file; the name state should be reset the same way. If the process registry needs a stable name for peer addressing, that's process identity and shouldn't be the same field that seeds a transcript's customTitle — otherwise every /clear in a long-lived process inherits it by construction. Whatever the fix, /clear should yield something indistinguishable from a fresh session in /resume.

Reproduced on v2.1.233 (macOS).

Steps:

1. Start claude in an empty project directory.
2. /rename My Test Session, then send any message.
3. /clear, then send another message in the cleared session.
4. Exit and run claude --resume.

Observed: the resume picker shows two entries both named "My Test Session" — the original session and the post-/clear session. The new session's transcript starts with the old name before any prompt is sent, even though the name indicator in the input area disappears after /clear (on current versions the title bar no longer keeps the * name described in the original report, but the on-disk name still carries over). Each further /clear in the same process carries the name again, which is why several commenters see one name spread across many unrelated sessions.

Expected (per the report): after /clear the new session starts unnamed and is distinguishable in /resume.

Assessment: Intended today, but the expectation is reasonable and this is worth making clearer. The name carry-over was added deliberately around v2.1.111 (which matches the "worked in v2.1.89, not in v2.1.146" window here) so that a name set with /rename or --name keeps working for --resume <name> and the statusline after /clear; before that, /clear dropping the name was treated as the bug. It's documented at https://code.claude.com/docs/en/sessions under /clear: "You keep a name you set with --name or /rename in the new conversation, but not an AI-generated session title." The mental model is that the name is your handle for what you're working on now, so it follows you into the fresh conversation; the archived conversation keeps it too because it had it when it was saved. If you want the name to stay only on the conversation you're leaving, use /clear <name> — that names the archived session and starts the new one untitled.

That said, ending up with several identical rows in the resume picker with nothing to tell them apart is a real usability problem. We should make this clearer — for example, tell you after /clear that the name carried over (with a nudge to /rename or use /clear <name>), and/or mark the archived conversation in the picker so duplicates are distinguishable. Same underlying behavior as #78264.

🤖 Generated with Claude Code

Confirmed — reproduced on 2.1.233 (Linux), so this is still current behavior.

What I did: fresh config dir → started a session → /rename My Test Session → /clear → checked the terminal title and the session store, then opened /resume from a new instance.

What I observed:

• After /clear the terminal title still shows ✳ My Test Session.
• The post-clear session is a new session, but it's created carrying the old custom name.
• /resume lists two sessions both named "My Test Session", telling them apart only by age/size — exactly what you reported.

Marking this as a confirmed bug: /clear should either reset the custom name for the new session or the picker should disambiguate. (I didn't independently verify the 2.1.89 regression point, but the behavior is present on the latest release.)

🤖 Generated with Claude Code

Still reproduces on 2.1.272, Windows 11 (PowerShell). /rename b219 → /clear → new session id, and its custom-title.json was created at the exact
timestamp of the /clear with the old name. /resume shows two rows named b219, distinguishable only by age and size.

@bcherny's 2026-08-20 comment lists two acceptable fixes: reset the name on /clear, or make the picker disambiguate. I want to argue that only the first
is consistent with what the sessions doc already commits to. Quotes below are verbatim from https://code.claude.com/docs/en/sessions.md (fetched
2026-09-15).

1. The doc defines the name as a resume handle that resolves to one session.

> Give sessions descriptive names so they're findable in the session picker and resumable by name.

> claude --resume <name> | Resumes the named session directly

> Sessions you don't name still get two labels that Claude Code assigns. Only the generated title works as a resume handle: […] The default isn't a resume
handle. If you pass it to claude --resume or /resume, Claude Code doesn't find the session.

"Resume handle" is the doc's own term, and "resumes the named session" is singular.

2. The doc enforces uniqueness of that handle, and lists the exceptions.

> When you start or resume an interactive session with a name that another live session on this machine already uses, or rename a session into such a
name, Claude Code leaves the name with the session that already has it, renames yours to a variant with a two-word suffix, such as
auth-refactor-graceful-unicorn, and tells you. […] Before v2.1.232, both sessions kept the name.

> In three cases Claude Code doesn't rename the duplicate, so you can still see two sessions with the same name in listings:
> * It doesn't check AI-generated titles or default display names.
> * It doesn't check the --name of a background or -p session at startup.
> * It can't rename a session on an earlier version of Claude Code.

/clear is not on that list, yet it is the one code path that mints a duplicate handle by design:

> With no argument, the new conversation keeps a name you set with --name or /rename, but not an AI-generated session title.

It slips past the uniqueness check only because the archived transcript has just stopped being "live". The doc never says what --resume <name> does when
two stored transcripts share the name.

3. Why reset, not disambiguate.

• Resetting closes the gap: every path that can produce a duplicate handle is then either listed as an exception or prevented. The doc stays internally

consistent.

• Disambiguating the picker keeps a non-unique resume handle in the product and leaves --resume <name> undefined on duplicates. It fixes the symptom the

picker shows and nothing else.

• The users in #73340 who want the label to survive as a "what I'm working on" marker are already served by /clear <name> (names the archived one, new

starts blank) and by /rename. A one-line notice after /clear ("name not carried over; /rename to set one") covers the discoverability concern raised
on 08-15.

From the user's side, the thing you can address is the transcript: you resume it, rename it, preview it. A label that follows "what I'm working on" is
never selectable anywhere, so a name that outlives the transcript it identified has stopped doing the one job the doc gives it.

Reproduced on Claude Code 2.1.278, Linux (WSL2 Ubuntu).

1. Named a session (clear-hello-world).
2. Ran /clear.
3. The new session (new ID) starts with {"type":"custom-title","customTitle":"clear-hello-world"} and {"type":"agent-name","agentName":"clear-hello-world"} as its first transcript lines.

Expected: /clear starts a fully fresh session and keeps nothing from the previous one, including its name. Today the only way to get a truly clean session is to exit and relaunch claude.

Still reproduces on 2.1.294, Windows 11. Not adding another repro, though: The open question is whether this is still considered a bug.

The sessions doc now describes the carry-over as intended (https://code.claude.com/docs/en/sessions, /clear entry):

With no argument, the new conversation keeps a name you set with --name or /rename, but not an AI-generated session title. To name the conversation you're leaving instead, pass the name, as in /clear release-prep; the new conversation then starts unnamed

That contradicts the bug / reproduced labels and @bcherny's confirmation above that /clear should reset the name. Could a maintainer say which one is it moving forward with? Or if it's moving forward at all?

Options I propose:

1. Fix it as a bug: /clear starts the new conversation unnamed, and the docs are updated to match. (ideal for me)
2. Keep the carry-over as the default but make it configurable, as proposed in #99633 (e.g. a clearKeepsSessionName setting). People who want the name kept (#38649, #88367) and people who don't would both be covered. (Feel like it's the sensible way)
3. Keep it as is, and relabel this issue so it stops reading as a confirmed bug. (Well, at least it wont'be a bug)

/clear <name> works as a workaround, but it only helps if you remember the argument every time. Forget it once and you get another duplicate entry in /resume. Over time you end up with several same-named sessions.