[FEATURE] Feature request: expose a "rename session" tool to the agent (ccd_session_mgmt)

I have a similar use case writing tooling and I want to programatic rename sessions or trigger the autorename.
So basically the same functionality as /rename, though accessible from outside.
Ideally there would a claude subcommand which would allow this.

Something like:

claude sessions rename 
claude agents rename

or similar.

The rename-session gap compounds quickly when you're running parallel sessions across machines or git worktrees. Auto-generated titles based on first-message content work fine for single-session use but become actively misleading once you have 3-4 sessions running: two of them might open with identical messages ("implement the auth changes") and become indistinguishable in the list.

The /rename slash command exists in the TUI, which confirms the underlying data model supports custom titles. Exposing that to agents via ccd_session_mgmt is the logical next step.

A few related gaps worth calling out in the same ticket scope:

1. Machine/hostname prefix. Even just "macbook-pro: auth refactor" would immediately solve the multi-machine confusion without requiring agents to remember to rename. Could be a session-start default.

1. autorename trigger. The suggestion above about a programmatic autorename (let the model pick a title based on accumulated context) would be more useful mid-session than at start, since the first message is often too generic.

1. Worktree annotation. When a session is started in a git worktree, surfacing the branch name in the title would close most of the disambiguation gap for the common parallel-branch pattern.

The create_session FR (#66126) is upstream of this one -- if orchestrators can spin up sessions programmatically, they can pass a meaningful title at creation time rather than patching it after the fact.

Adding a measured data point from Claude Code v2.1.219 (desktop app, Windows): ccd_session_mgmt does now expose set_session_title — but it is scoped to other sessions only, so the ask in this issue is still unmet.

Measured today:

| Attempt | Result |
|---|---|
| Rename another session (idle or actively running) | works |
| Rename the current session | Refusing to rename the current session from within itself. |
| Find the current session's own id | list_sessions excludes it; get_session returns Refusing to return the current session; use list_sessions for other sessions or your own session context for this one. |
| Rename the parent session from a subagent | identical refusal — a subagent is treated as being inside the parent session, so that is not a workaround |
| Nonexistent id (control) | Session <id> not found. — a different message, so the refusal above is a deliberate guard rather than a lookup failure |

That last row is the point: the store plainly supports retitling a live session, since it does exactly that for other running sessions. Only the caller-is-self path is blocked. So the "self" literal proposed here is precisely the missing piece.

A second use case, in case it helps weigh this. I keep a coordinate-based backlog (R-139 (session-title-convention)) and want every session titled @<date> <coordinate> (<name>), where the leading @ means "this coordinate is still open". The agent can derive that entire string from the backlog files on the first turn — it simply cannot apply it to itself, so a human retypes it every session. Renaming other sessions does not substitute: judging whether a different session's work is finished is a separate call, and an unrelated new session is the wrong place to make it.

One precedent that may be relevant: accepting a plan in plan mode already names the session from model-generated content. A model→title path therefore exists in the harness; this request is essentially to make it callable directly.

+1 — hit this exact wall today, with a concrete unattended use case and some test results that may save others time.

We run scheduled/unattended Claude Code sessions through a roadmap pipeline (claim → RFC → build → PR → review). The one participant that knows the pipeline state at each moment is the session itself — but it's the only one that can't put that state in the session list:

• set_session_title with the session's own id: Refusing to rename the current session from within itself.
• Same call from a spawned subagent: same refusal (the guard tracks the host session).
• session_id: "self": not supported — even though archive_session already has a self sentinel, so the concept exists in the server.

Why it matters for unattended fleets: auto-titles summarize the first prompt, so every scheduled run of the same routine gets an identical title, and a run that stops blocked on a human keeps its opening-prompt title — it reads as finished-clean in the session list, which is the worst possible failure mode for "does anything need me?".

Workarounds we tested, all dead ends:

• Cross-session renames work fine, but require another session to be running — an unattended run can't rely on that.
• Editing the desktop app's session-store JSON directly: races the app's in-memory flushes (same class as the revert in #52352).
• Plan-accept naming ("accepting a plan names the session from the plan content"): tested today in the desktop app — the accept updated the record's planPath but left title/titleSource: auto untouched, so it appears to be a CLI-surface feature; and the accept needed a human click anyway.

A self-capable rename (or lifting the self-restriction, opt-in via permission rule if impersonation is the concern) would let sessions surface pipeline state — e.g. 🤖🔴 <item> — BLOCKED: needs human — exactly where humans scan for it.