[FEATURE] /clear and /new should not copy a custom session name into the new conversation (or make it configurable)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a conversation has a custom name (set with /rename or --name), running /clear or /new without an argument starts a new conversation that inherits that name. This is documented in Sessions:

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

Most people name a conversation after its topic ("Debugging buttons"), not after a terminal or role. A topic name describes one specific conversation. When I run /new, I'm usually switching to a different topic, so the inherited name is wrong as soon as the new conversation starts.

The result is several saved conversations with the same name, and /resume can't tell them apart:

• the original conversation, which is the one I actually want to find later
• any empty or aborted conversations from a /new I started by mistake
• the conversation about the new topic, now mislabeled with the old name

The workaround, /clear <name>, names the conversation you're leaving. It's easy to miss, and you have to remember it every time. If you forget once, the name is no longer unique.

This default also turns off the AI-generated title for the new conversation. An unnamed conversation would get a generated title that matches its actual content.

Proposed Solution

1. Default: /clear and /new with no argument start an unnamed conversation, just like a new session. It then gets an AI-generated title from its content, and the previous conversation keeps its name unchanged.
2. Setting: a setting such as "clearKeepsSessionName": true for people who use names as a stable workspace or role label (terminal tab title, cross-session messaging address, Remote Control). With it on, the new conversation keeps the name, but the saved transcript being left gets a distinct suffix (for example backend (Oct 5 14:32)). That way two saved conversations never end up with the same name.

Either way, clearing should never leave two saved transcripts with identical names.

Alternative Solutions

• Remembering to run /clear <name> every time. This works, but it's easy to forget and one slip breaks it.
• Running /rename afterwards. This requires noticing the duplicate first, and finding the right session among identically named ones.
• A SessionStart hook with source: "clear" that returns a new sessionTitle. Hooks can only rename the new session, and it isn't documented whether a hook can clear a title back to "unnamed" so a generated title takes over. A built-in default is the right fix, not a per-user hook.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. I name a conversation "Debugging buttons" and finish that work.
2. I run /new to start designing a new feature. The new conversation is also called "Debugging buttons".
3. I realize I started it wrong and run /new again before typing anything useful. Now there's a third "Debugging buttons".
4. A week later I want the original button debugging conversation. /resume shows three sessions named "Debugging buttons": the real one, one empty or broken one, and one about a different feature entirely.

With the proposed default, step 2 would give an unnamed conversation that gets a title like "Design new feature X". Step 3 would leave no duplicate, and step 4 would find exactly one "Debugging buttons".

Additional Context

• Claude Code version: 2.1.288, macOS
• Current behavior is documented in Sessions under /clear.
• The current default makes sense only when the name labels a terminal or role (backend), not a topic. Topic names are the common case, and they're how the session picker is used to find past work.