[FEATURE] Opt-in neutral naming for session worktrees and branches (topic-derived names expose past session subjects)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Session branches and worktree directories are named after the session's topic (claude/<topic>-<hash>, .claude/worktrees/<topic>-<hash>). These names are persistent, accumulate across sessions, and appear in every branch picker, IDE status bar, terminal prompt and git branch listing. There is no way to opt out.

For anyone using Claude Code on personal or confidential material, this turns the branch list into a permanent, screen-visible log of everything they have worked on. A few weeks of ordinary desktop use produced 29 such branches in one repository here, covering medical, financial, legal and third-party-personal subjects — all readable at a glance, none of them related to whatever is currently on screen.

Both naming schemes already ship, and neither can be selected

The same repository contains both:

claude/charming-diffie-fb108c <- neutral (adjective + surname)
claude/<topic>-5dcc63 <- topic-derived

So the neutral generator is not hypothetical — it is live product code, emitted alongside the topic scheme, with no user control over which one appears.

This is why this request and #85998 are not in conflict despite pulling in opposite directions. #85998 (filed 2026-08-12) asks for auto-created branches to be more descriptive and to follow the repository's documented CLAUDE.md convention, because random names are unidentifiable. This issue asks for them to be less descriptive, because topic-derived names are disclosive. Both users are asking for the same thing: a predictable choice instead of a coin flip.

Why this is a different argument from the ones already filed

#31969 and #85998 both want naming control for identifiability — a convenience, however real. This is a confidentiality requirement:

• Screen sharing, pairing, demos. Opening a branch picker discloses every past session subject at once.
• Persistence. Branches outlive their sessions. Cleanup is manual and easy to forget, so exposure grows monotonically.
• No opt-out. A user cannot decline the disclosure, only clean up after it.

Convention-matching can wait for a good default. Confidentiality cannot be served by any default, only by a switch.

Proposed Solution

A setting that selects the naming scheme, applying to both the worktree directory name and the branch name:

{
"worktree": {
"naming": "neutral" // "topic" (default) | "neutral"
}
}

"neutral" would use the adjective + surname generator that already exists as the fallback when no topic is known at creation time. No new naming mechanism is required — only that the existing one becomes selectable.

Two properties matter:

1. It must cover the branch name, not only the directory. The branch is the larger exposure: it appears in branch pickers, PR queues and git branch output, and it outlives the worktree that created it.
2. It must be settable at user scope, not only per project. The sensitive repositories are exactly the ones a user is most likely to forget to configure, so a global default is what actually protects.

A branchNameTemplate-style setting as proposed in #85998 would also satisfy this request, provided a template that resolves to no topic-derived component is expressible.

Alternative Solutions

• worktree.baseRef — the only documented worktree setting, and unrelated: it selects the base branch, not the name.
• A WorktreeCreate hook — can control the directory name, but replaces the default git logic wholesale, so base-ref resolution has to be reimplemented and .worktreeinclude is no longer processed. It also does not affect the branch name, which is the larger exposure.
• Manual pruning — deleting branches and worktrees after the fact. This is what I do today. It is after the fact by definition: the name was already on screen for the whole session, and the cleanup is easy to forget, so exposure accumulates between cleanups.
• Renaming after creation — git worktree move plus git branch -m. This breaks anything holding the path (open terminals, editors, the session's own working directory), and the harness has already chosen and used the original name by then.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. Monday: I use Claude Code on a medical document. The harness creates the branch claude/<medical-topic>-<hash> and the directory .claude/worktrees/<medical-topic>-<hash>.
2. Tuesday to Friday: four further sessions on unrelated subjects — finances, a legal question, two ordinary technical tasks. Each gets its own topic-derived branch.
3. The following week I share my screen to walk a colleague through a build problem.
4. The branch picker, the terminal prompt and the editor title bar now show subjects from all five sessions. The colleague sees a list of what I have been dealing with, none of it related to the build problem actually on screen.

I cannot prevent step 4 today. I can only delete branches afterwards, which does not help for the session I am currently in, and which I have to remember to do.

With "worktree": { "naming": "neutral" } set once at user scope, every one of those names would have been claude/<adjective>-<surname>-<hash>, and step 4 would disclose nothing.

Additional Context

Related issues

• #31969 — open, includes "configurable branch naming". Overlaps directly on mechanism. Happy for this to be folded in if maintainers prefer; filing separately because the confidentiality motivation is not raised there, and it leads to a different requirement: a neutral mode must exist, not merely a configurable one.
• #85998 — open, asks for the opposite default (branch names should follow the repository's documented convention). Cited above as evidence for a setting rather than a change of default.
• #79366 — open, worktree directories are reused across unrelated sessions, so a topic-derived directory name outlives its topic and displays an unrelated earlier subject for the whole life of every later session that leases it. That is a lifecycle fix and separate from this request, but it would remove one of the two exposure paths.

Environment

• Claude Code 2.1.222, desktop app 1.26832.0
• Windows 11