Summary

Two related gaps exist in the worktree isolation layer that can cause workflows to operate in the wrong or shared directory:

1. Git-level adoption bypasses cross-checkout guard

WorktreeProvider.findExisting() (packages/isolation/src/providers/worktree.ts) checks the filesystem for an existing worktree at the computed path. Since two local clones of the same remote resolve to the same worktree base directory (~/.archon/workspaces/owner/repo/worktrees/), a worktree created from clone A is visible on disk when clone B checks. The DB-level guard added in #1186 prevents reuse via findActiveByWorkflow, but the git-level adoption in findExisting() runs independently during provider.create() and has no equivalent check.

2. Parallel workflows with the same identifier share a worktree without coordination

Two concurrent workflows with the same branch name (e.g., both using --branch fix/issue-123) compute identical worktree paths. The second workflow adopts the first's worktree via findExisting(). Both AI agents then operate in the same filesystem directory concurrently with no locking or coordination mechanism. This can cause:

• File write conflicts
• Partial/interleaved commits
• Unpredictable workflow outcomes

Steps to Reproduce

Cross-checkout adoption:

1. Clone the same repo to ~/project-a and ~/project-b
2. From ~/project-a: archon workflow run my-workflow --branch fix/shared "task"
3. From ~/project-b: archon workflow run my-workflow --branch fix/shared "task"
4. Step 3 bypasses the DB guard (fix: prevent worktree reuse across different local clones #1186) because provider.create() → findExisting() detects the worktree on disk and adopts it before the DB lookup path is reached

Parallel collision:

1. From the same directory, run two workflows simultaneously with the same --branch
2. Both resolve to the same worktree path; the second adopts the first's worktree
3. Both AI agents write to the same directory concurrently

Suggested Fix

For cross-checkout adoption: findExisting() should incorporate the source repo root into its path computation or existence check, similar to how #1186 guards the DB-level reuse path. One approach: include a hash of the source repo root in the worktree directory name.

For parallel collision: Consider advisory locking (e.g., a lockfile in the worktree directory) or refusing to adopt an environment that is currently in use by another active workflow run.

Related

• Worktree reuse matches environments from different local clones of the same remote #1183 — original worktree reuse bug report
• fix: prevent worktree reuse across different local clones #1186 — DB-level reuse guard (merged)
• Worktrees created from monorepos do not initialize git submodules #1187 — submodule initialization gap

🤖 Generated with Claude Code