Recurring core.bare=true corruption of the main repo

[vivek7405]

Problem

During multi-step sessions the main repo's local core.bare config flips to true, after which any git operation that needs a work tree fails with fatal: this operation must be run in a work tree (checkout, add, commit, branch creation all break). It recurred 5+ times in one session and needed repairing with git config core.bare false each time. Nothing is lost on GitHub (commits and branches are pushed and safe); only the LOCAL checkout is corrupted, but it interrupts every git step until repaired.

Design / approach

The flip correlates with two reproducible triggers:

1. npm install (notably npm install --package-lock-only) flipped core.bare to true mid-operation, surfacing as a failed git add immediately after.
2. Spawning worktree-isolated subagents (the review subagents under .claude/worktrees/agent-*).

Diagnostics gathered:

• The repo carries multiple long-lived worktrees (webjs-prefetch, webjs-testgate), both valid.
• extensions.worktreeConfig is NOT enabled.
• The root package.json prepare runs git config core.hooksPath .hooks, yet the live core.hooksPath ends up reset to the absolute default (.git/hooks), suggesting git-config writes from a worktree or workspace context land on and reset the shared .git/config, the same surface where core.bare lives.

Hypothesis: git-config writes from inside a linked worktree (or from npm running a workspace lifecycle script while worktrees are registered), without extensions.worktreeConfig enabled, bleed into the shared config and reset core.bare (and core.hooksPath).

Candidate mitigations to evaluate:

• Enable extensions.worktreeConfig true so per-worktree config writes cannot touch shared config.
• Make the root prepare hook's git config write worktree-safe and idempotent, scoped so it cannot reset shared core.* keys.
• Keep a guard/repair as a backstop (the Claude Code skill already runs git config core.bare false around git ops); the durable fix should remove the need.

Acceptance criteria

• Root-cause the exact write that flips core.bare (instrument git-config writes during npm install and a worktree spawn)
• core.bare stays false across npm install and worktree subagent spawns with multiple worktrees registered
• A regression check (script or doc) catches a reintroduction

[vivek7405]

Root cause found (and fixed)

The recurring core.bare / HEAD-moving corruption traces to a stray core.worktree entry in the shared .git/config that pointed at a /tmp path, misdirecting every linked worktree (including other checkouts). Once that entry exists, worktree operations and npm lifecycle git calls resolve against the wrong location and flip shared core.* keys.

It has been removed from .git/config, and the repo is healthy again (core.bare=false, no core.worktree, extensions.worktreeConfig=true). The extensions.worktreeConfig true mitigation from this issue is complementary belt-and-suspenders, but the stray core.worktree was the trigger.

Remaining durable-fix question for this issue: should the repo guard against a stray core.worktree being introduced in the first place (e.g. the worktree-spawn tooling writing it), or is removing it plus extensions.worktreeConfig enough to close this out? Leaving open for that decision.