[FEATURE] /clear should not inherit session name, causing duplicate entries in /resume history

Resolved 💬 3 comments Opened May 3, 2026 by consentculture Closed Jun 21, 2026

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:

  1. 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.
  2. When asked whether the session is named, Claude incorrectly states it is not named and suggests a nonexistent /sessions command. The model has no awareness that the name was inherited via /clear.

Proposed Solution

/clear within a named session should either:

  1. Drop the session name so the new conversation starts unnamed (preferred -- clean break), or
  2. Prompt the user for a new session name, or
  3. 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

  1. Start a session: claude -n statusline-work
  2. Complete the task, then /clear to start fresh
  3. Begin unrelated work in the new conversation
  4. Later, need to revisit the statusline work via /resume
  5. See two entries both named "statusline-work" -- can't tell which is which without trial and error
  6. Ask Claude if the session is named -- Claude says no and suggests a nonexistent command

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗