[FEATURE] /clear should not inherit session name, causing duplicate entries in /resume history
Problem Statement
When working in a named session and issuing /clear, the new conversation inherits the previous conversation's session name. This creates multiple conversation history entries with identical names but different content. When using /resume to return to a previous conversation, the duplicate names make it difficult to identify the correct one -- the only distinguishing clues are file size and timestamp, which aren't meaningful at a glance.
This is compounded by two factors:
- The colored input box border with the visible conversation name no longer appears, so there's no on-screen reminder that the cleared conversation is still carrying a name from the previous context.
- When asked whether the session is named, Claude incorrectly states it is not named and suggests a nonexistent
/sessionscommand. The model has no awareness that the name was inherited via/clear.
Proposed Solution
/clear within a named session should either:
- Drop the session name so the new conversation starts unnamed (preferred -- clean break), or
- Prompt the user for a new session name, or
- Auto-suffix the name (e.g.,
my-session-2) to keep history entries distinguishable
The key requirement is that each conversation in /resume history should be uniquely identifiable.
Alternative Solutions
The workaround is to /rename the conversation after every /clear, but this requires remembering to do so each time. It's especially easy to forget now that the session name is no longer visually prominent in the input area.
Priority
Medium - Would be very helpful
Feature Category
Interactive mode (TUI)
Use Case Example
- Start a session:
claude -n statusline-work - Complete the task, then
/clearto start fresh - Begin unrelated work in the new conversation
- Later, need to revisit the statusline work via
/resume - See two entries both named "statusline-work" -- can't tell which is which without trial and error
- Ask Claude if the session is named -- Claude says no and suggests a nonexistent command
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗