Worktree creation rewrites the repo's shared core.hooksPath to an absolute path

Reproduced on Windows 11, on two installs: standalone CLI 2.1.236 (~/.local/bin, native installer) and the Desktop-app-embedded CLI 2.1.234 (%APPDATA%\Claude\claude-code). Adding the pieces this issue doesn't have yet: where the write comes from in the bundle, a live capture of the flip, and a nastier variant when the creating session runs in a secondary worktree.

Where it happens (from the shipped bundle, both versions):

resolve(e,s), s!==a) { let {code:u, stderr:d} = await ko(No(), [...Zs, "config", "core.hooksPath", a], {cwd:t, env:Hm()});
if (u===0) w(`Configured worktree to use hooks from main repository: ${a}`)

The routine resolves the main repo's core.hooksPath to an absolute path (a), compares it with the worktree's effective value (s), and writes on mismatch. Two problems compound:

1. With a relative core.hooksPath (the portable form), s resolves against the new worktree while a resolves against the main tree, so s !== a is always true and the rewrite fires on every worktree creation.
2. The write runs git config core.hooksPath <absolute> with cwd in the new worktree but without --worktree, so it lands in the shared $GIT_COMMON_DIR/config and changes hook resolution for the main tree and every other worktree at once.

Live capture (FileSystemWatcher on .git, EnterWorktree issued from a session):

[08:28:03.767] Created config.lock
[08:28:04.011] shared config changed: '.githooks' -> 'C:\work\repo\.githooks'

Control: plain git worktree add on the same repo creates no config.worktree and leaves the shared config untouched. The transcript of the creating session contains no git-config commands; the write is the harness's own.

Secondary-tree variant (worse than a broken guard): if the creating session runs in another worktree of the same repo (e.g. a deploy tree at C:\work\repo-deploy sharing the same .git), the absolute path written points at that tree's .githooks. New agent worktrees then execute hooks from a different checkout, potentially a different revision, of the hooks. On this machine 22 of 98 registered worktrees were also born with an absolute core.hooksPath seeded into their per-worktree config.worktree, 2 of them pointing at the deploy tree.

Suggested fix: write with --worktree (enabling extensions.worktreeConfig if needed), or keep the original relative value, or skip entirely when the repo-level value already resolves correctly per-worktree, which is exactly what a relative core.hooksPath does.

Likely same root cause as #72714 and #27474.

Independent Linux confirmation on Claude Code 2.1.220: in a repository that deliberately sets core.hooksPath=.githooks, Claude-managed linked-worktree creation repeatedly changed the shared value to an absolute path. In a heavily concurrent agent workflow, this can make one worktree execute hook files from a different checkout and therefore a different revision.

Additional observations

• The repository regularly had many Claude-managed linked worktrees. During investigation, extensions.worktreeConfig was unset while 203 linked worktrees still existed. Concurrent setup and cleanup make that state unstable, but the bundle evidence already recorded on this issue identifies the more direct defect: the hooks-path write lacks --worktree, so a plain git config core.hooksPath ... targets shared configuration regardless of the invoking worktree.
• The installed 2.1.220 bundle contained the same worktree-setup path and the log string Configured worktree to use hooks from main repository: described above.
• Worktree-creation timing correlated with the recurring absolute-path rewrite. A controlled live race was deliberately avoided because changing shared hook configuration while other worktrees were active could weaken their safeguards.
• A package-install hook repeatedly repaired the value to relative .githooks, which masked the recurrence: the setting appeared to fix itself and then drifted again on later worktree creation.
• The practical impact was not only portability. With an absolute path, linked worktrees can run the main checkout's hook revision instead of their own. For repositories whose hooks enforce push destinations, commit identity, secret scanning, or other safeguards, that is a safety and correctness boundary.

The local mitigation is to detect and restore the required relative value, but that only narrows the exposure window. Preserving a valid relative value—or making any necessary propagation explicitly --worktree-scoped without racing repository-wide worktree configuration—is still the needed upstream fix.

Still reproducing on Claude Code 2.1.228 (macOS 26.5.2, git 2.50.1 Apple Git-155) — adding a second platform, a forensic timeline from a multi-session repo, one new diagnostic detail that may localize the fix, and a userland mitigation for affected repos.

Fresh controlled repro (twice, same-second correlation): with the shared config verified at core.hooksPath = .githooks, a single EnterWorktree call flipped the shared .git/config to core.hooksPath = /Users/<user>/<repo>/.githooks within the same second, both times. The probe worktrees were used for nothing else. ExitWorktree (action: remove) deletes the worktree and branch but does not restore the value — explicitly checked after exit, still absolute.

New diagnostic detail — two creation flows write to two different scopes:

• EnterWorktree (and, per the original report, Agent with isolation: "worktree") writes the absolute value into the shared .git/config — the harmful case, since it mutates state for the main checkout and every other worktree.
• The desktop "start suggested task in a fresh worktree" flow instead writes it worktree-scoped: .git/worktrees/<name>/config.worktree gets core.hooksPath = <abs> plus core.longpaths = true (observed on several worktrees, each file's mtime matching that session's start to the second; that variant is #88747). This flow does not clobber the shared config.

So a correctly-scoped write path already exists in the product; routing the EnterWorktree path through the same worktree-scoped write (or simply not touching hooksPath at all — the relative value resolves fine in linked worktrees when the hooks dir is committed) would fix the shared-config clobber. Related open reports of the same class, for dedupe: #72714, #27474 (shared config), #88747 (worktree-scoped variant).

Measured impact in a repo where many sessions share one clone: our ship gate asserts the pinned relative form. Over ~2 weeks it flapped in a dozen+ sessions' transcripts; on one day alone we restored the value three times and each regression correlated with a harness worktree creation (one at 09:19:06Z landed inside a 24-minute window bounded by two gate readings — pass before, fail after). Every session that used a worktree silently broke the gate for all sessions that followed.

Userland mitigation until this is fixed, for anyone whose hook-policy check is flapping: accept an absolute value only when it resolves to exactly <main-checkout-root>/.githooks, deriving the root from git rev-parse --path-format=absolute --git-common-dir (parent dir). That stays machine-correct — on any other machine the stored absolute no longer equals that machine's root, so the portability warning still fires where it is real — and keeps foreign/absolute-to-.git/hooks values failing:

function isEquivalentHooksPath(configured, mainRoot) {
  if (!configured || !mainRoot || !path.isAbsolute(configured)) return false;
  return path.resolve(configured) === path.join(mainRoot, ".githooks");
}

Expected behavior (agreeing with the OP): worktree creation should not modify the shared core.hooksPath; if the product needs a per-worktree value, git config --worktree is the right scope — and exit/removal should leave no residue either way.