[BUG] `/rename` with no argument ignores the `language` setting and destroys the correctly-localized auto title

Summary

/rename with no argument actively destroys correct localization.

The auto-generated session title respects the language setting and produces a correct Japanese title. Then /rename — a different code path with a hardcoded English-only prompt — overwrites it with an English kebab-case slug, and takes display precedence over it. There is no setting, no CLAUDE.md rule, and no hook that can change this.

For every non-English user, the localization work that already shipped is silently undone by a single keystroke, and the only recovery is to type the title by hand.

This is not #72004. That issue is about the auto-title path, which reads language and works. This one is a path that was never wired into the language plumbing at all.

Repro

1. Set "language": "japanese" in ~/.claude/settings.json
2. Hold an entirely Japanese conversation
3. Observe the auto-generated title — correctly Japanese, e.g. 環境のcontext管理を評価する
4. Run /rename with no argument
5. Session renamed to: claude-code-version-check — English, kebab-case, and the Japanese title is now gone from the session list

Version: 2.1.220, native installer, Linux/WSL2. 100% reproducible.

Cause

The two titles come from two different generators, and only one of them knows the language setting exists.

Auto title — injects the setting into its prompt:

Write the title in ${language}. Keep technical terms and code identifiers in their original form.

with a fallback to "the predominant language of the session" when unset. Correct.

/rename with no argument — an entirely separate system prompt, with no language handling whatsoever:

Generate a short kebab-case name (2-4 words) that captures the main topic of
this conversation. Use lowercase words separated by hyphens.
Examples: "fix-login-bug", "add-auth-feature", "refactor-api-client",
"debug-test-failures". Return JSON with a "name" field.

Every example is English. kebab-case and lowercase words separated by hyphens are constraints that do not even have a meaning in Japanese, Chinese, Korean, Thai, or any non-alphabetic script — the model has no way to satisfy them except by translating the user's language into English. The setting is never read on this path, so the behavior is unconfigurable by construction.

Why this is worse than a cosmetic mismatch

Session-list display resolves in this order:

agentName || customTitle || aiTitle || summary || ...

/rename writes customTitle, which sits above aiTitle. So the failure is not "one title is in the wrong language" — it is a working feature being overwritten by a broken one. The user's action looks like a harmless refresh and is in fact destructive: the correctly-localized title is replaced and cannot be restored except by hand.

It is also invisible until it happens. Nothing in /rename's UI or its [name] argument hint suggests that omitting the argument will discard the localized title.

Expected

Either fix is small and self-contained:

1. Pass the same language instruction the auto-title prompt already builds into the /rename prompt, and drop or relax the kebab-case constraint when the target language is not alphabetic. The prompt-building code already exists a few functions away — it just is not called here.
2. Or: do not let /rename's generated name outrank a language-correct aiTitle at display time.

(1) is the real fix. (2) alone would at least stop the data loss.

The explicit form /rename <name> is fine and needs no change — the argument is stored verbatim, with no slugification.

Related

• #72004 — auto session title language. Related in symptom, different in cause: that path reads language; this one has no language handling at all. Fixing #72004 will not fix this, and users who work around it via the auto-title will still lose their title the first time they run /rename.