Config-driven automatic session naming with a per-project/org prefix

What I'm trying to do

I work across several projects and want sessions to be named automatically and consistently, with a per-project/org prefix so related sessions group together and are easy to scan (e.g. every session opened in a github.com/rook/* checkout gets a rook- prefix: rook-support-matrix, rook-flake-campaign, …).

Today the only reliable path is manually typing /rename in each session. Instructions in CLAUDE.md can't accomplish this: CLAUDE.md steers the model's use of available tools, but there is no tool/command the model can invoke to rename the current session, and naming happens at the harness level, not via model output.

Proposed feature

A declarative, config-driven session-naming policy. Some combination of:

1. A per-project/global prefix setting in settings.json, e.g.:

``jsonc
{
"sessionNaming": {
"prefix": "rook-" // prepended to the auto-generated title
}
}
`
Project-level .claude/settings.json` would let each repo set its own prefix without touching global config.

1. Auto-naming on by default (derive a title from early conversation context) with the prefix applied, so the session is named without manual /rename.

1. Optionally, a template ("format": "{prefix}{summary}") for users who want more control.

Relationship to existing issues

• #34243 (OPEN) — "Allow programmatic session rename from skills/commands" is the enabling primitive; a config-driven policy could build on the same rename mechanism.
• #55952 (closed, not-planned/stale) — "Native project-prefix session titles" requested essentially the prefix piece.
• #24937 / #25133 (closed as duplicate) — "Customizable conversation title format" / "customize titles via CLAUDE.md or settings".

These were all closed as stale or duplicate; the auto-close bots invited a fresh issue referencing them, which is what this is. Consolidating the prefix + auto-naming + config-driven angle into one request.

Why settings/harness rather than CLAUDE.md

CLAUDE.md is the wrong layer: it's loaded mid-session and only guides model behavior with existing tools. Session naming is a harness concern, so a settings-level (or harness) mechanism is the dependable home for it.