[BUG] /clear loses session name from prompt bar and spawns a distinct session

Confirming this also reproduces in the VS Code extension (not just a standalone terminal), so it's not terminal-specific.

Repro:

1. Set a custom name for a session (it shows in the prompt bar as expected).
2. Run /clear.

Actual: the custom name is dropped and the prompt bar reverts to an auto-generated title.

Same behavior and same workaround as described (/rename <name> again after /clear restores it). Would be great to have /clear preserve the session name here as the docs imply.

🤖 Generated with Claude Code

Root-caused this by inspecting the shipped binaries (2.1.198 — the version reported here — plus 2.1.201/2.1.202/2.1.204). The name survives /clear in every persistence layer; what breaks is only the prompt-bar UI state, which is wiped during the clear and never re-seeded. Property/record names below are as they appear in the bundle, so they should be greppable in source.

1. /clear starting a new session is by design. The session id rotates (SessionStart hooks fire with source: "clear"), and in 2.1.20x the command self-describes as "Start a new session with empty context; previous session stays on disk (resumable with /resume)", with aliases /reset and /new and an optional [name] argument that labels the cleared session for /resume. So "picker shows a distinct session" is expected behavior; the docs wording in sessions.md is what's misleading (related: #57445).

2. The name carry-over already exists — in persistence. clearConversation captures the user-set title before rotating and calls saveCustomTitle(newSessionId, title, undefined, "user") after: this appends a {"type":"custom-title"} record to the new session's transcript and updates in-memory currentSessionTitle. Present in 2.1.198 through 2.1.204 (this looks like the 2.1.111 fix "Fixed /clear dropping the session name set by /rename, causing statusline output to lose session_name"). Side effect: old and new sessions can then show the same name in /resume — which is exactly the duplicate-name complaint in #61172, i.e. more evidence the persistence carry-over works.

3. The prompt bar renders a different store, and that's the bug. The prompt bar shows appState.standaloneAgentContext.name. Only two paths write it: startup seeding and /rename (which does both saveCustomTitle(...) and a setAppState that writes standaloneAgentContext.name). clearConversation's app-state reset explicitly discards standaloneAgentContext — it preserves only prideGradient — and nothing re-seeds name afterwards. That is precisely why the reported workaround works: /rename after /clear is the only path that writes the field back.

4. The tab-title asymmetry. The terminal-title name lives in the per-PID registry (~/.claude/sessions/<pid>.json). On clear, that file gets only its sessionId field updated in place; its name field is untouched — so the tab keeps the name while the prompt bar loses it.

Suggested fix: in clearConversation, when the title carry-over branch runs, also re-seed the prompt-bar state — either exempt name (and color, which is dropped by the same reset) from the standaloneAgentContext wipe when a user-set title exists, or invoke the same app-state update /rename uses after saveCustomTitle. #67389 (SessionStart hook sessionTitle ignored for source: "clear") looks like the same gap: the hook path persists via saveCustomTitle but never touches standaloneAgentContext.name either.

Mechanism is unchanged in 2.1.204, so this should still reproduce on latest.

🤖 Generated with Claude Code

Also reproduces on macOS (Darwin 25.3.0), so this is not Windows-specific. Name set via /rename is gone after /clear and a new session file is created under ~/.claude/projects/<project>/.

Workaround that works for me: a SessionStart hook with matcher "clear" that reads the last {"type":"custom-title"} line from the most recent previous session .jsonl in the project directory and re-applies it via hookSpecificOutput.sessionTitle.

Confirmed — reproduced on the released 2.1.233 build (Linux, fresh profile):

1. /rename mytestname → name shows on the prompt bar. ✔
2. /clear → name disappears from the prompt bar and doesn't come back on later turns, until another /rename. ✘

Two useful details from digging in: the name is not actually lost — the continued session keeps the custom name in session storage, and the --resume picker shows it with the right name. Only the prompt-bar display drops it after /clear, which we agree is a bug.

On the second part: /clear saving the previous conversation as its own resumable entry (so the picker shows the pre-clear conversation separately from the continuing one) is the documented behavior — "the previous conversation is saved and resumable" requires it to stay its own entry. So the distinct picker entry is expected; the prompt-bar losing the name is the part we'll fix.

🤖 Generated with Claude Code