[RETRACTED — local hook confound] EnterWorktree branches from local branch instead of origin/<default-branch>

UPDATE / RETRACTION: The reproduction below is confounded and does not provide valid evidence of a Claude Code product bug. This repo has a custom WorktreeCreate hook (a local script the user's own repo registers in settings.json) that, per Claude Code's own documented hook contract, fully replaces default worktree-creation behavior. That hook's own git worktree add -b <branch> <path> call omits the starting-point ref, which git defaults to the current HEAD of the primary checkout — this alone fully explains every symptom described below, with no need to invoke any defect in Claude Code's internal EnterWorktree resolution logic. Since the hook overrides default behavior entirely, this report can't confirm or rule out whether Claude Code's own unhooked resolution has a related issue — it just isn't valid evidence either way. Closing this issue as a local-configuration confound, not a product bug. The independent reports at #82364, #83375, #83349, #77671, and #75045 (filed by other users, presumably without this specific hook) are unaffected by this correction and may still represent a genuine separate issue worth tracking on their own evidence. Original report preserved below for transparency.

---

Preflight Checklist

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

What's Wrong?

EnterWorktree branches the new worktree from the repo's current local
branch instead of origin/<default-branch>, even when worktree.baseRef
is unset (default should be "fresh").

In one repo, across one background session, every EnterWorktree call
branched from the local branch — 4 for 4, including the very first call
of the session, made before worktree.baseRef was ever touched. Confirmed
unset via jq '.worktree' ~/.claude/settings.json → null (checked both
global and project-level settings).

This wasn't a one-off: a second, fully independent Claude Code session
running concurrently in the same repo hit the identical misbehavior. Its
worktree also branched from an unpushed local feature branch instead of
origin/main, and it built substantial new work (a Postgres adapter + CLI
binary, several hundred lines across ~6 files) on top of that unintended
base, then merged it directly to main. Untangling the resulting divergent
git history required a multi-PR reconciliation afterward.

Reproducing independently in two different concurrent sessions in the same
repo suggests this isn't a rare race condition local to one process — it
looks like a consistent resolution bug tied to specific repo/session
conditions (see Steps to Reproduce).

What Should Happen?

With worktree.baseRef unset/default ("fresh"), EnterWorktree should
branch from origin/<default-branch> — per the tool's own documented
default behavior ("branches from origin/<default-branch> for a clean tree").

Error Messages/Logs

None — this is a silent misbehavior, not a crash or visible error. The
worktree is created successfully; it's just based on the wrong branch. Only
caught via manual verification (`git log --oneline -3` / `git branch
--show-current` immediately after EnterWorktree, and later `git log -1
<first-commit-on-worktree>^` to confirm the parent commit).

Steps to Reproduce

1. In a git repo with a Forgejo or GitHub remote, check out a local branch

other than the default branch (e.g. feature-x) — one that is ahead of
origin/<default-branch> and, ideally, not yet pushed to the remote at
all (no origin/feature-x exists yet).

1. Start a Claude Code background session (claude --bg / job-based) in

that repo, on that checked-out branch.

1. Without setting worktree.baseRef anywhere (confirm via

jq '.worktree' ~/.claude/settings.json and the project's
.claude/settings.json — both should be null/unset), call the
EnterWorktree tool.

1. Inside the resulting worktree, run git log --oneline -3 and

git branch --show-current.

Expected: worktree is based on origin/<default-branch>.
Actual: worktree is based on the local feature-x HEAD from step 1.

This reproduced on 4 consecutive EnterWorktree calls in one session
(including the first, made before any baseRef setting was touched), and
independently in a second concurrent background session in the same repo.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Claude Model

Sonnet 5 (claude-sonnet-5)

Is this a regression?

Unknown — first encountered this session, no earlier-version baseline to
compare against.

Last Working Version

N/A (not confirmed as a regression)

Claude Code Version

2.1.220

Platform

Direct Anthropic API (ANTHROPIC_BASE_URL=https://api.anthropic.com, not
Bedrock/Vertex/claude.ai)

Operating System

macOS 27.0 (build 26A5388g), Darwin 27.0.0

Terminal/Shell

N/A — this occurred in a background session (job-based,
$CLAUDE_JOB_DIR), not an interactive terminal at all. Worth stating
explicitly, since background-session EnterWorktree may follow a
different code path than interactive --worktree usage — that's
plausibly the actual differentiator here, not the shell.

Additional Information

The repo's own remote is Forgejo-hosted, not GitHub — likely irrelevant to
the bug, noting in case remote type affects origin/HEAD resolution.

Suspected mechanism: "fresh" mode's origin/<default-branch> resolution may
have a fallback path that prefers the current local branch when that
branch is ahead of / diverged from / not yet pushed relative to
origin/<default-branch>, and/or this fallback may be specific to
background-session worktree creation. Would help to know whether that
fallback is intentional, and whether there's a way to force strict
origin/<default-branch> resolution regardless of local branch state.