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

Environment: Claude Code CLI on Linux; repo with core.hooksPath deliberately pinned to the relative form .githooks.

Summary: Creating a worktree through Claude Code — the EnterWorktree tool or an Agent spawn with isolation: "worktree" — silently rewrites the shared .git/config's core.hooksPath from .githooks to the absolute /home/<user>/<repo>/.githooks. The config is shared by every worktree of the repo, and the change persists after the worktree is removed.

Repro:

1. git config core.hooksPath .githooks; confirm with git config --show-origin core.hooksPath.
2. In a Claude Code session, spawn any subagent with isolation: "worktree" (a trivial read-only task suffices), or call EnterWorktree.
3. Re-check: the value is now absolute, and .git/config's mtime matches the worktree-creation second.

Evidence from a controlled run: relative form restored and verified at 03:10:27; a deliberately trivial read-only probe agent spawned with isolation: worktree (its transcript contains no git-config commands at all); .git/config mtime jumped to 03:15:23.799 — the same second the worktree was created — with the value absolute again. Observed four times on this machine, each correlated with harness worktree creation; other writers (other sessions, root processes, docker binds) ruled out by sweep.

Impact: repos pin the relative form so hooks resolve identically across clones and worktrees and survive a checkout rename. The silent flip breaks that: an absolute path goes stale when the checkout moves, defeats hook-integrity guards that assert the pinned form, and turns any repo-level hook policy (make install-hooks, husky-style) into a restore treadmill.

Expected: worktree creation should not modify core.hooksPath — worktrees inherit the shared config and no rewrite is needed for hooks to resolve — or at minimum should preserve the existing value verbatim.