Session auto-title latches onto an interrupted first message and never regenerates
Symptom
The interactive CLI generates a session's auto-title once, from the first non-command user message, and never updates it. When that first message is one I submitted and then interrupted with Esc before it ran, the title sticks to that aborted message for the rest of the session, even after I send real follow-up prompts and do substantial work. The stale title shows in claude --resume, the Recents sidebar, and the terminal tab, and stays until I run /rename.
Reproducer
- Start a session whose first turn is a slash command, so the first turn is a command rather than prose (a custom skill works).
- Type a prose message, press Enter, then interrupt it with Esc before it produces a response.
- Send a different prose message and let it complete normally.
- Look at the session title.
Expected: the title reflects the actual conversation, or at least is not derived from the aborted turn.
Actual: the title is generated from the interrupted message in step 2 and never changes, including after step 3.
Determinism
Reproduces every time the first title-eligible user message is an interrupted turn. This is easy to hit when a session opens with a slash command, since command turns are skipped for titling and the next prose message becomes the title source.
Root cause (observable)
The title is persisted to the session transcript as a single ai-title entry, generated once from the first eligible user message and not regenerated. In ~/.claude/projects/<project>/<session>.jsonl the ai-title entry is written right after the interrupted turn and before the real follow-up message, and it never updates for the rest of the session.
Suggested fix directions
- Regenerate the auto-title over the conversation after a few messages instead of one-shot on the first eligible message.
- Exclude interrupted or aborted turns from title generation.
- For sessions that open with a slash command, derive the title from the first substantive turn rather than the first stray prose message.
Environment
- Claude Code 2.1.186, interactive CLI, Linux. Observed June 2026.
Related
#61179 (make auto-generated session titles more descriptive or configurable) is adjacent but distinct: this is about the title being derived from the wrong, aborted message and never updating, not about title quality.
4 Comments
Related finding: there is no way to clear the session title entirely.
/renamecan change the title but not remove it — passing""or''sets the title to those literal strings rather than making it blank. The title persists even after:~/.claude/plans/*.md)--resume(the title is restored from theai-titleentries in the session JSONL)The only escape is starting a completely new session without
--resume, which loses conversation history.Expected:
/renamewith an empty argument (or a dedicated/rename --clearflag) should remove the display title and fall back to a neutral state.Environment: Claude Code interactive CLI, Linux, TUI.
Additional impact: this makes users reluctant to use
/planmode.When
/planis invoked, the session title gets set to something plan-related (e.g.,visual-help-redirect-implementation) and stays there permanently. Since there's no way to clear it afterward, users who work on multiple topics within a session — or who use/planexploratorily — end up with a stale title that no longer reflects what the session is actually about.The inability to clear the title creates a practical disincentive to use
/planat all.Adding a more general version of the first suggested fix here (regenerate the title over the conversation instead of one-shot on the first eligible message), independent of the interrupted-turn case.
Even when the first message is a clean, completed prose turn, it often does not carry enough context to produce a good title. Plenty of sessions open with something vague like "let's look at X" or a broad question, and the actual topic only becomes clear after the first response or two. Because the
ai-titleis generated once and then frozen, the Recents sidebar and the--resumelist fill up with titles derived from the opening line rather than what the session turned out to be about.Concrete request: regenerate the auto-title after the first one or two completed turns, or simply once after the initial request has been handled, and then leave it alone. A single re-derivation at that point would capture the real scope in the common case without churning the title on every message.
Workaround today: I maintain a custom skill that rewrites the title entry in the transcript on demand, but it is manual and easy to forget. A built-in "title once there is enough context" pass would remove the need for it.
Thanks for the detailed repro — I reproduced this on 2.1.233 (Linux).
Steps I ran: opened a session whose first turn was a project slash command, submitted a prose prompt and hit Esc a few seconds in, then did two more real turns (created a file, ran it, edited it). The title stayed the summary of the interrupted prompt in
claude --resumefor the rest of the session — exactly as you describe.I also ran a control with no interruption at all: first prompt "What is 2 plus 2?", then a substantial second turn writing a script. The title stayed "Calculate simple arithmetic". So the title isn't sticking because the turn was interrupted — it's one-shot by design, summarizing the first non-command prompt at the moment you submit it, before the turn runs. That matches the docs: https://code.claude.com/docs/en/sessions ("a short summary of your first prompt").
/renamereplaces it.That said, your expectation is a fair one: a prompt you aborted before it produced anything is a poor thing to name a session after, and it's easy to hit when a session opens with a slash command. So I'm treating this as intended-but-confusing rather than closing it, and passing your two suggestions along — skip aborted turns as a title source, and/or refresh the title once the conversation has real content.
🤖 Generated with Claude Code