[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.