claude-code - 💡(How to fix) Fix [BUG] Worktree branch prefix preference (ccBranchPrefix) ignored in v2.1.156 — hardcoded claude/MMDD- used

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

Worktree branch prefix preference (ccBranchPrefix) is ignored in v2.1.156. Worktrees are created with a hardcoded claude/MMDD- prefix instead of the configured value.

Environment

• Claude Code Desktop: v2.1.156
• macOS

Steps to reproduce

1. Open Settings → Claude Code → Branch prefix and set it to a custom value (e.g. nh7a).
   • This is stored as ccBranchPrefix in ~/Library/Application Support/Claude/claude_desktop_config.json.
2. Create a new worktree.
3. Inspect the actual git branch on disk and the entry in ~/Library/Application Support/Claude/git-worktrees.json.

Expected

• Git branch: nh7a/<worktree-name>
• JSON record: "branch": "nh7a/<worktree-name>"

Actual (v2.1.156)

• Git branch: claude/0529-<worktree-name> (hardcoded claude/MMDD- prefix, ccBranchPrefix ignored)
• JSON record: "branch": "<worktree-name>" (prefix stripped entirely from record), plus new fields "hookBased": true, "fromCommittableTier": true

Evidence from my machine

Likely cause

The new hookBased / fromCommittableTier worktree-creation code path does not read ccBranchPrefix from preferences and instead hardcodes claude/MMDD- as the branch prefix.

Impact

Users with a configured branch prefix (e.g. matching their personal Git convention) must manually rename every new worktree branch before pushing, or end up with claude/-prefixed branches on the remote.

What Should Happen?

With "Branch prefix" set to a custom value (e.g. nh7a) in Settings → Claude Code, every new worktree should create its git branch using that prefix — nh7a/<worktree-name> — and the same value should appear in the branch field of ~/Library/Application Support/Claude/git-worktrees.json. The ccBranchPrefix preference should be honored by all worktree-creation code paths, including the new hookBased / fromCommittableTier path; the literal claude/MMDD- prefix should never be used when a custom prefix is configured.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code Desktop (v2.1.156).
2. Go to Settings → Claude Code → Branch prefix. Set it to a custom value, e.g. nh7a. Close Settings.
3. Verify the preference was saved: cat "~/Library/Application Support/Claude/claude_desktop_config.json" | grep ccBranchPrefix Expected output: "ccBranchPrefix": "nh7a"
4. Open any local git repo in Claude Code Desktop.
5. Create a new worktree (e.g. via the "+" / new session with worktree enabled, or the worktree-create action). Let Claude Code auto-generate the worktree name (e.g. mystifying-wright-4b3046).
6. In a terminal, inspect the actual branch checked out in the new worktree: cd <repo>/.claude/worktrees/<worktree-name> git rev-parse --abbrev-ref HEAD
7. Inspect the worktree record: cat "~/Library/Application Support/Claude/git-worktrees.json" | python3 -m json.tool | grep -A6 "<worktree-name>"

Observed (bug):

• Step 6 prints: claude/0529-<worktree-name> ← hardcoded claude/MMDD-, ignores ccBranchPrefix
• Step 7 record contains: "branch": "<worktree-name>", "hookBased": true, "fromCommittableTier": true

Expected:

• Step 6 prints: nh7a/<worktree-name>
• Step 7 record contains: "branch": "nh7a/<worktree-name>"

Note: For comparison, a worktree created on 2026-05-28 in the same repo with the same ccBranchPrefix=nh7a setting was correctly named nh7a/lucid-pike-502de7 and its JSON record contains "branch": "nh7a/lucid-pike-502de7" (no hookBased field). The regression appears tied to the new hookBased / fromCommittableTier worktree-creation path introduced in v2.1.156.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.156

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response