---

date: 2026-06-11 tags: [subagents, worktrees, orchestration, git] status: active graduated_to:

Worktree-isolated builders still leak into the main working tree — watch git status mid-flight

Symptom — while five worktree-isolated builders ran in parallel on epic #217, the main repo's working tree dirtied twice: composer.lock flipped its plugin-api-version, and three app/test files showed live edits matching one builder's in-progress work.

Root cause — worktree isolation quarantines git writes, not behaviour. Two leak paths: (1) a worktree has no vendor/ or node_modules/, so a builder that needs to run anything (tests, composer audit) works around it by copying files into — or directly editing — the main checkout where the toolchain lives; (2) any composer invocation in the main repo by a different composer build rewrites composer.lock metadata (plugin-api-version) as a side effect.

Fix — reconciled at integration: the stray edits matched the builder's committed work, so cherry-picking its commit made the main tree converge (then clean); the lockfile drift was discarded as an environment artifact before it could pollute the CI-gate builder's diff.

Guard — when running parallel worktree builders, treat the main tree as a shared resource: check git status between integrations, and diff any stray modification before discarding it (it may be a still-running builder's only copy of real work). Builder prompts should state where the runnable toolchain lives and that main-tree edits must end up committed in the worktree branch.