Slash-command session titles ignore command args, and command-launched sessions cannot name themselves

Summary

When a session is launched by typing a slash command as the first message, the generated session title ignores <command-args> and is derived mostly from the command name. Every session started with the same command therefore gets the same title, and because the same generator output also names the worktree, the same generic worktree name too.

A namespaced plugin command makes it worse than an unnamespaced one: the plugin-qualified name appears to dominate, so the arguments (which carry the only distinguishing information) are dropped.

Environment

• Claude Code desktop app, CLI 2.1.233, macOS.
• The commands below are plugin skills invoked as the first message of a new session.

Observed

| First message (command-name + command-args) | Generated title |
| --- | --- |
| /myplugin:implement-phase + @docs/plans/2026-08-17-worktree-project-root-resolution.md 1 | Myplugin implementation phase |
| /myplugin:implement-phase + @docs/plans/2026-08-17-worktree-project-root-resolution.md 2 | Myplugin implementation phase |
| /implement-phase (same command, unnamespaced) + @docs/plans/2026-08-15-managed-pre-commit-format-hook.md 2 | Managed pre-commit format hook |
| /review-pr + 59 | PR #59 review |

Rows 1 and 2 are different work (phase 1 and phase 2 of one plan) and are indistinguishable in the session list. Row 3 shows the arguments can drive a good title. Note that even there the phase number is dropped, so two phases of one plan still collide.

Expected

The title (and the generated branch/worktree name) reflect the arguments, since for a command launch that is where the specific work is named. Something like "Phase 2: worktree project root resolution" rather than the command's own name.

Why this cannot be worked around today

I spent a while establishing this, so in case it is useful:

1. A skill cannot rename its own session. The session-management rename tool requires a session_id and rejects the current session.
2. There are two separate title stores. The CLI appends custom-title records to the transcript in ~/.claude/projects/<project>/<sessionId>.jsonl; that is what the CLI session picker reads and what /rename writes. The desktop app keeps its own per-session JSON under ~/Library/Application Support/Claude/claude-code-sessions/<install>/<workspace>/local_<uuid>.json with title and titleSource, and that is what the desktop session list shows.
3. A hook reaches the first store only. hookSpecificOutput.sessionTitle works, on SessionStart and UserPromptSubmit, and writes a custom-title record. The desktop record is unaffected: in one test a live CLI process held a hook-applied title while its desktop record kept the original, unchanged.
4. And the desktop store is set before the CLI session exists, since the same generated title also names the worktree, which must exist before Claude Code starts inside it. So no hook can influence the name a desktop session is created with.

Requests

1. Include <command-args> in title and branch generation for command-launched sessions. This is the actual fix and it affects every namespaced plugin command, not one plugin.
2. Give a command-launched session a supported way to name itself: either have the desktop store honour a hook-supplied sessionTitle, or provide an equivalent that runs early enough to matter.
3. Document hookSpecificOutput.sessionTitle. It is absent from the hook-output schema the CLI itself prints for hook authors (which lists additionalContext and friends), yet it is read for SessionStart and UserPromptSubmit. Two things that cost me a while and would be worth stating explicitly:

• it must be nested inside hookSpecificOutput; a top-level sessionTitle is ignored silently, so a wrong shape is indistinguishable from an unsupported version;
• it overrides an existing title, with no untitled-only guard, so a hook that fires on every prompt will rename sessions the user named by hand. An opt-in "only if untitled" would make this safe to use.