Feature request: Allow Claude to programmatically rename sessions

Since remote sessions landed, I've been accessing Claude Code from my phone regularly. The problem is session names are often meaningless when browsing from a small screen — I can't tell what each session is about without opening it.

My ideal workflow would be using a hook (e.g. on Stop or a periodic trigger) to automatically rename the session based on the current development context. Something like renaming to the active branch + task summary every ~10 minutes.

A sessionName field in hook output (as proposed in #24872) or a dedicated CLI command like claude session rename would both solve this. Either way, programmatic access to session renaming is the missing piece for making remote sessions truly usable.

Additional use case: AI-initiated session naming at startup

I have a workflow where a SessionStart hook injects a timestamp and CLAUDE.md instructions tell Claude to ask "What would you like to name this session?" at the start of every new conversation. The user provides a name, Claude constructs the full title (e.g., 2026-03-27_1229-auth-refactor) — and then hits a wall.

Claude can't invoke /rename. The only option is to output the command as text and ask the user to copy/paste it:

Run this to name your session: /rename 2026-03-27_1229-auth-refactor

This adds friction to every single session start.

Workaround attempted: I built a Stop/PostCompact hook that writes custom-title entries directly to the session JSONL file and maintains a sidecar .title file next to it (to survive the 64KB tail window compaction — same issue documented in #33165). This persists the name for /resume and session lists, but does not update the live prompt line or terminal tab title, since those are controlled by Claude Code's internal UI state. Only /rename or a session resume triggers those UI updates.

A SessionRename tool callable by the AI would completely solve this — Claude already has the name, it just needs a way to apply it that updates the live UI.

Another useful feature would be auto suggest renaming, potentially after session grows beyond certain length so we don't need it for trivial session.

+1 — and a prerequisite for this to be useful: a lock mechanism on session names.

Today, even manually renamed sessions get auto-overwritten by task-generated titles during the conversation. A programmatic rename API would suffer the same problem — the auto-rename would silently overwrite it.

Proposal: a locked flag (set automatically on any manual or programmatic rename) that prevents auto-rename from overwriting the name. This makes both the current /rename and any future programmatic rename actually stick.

---

Disclaimer: this comment and the proposal it contains were drafted by Kloud AI assistant (kloud@gravya.it) under human review and approval. Human in the loop: GravyaDev.

+1 Would be really useful in combination with skills

+1 — adding a real-world ergonomic case that I haven't seen articulated in this thread:

I run 6-10 concurrent Claude Code sessions across a tabbed terminal (one per task / branch / worktree). My primary way to find old work is the /resume picker. When sessions don't have a clear name, the picker shows the first line of the conversation, which is usually noise like "ok let's look at this" or system context. Result: prior conversations become unfindable within a day.

Manual /rename is unreliable because I'm thinking about the work I'm doing, not the session metadata. By the time I remember to rename, I've already lost track of which tab was which. Sessions that took hours to build up get effectively orphaned because I can't find them in the picker the next morning.

The interim workaround (/rename with no args — Haiku auto-generates a name from current context) helps when I remember to use it, but the whole point of the friction is that I forget. A programmatic path — even just a hook that fires after the first substantive exchange and auto-names via Haiku — would close the gap.

Workflow pattern that would benefit: heavy multi-session users where /resume is the primary navigation surface.

This would be fantastic. Looking to take advantage of tooling that would be nice to have standardized.

This would be really useful! When working with parallel sessions on a related problem it can get confusing to have to remember which one is working exactly on what issue at the moment, seeing it in the GUI would be very helpful.

The workaround that I'm currently using:

A UserPromptSubmit hook (in ~/.claude/settings.json) runs a script that reads transcript_path from stdin, extracts your last assistant turn, and greps for a marker like <!--rename: TITLE -->, emitting {"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","sessionTitle":"TITLE"}} — because only SessionStart/UserPromptSubmit (not Stop) can set the title, so the rename lands on your next message. A CLAUDE.md rule instructs Claude to end replies with that marker when the session name is stale, so naming happens automatically with no /rename copy-pasting — just a one-message delay.

bump