[FEATURE] Add settings.json key to default worktree-exit prompt to "keep"

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested in this exact form
• [x] This is a single feature request

Problem Statement

The current worktree-cleanup behavior at session end has two failure modes for a user whose answer is always "keep":

1. Loud failure (the prompt): when changes or commits exist, the harness prompts keep-or-remove. Default is "keep", so an accidental Enter on /exit plus the prompt confirmation leaves the worktree intact, which is fine for me. But the prompt fires every single time and the answer is invariant. Dozens of times per week per worktree-heavy user.

1. Silent failure (auto-remove on clean): when the harness considers the worktree "no changes" (per the docs), it removes the worktree and its branch automatically with no prompt and no signal. The doc wording (No changes: the worktree and its branch are removed automatically vs Changes or commits exist: Claude prompts) is ambiguous about whether a committed-then-clean worktree (commit done, working tree clean) is treated as "no changes" or "commits exist". If the former, a user who committed work and ran /exit can lose the worktree silently with zero recovery path. This is the load-bearing reason a "never auto-clean" mode is needed: the prompt is the visible part of the problem, the silent auto-remove is the dangerous part.

There is currently no way to set a default for either branch. The only escape hatches are:

• -p non-interactive mode, which skips both branches but is not how interactive sessions are run.
• WorktreeRemove PreToolUse hooks with exit 2, which (a) is overkill for "I just want a default", (b) was reported in #56349 to silently bypass the prompt path and cause data loss in some configurations.

Proposed Solution

A new key in settings.json:

{
  "worktree": {
    "removeOnExit": "never"
  }
}

Values:

• "prompt" (current behavior, default): prompt when changes or commits, silently auto-remove when clean.
• "never": never remove on exit, ever. No prompt, no silent auto-remove, regardless of dirty/clean state. The worktree always persists, removal is a manual git worktree remove decision.
• "ifClean": keep current implicit auto-remove when no changes, prompt otherwise. Same as "prompt" but named explicitly so the silent branch is opt-in rather than opt-out.
• "always": always remove, no prompt, no exception. For users with the opposite preference.

The key point is that "never" covers both branches: it must override the silent auto-remove just as much as the explicit prompt. A setting that only suppressed the prompt while leaving the silent auto-remove in place would still be a data-loss vector for committed-then-clean worktrees.

This is a per-user setting in ~/.claude/settings.json, also overridable at project or local scope per the standard hierarchy.

Alternative Solutions

• Current workaround: answer "keep" by hand every time the prompt fires, and hope the silent auto-remove never triggers on a committed-then-clean worktree. The hope part is not a real workaround.
• WorktreeRemove hook with exit 2: doable today via a shell hook, but it's a heavy lever for an inversion-of-default that should be a one-line setting. Also see #56349 for a report that this path silently fails in some configurations.
• Issue #31969 point 3 asks for a flag on EnterWorktree to opt out of the prompt for plugin authors. Same root mechanic, but framed inside the plugin/tool-arg axis. A settings.json key is the right granularity for users who simply prefer "keep" as their default, no plugin involved.

Priority

Low for the prompt-noise dimension (friction, not a blocker). Medium for the silent-auto-remove dimension if "no changes" includes "committed then clean", because that's an actual data-loss path with no recovery.

Feature Category

Configuration and settings.

Use Case Example

Two scenarios this would fix.

Scenario A (prompt noise, current workaround works):

1. claude --worktree feat-new-api from a project root.
2. Do focused work, commit on the worktree branch.
3. /exit to end the session, intending to come back tomorrow (PR not yet opened, code not yet reviewed).
4. Prompt appears: keep or remove?
5. Answer "keep" (always). Repeat across 5 to 10 worktrees per day.

Scenario B (silent auto-remove, no workaround exists today):

1. claude --worktree feat-quick-fix.
2. Make a one-shot change, commit it, working tree is now clean.
3. /exit.
4. Depending on how the harness interprets "no changes", either the prompt appears (safe) or the worktree and its branch are removed automatically with no signal (data loss). The doc does not make the distinction explicit.

With "worktree.removeOnExit": "never", both scenarios collapse to: the worktree persists until the user runs git worktree remove manually. The cost of an accidental remove (replay the implementation, replay the review) massively exceeds the cost of a manual cleanup when the user genuinely wants the worktree gone.

Additional Context

Related issues (none cover this exact ask, especially the silent-auto-remove branch):

• #26725 wants stale worktrees better cleaned up. Opposite axis: that issue complains about under-removal, this one complains about over-removal (silent and prompt-driven) for users whose intent is always "keep".
• #53720 (closed as dup of #26725) wanted the default flipped to "remove". Same surface, opposite preference. A configurable key serves both camps.
• #31969 (open) point 3 asks for a per-call opt-out via a tool arg, scoped to plugin authors. Complementary to a global settings key, not a substitute.
• #56349 (closed as dup) reports that WorktreeRemove hook-based blocking can silently fail, reinforcing the need for a first-class setting rather than a hook hack.

A clarification PR on the worktree docs to make the "no changes" definition explicit (does it include committed-then-clean?) would also be valuable independent of this feature request, since today the doc forces users to test empirically to know what their worktrees do on exit.