Worktree isolation (Agent/Workflow) forks from the default branch, not the current branch — wastes agent fan-outs on a divergent base

Summary

Spawning sub-agents with isolation: "worktree" (via the Agent tool or Workflow builder agents) creates the git worktree from the repository's default-branch lineage rather than the currently checked-out HEAD. When the working branch carries commits not yet on the default branch, every builder starts from a base that is missing the very work it was told to build on top of.

Severity: High — silent token waste, and a real risk of silently-wrong output.

Environment

• Working branch (e.g. dev) is ahead of and divergent from the default branch (e.g. master) — it carries feature/migration commits not yet merged to the default.
• origin/HEAD points at the default branch.

Steps to reproduce

1. In a repo where the working branch is ahead of / divergent from the default branch, and origin/HEAD → the default branch.
2. Check out the working branch. Confirm git rev-parse HEAD is its tip.
3. Invoke a Workflow whose builder agents use isolation: "worktree" (or a single Agent call with isolation: "worktree").
4. Inspect the created worktree's HEAD.

Expected

The worktree is cut from the session's current HEAD (the working-branch tip).

Actual

The worktree HEAD is on the default-branch lineage. git merge-base --is-ancestor <current-HEAD> <worktree-HEAD> returns false in both directions — the worktree is on a divergent lineage, not merely behind. Recent commits on the working branch are absent from it.

Impact

• A 17-agent fan-out all detected the wrong base and aborted with zero output — a large batch of tokens spent for nothing.
• Builders that do not self-check their base would produce code against stale state — silently wrong, and hard to catch downstream.
• Observed recurring across multiple sessions, not a one-off.

Root-cause hypothesis

The worktree base appears to resolve from origin/HEAD / the configured default (main) branch instead of the session's current HEAD/branch. Please verify the base-selection logic uses git rev-parse HEAD (current checkout), not the default branch.

Secondary issue

Worktrees created during aborted/failed runs are not auto-cleaned when they contain untracked artifacts (e.g. a node_modules/ directory), so stale worktrees and their worktree-* branches accumulate across sessions and require manual git worktree prune + directory removal + branch deletion.

Suggested fixes

1. Cut worktrees from the current HEAD, not origin/HEAD / the default branch.
2. Have each spawned worktree assert its base is a descendant of the parent session's HEAD, and fail loudly (actual-vs-expected SHA) if not — instead of silently proceeding.
3. Reliably clean up worktrees on run abort/failure regardless of untracked artifacts.

Workarounds found

• Run the fan-out in the main working tree with disjoint write-sets (no isolation: "worktree") — a DAG that guarantees non-overlapping files makes isolation unnecessary.
• Or git remote set-head origin <working-branch> before spawning worktree-isolated agents (unconfirmed as a complete fix).