Problem
worktree_providers.dmc.commands in Homeboy config can point at a disposable task worktree with nothing validating that the path is stable.
Found in a live config, in 9 separate command entries:
/Users/<user>/Developer/wp-coding-agents@fix-475-opencode-json-preamble/scripts/homeboy-dmc-provider.php
That branch was already merged. The worktree survives only until cleanup runs. When it goes, every DMC worktree operation — resolve_identity, attest_safety, resolve, resolve_task, converge, plan, cleanup — breaks at once, because all of them route through that one path.
This is the control plane's own worktree provider depending on a worktree that the control plane is entitled to delete.
Contributing factor
The primary checkout was simultaneously 6 commits stale, so pointing at the primary would have silently used an older adapter. workspace show reported the commit but left the freshness and behind columns empty, so staleness was not obvious without comparing against origin/main by hand.
Expected
Validate that configured provider command paths resolve to a stable location (primary checkout or an installed release), and refuse or warn when they resolve inside a task worktree. Ideally the setup path writes the stable path in the first place.
Surfacing primary staleness in workspace show / workspace hygiene would remove the reason to reach for a worktree path at all.
Filed with AI assistance: Claude Sonnet 4.5 via opencode. Found while diagnosing a converge failure; the stale-primary and worktree-pinned-config conditions were both confirmed against live repository state.
Problem
worktree_providers.dmc.commandsin Homeboy config can point at a disposable task worktree with nothing validating that the path is stable.Found in a live config, in 9 separate command entries:
That branch was already merged. The worktree survives only until cleanup runs. When it goes, every DMC worktree operation —
resolve_identity,attest_safety,resolve,resolve_task,converge,plan,cleanup— breaks at once, because all of them route through that one path.This is the control plane's own worktree provider depending on a worktree that the control plane is entitled to delete.
Contributing factor
The primary checkout was simultaneously 6 commits stale, so pointing at the primary would have silently used an older adapter.
workspace showreported the commit but left thefreshnessandbehindcolumns empty, so staleness was not obvious without comparing againstorigin/mainby hand.Expected
Validate that configured provider command paths resolve to a stable location (primary checkout or an installed release), and refuse or warn when they resolve inside a task worktree. Ideally the setup path writes the stable path in the first place.
Surfacing primary staleness in
workspace show/workspace hygienewould remove the reason to reach for a worktree path at all.Filed with AI assistance: Claude Sonnet 4.5 via opencode. Found while diagnosing a converge failure; the stale-primary and worktree-pinned-config conditions were both confirmed against live repository state.