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

Both pieces of this shipped:

• claude --name TICKET-123 (or -n) sets the session name at launch (v2.1.76).
• A UserPromptSubmit hook can return hookSpecificOutput.sessionTitle to rename the session automatically — e.g. a small script that greps the prompt for a ticket ID and sets the title (v2.1.94). SessionStart hooks can do the same from the branch or folder name.

Docs: https://code.claude.com/docs/en/hooks#userpromptsubmit-decision-control
Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

🤖 Generated with Claude Code

Sharing what I found digging into this today, in case it saves anyone else the afternoon.

A tool that does this already exists. It is undocumented and desktop-only.

Claude Code Desktop ships an internal MCP server, ccd_session_mgmt, exposing list_sessions, get_session, search_session_transcripts, list_events, archive_session, send_message and set_session_title.

mcp__ccd_session_mgmt__set_session_title renames the live session properly, UI included. It is injected into desktop-hosted sessions only, so CLI and VS Code sessions do not see it.

Claude can call it, which means a SessionStart hook injecting one line of context is enough for fully automatic naming:

Set this session's title to <name> using set_session_title. Do this once, early, without commenting on it.

I derive <name> in the hook from git (repo, branch, role, start time), so sessions name themselves with no typing at all. On a protected branch there is no task in the branch name, so the hook passes a template with a <slug> placeholder and lets Claude fill it from the conversation. That has held up across live sessions.

How to check it actually ran

titleSource on the session record tells you which path did the rename:

• auto = the background titler
• user = /rename, or a manual rename in the UI
• tool = set_session_title

The record is at ~/Library/Application Support/Claude/claude-code-sessions/<account>/<org>/local_<uuid>.json, and its cliSessionId matches the session_id your hook receives on stdin. Worth checking, because "I asked Claude to rename the session and it did" is not by itself evidence the tool ran.

Why the other approaches fail

@estesbreninc your JSONL result is correct, and here is the mechanism: the custom-title record in the transcript is an output of the desktop store, not an input. Appending to it changes nothing, including across an app restart. The store is the source of truth.

Writing that store directly does drive the picker, but it loses a race. The app holds the record in memory and re-persists it every turn. I measured a hook write at 13:31:21 overwritten by the app at 13:32:21. Deferring the write until the session has been idle works, but it is fragile and it is not needed given the tool exists.

@GravyaDev on the lock you asked for: titleSource: user is already respected, the auto titler does not overwrite it. What overwrites a manual rename is the persistence race above, not the titler.

/rename is defined with requires: {ink: true}, so it is TUI-bound by design. claude -p --resume <id> "/rename x" reports success but renames a detached process, and the CLI name and the desktop picker turn out to be separate namespaces.

Why this issue should stay open

This is undocumented internal API. It can change or vanish in any release, there is no supported way to reach it from a hook or the SDK, and it does nothing for CLI or VS Code sessions, which still have only claude -n at startup. A documented tool, or a sessionName field in hook output as proposed in #24872, is still the right fix. Treat the above as a workaround rather than a resolution.

Hook, with install notes and the worktree/protected-branch//clear edge cases handled: https://gist.github.com/Shepherd-Creative/4b723ba2261292a58bcc931aff7c0b3e

Credit where it is due: I worked this out together with Claude Code (Opus 5) over a long session of poking at binaries and testing on throwaway sessions, and it wrote this comment up for me.

Another use case for this: I'd like Claude Code session titles in the sidebar to auto-prefix with the issue number when the session is working on a repo issue (e.g. from the current git branch name or an issue number mentioned in the first prompt). For example, instead of a generic auto-generated title like "Fix login redirect bug," it would show "#123: Fix login redirect bug" — so I can identify sessions by issue at a glance.

Another use case for this: I'd like Claude Code session titles in the sidebar to auto-prefix with the issue number when the session is working on a repo issue (e.g. from the current git branch name or an issue number mentioned in the first prompt). For example, instead of a generic auto-generated title like "Fix login redirect bug," it would show "#123: Fix login redirect bug" — so I can identify sessions by issue at a glance.

This can be done perfectly in Claude Code with UserPromptSubmit hook. The script can just parse the current git branch name and return "sessionTitle" in the response body.
But it will only work on UserPromptSubmit.