Agent tool `isolation: "worktree"` dispatch may corrupt parent repo `core.bare` flag

Observation

After dispatching a subagent via the Agent tool with isolation: "worktree" parameter, the parent repository's .git/config contained core.bare = true. This rendered the primary worktree inoperative:

• git worktree list showed (bare) next to the primary worktree path
• git status failed with fatal: this operation must be run in a work tree
• Read-only commands (git rev-parse HEAD, git branch --show-current) continued to work
• git fsck reported HEALTHY (objects + index intact)

Environment

• Claude Code CLI: as of 2026-04-22
• OS: Linux Ubuntu 24.04
• Repository: standard (non-bare) multi-worktree setup (primary + one secondary at time of dispatch)

Timeline

1. Parent .git/config initially had no core.bare entry. git worktree list at session start showed normal branch output (primary in attached state at HEAD @ 095f12315e27)
2. Two subagent dispatches with isolation: "worktree" executed in quick succession within the same CC session. Workloads performed inside the isolated worktrees:

• Dispatch 1: git checkout -b, file creation, bash scripts/safe-commit.sh (commit succeeded)
• Dispatch 2: same as above + bash scripts/write-review-marker.sh + npm install (142 packages, needed because subagent worktree lacked node_modules) + vitest test runner execution + git push (blocked at pre-push hook)

1. After dispatch 2, parent cleanup via git worktree remove --force /home/adminaag/agentant/.claude/worktrees/agent-<uuid>
2. Subsequent commands in parent shell: git status failed; git worktree list showed parent as (bare); .git/config contained core.bare = true

Recovery

git config --unset core.bare restored normal operation. No data loss. Working tree content intact.

Impact

Even though recovery is trivial once identified, the corruption is severe:

• Any repo-level git operations fail silently in interactive sessions that follow the corruption
• In a multi-worktree setup (common for parallel CC-session workflows where the primary worktree is where most work happens), this breaks the entire primary session context
• No error is emitted during the dispatch itself — the problem surfaces only on the next normal git command, which may be minutes or hours later

Not reproduced after initial observation

I deliberately did not attempt to reproduce this after the initial cleanup, to avoid risking repeated parent corruption in a production-adjacent development environment. Reproducer pattern (if attempted in a throw-away repo):

1. From a CC session in a normal git repo with at least one secondary worktree, dispatch Agent({isolation: "worktree", prompt: "..."}) twice
2. Subagent 1 workload: git checkout -b <branch>, write a file, safe-commit
3. Subagent 2 workload: same as 1 + npm install + vitest run + git push (any failing condition at pre-push is fine)
4. Parent cleanup: git worktree remove --force for each subagent worktree
5. Parent check: git worktree list and grep bare .git/config

Related observations during the same session

Two other issues surfaced in the isolated worktree context (may or may not be related to the main core.bare issue):

1. node_modules not bootstrapped: the isolated worktree had no node_modules directory, forcing the subagent to run npm install before any test or script that required dependencies
2. Test subprocess core.hooksPath inheritance: within the isolated worktree, test subprocesses that did git init in a /tmp/sandbox (for vitest) inherited the parent repo's absolute core.hooksPath pointer, causing hook scripts to be invoked with relative paths that failed to resolve against the /tmp sandbox. Same test code passes from the user's primary or secondary (git worktree add-style) worktrees.

These three observations together made isolation: "worktree" unusable for our production workflows. We have adopted a separate CC session per tmux window pattern (git worktree add + parallel claude processes) which avoids all three issues.

Suggested direction

Whatever Agent tool path performs subagent worktree setup/teardown should:

1. Either fully isolate the subagent's git operations from the parent's .git/config
2. Or document precisely which config mutations can propagate upward
3. On cleanup, restore the parent to a known-good state rather than leaving core.bare = true behind

I'm happy to provide more detail or help debug further — the initial incident is captured in a local memory record (can share context on request). The concern is primarily about silent corruption, not the specific flag.