Worktree at ${worktreePath} belongs to a different clone (${

Error message

Worktree at ${worktreePath} belongs to a different clone (${worktreeIdentity.commonGitDir}). Remove it from that clone or use a different codebase registration.

What it means

verifyWorktreeOwnership compares the common git directory (commonGitDir) of the worktree and the expected repo. Linked worktrees of one clone share a common dir, while separate clones do not. A mismatch means the directory is a worktree of a different clone, so adoption is refused with instructions to detach it from that clone or register the right codebase.

Source

Thrown at packages/git/src/worktree.ts:485

    ]);
  } catch (error) {
    throw new Error(
      `Cannot verify worktree ownership at ${worktreePath}: ${(error as Error).message}`,
      {
        cause: error,
      }
    );
  }
  if (!worktreeIdentity.linkedWorktree) {
    // Not a git-worktree pointer (e.g., submodule pointer, or malformed).
    // We cannot confirm this is our worktree, so refuse adoption.
    throw new Error(`Cannot adopt ${worktreePath}: .git pointer is not a git-worktree reference.`);
  }

  // Compare resolved common-directory paths: the primary checkout and every
  // linked worktree share this Git identity, while separate clones differ.
  if (resolve(worktreeIdentity.commonGitDir) !== resolve(expectedIdentity.commonGitDir)) {
    throw new Error(
      `Worktree at ${worktreePath} belongs to a different clone (${worktreeIdentity.commonGitDir}). ` +
        'Remove it from that clone or use a different codebase registration.'
    );
  }
}

View on GitHub (pinned to 0773b97458)

Solutions

Run `git worktree remove <path>` from the clone that owns the worktree, then `git worktree add` it from the expected repo.
Update the codebase registration to point at the clone that actually owns the worktree (the one in the error's commonGitDir).
If the parent clone moved, prune stale worktree metadata (`git worktree prune`) and recreate the worktree from the current clone.
Delete the orphaned worktree and let Archon provision a fresh one from the registered repo.

Example fix

// before: worktree belongs to /old/clone, expected repo is /srv/clone
cd /old/clone && git worktree remove /srv/app
cd /srv/clone && git worktree add /srv/app feat-branch

Defensive patterns

Strategy: validation

Validate before calling

const wt = await getGitCheckoutIdentity(worktreePath);
const repo = await getGitCheckoutIdentity(expectedRepo);
if (resolve(wt.commonGitDir) !== resolve(repo.commonGitDir)) {
  throw new Error(`worktree belongs to clone ${wt.commonGitDir}, not ${expectedRepo}`);
}

Try / catch

try {
  await assertWorktreeOwnership(worktreePath, expectedRepo);
} catch (e) {
  if (e.message.includes('belongs to a different clone')) {
    console.error('Detach from the owning clone and re-add from the expected repo');
  } else throw e;
}

Prevention

Keep one canonical clone per project and create all worktrees from it.
Update codebase registrations when the parent clone moves.
Run `git worktree prune` after clone moves or backup restores, then recreate worktrees.

When it happens

Trigger: Calling findExisting/assertWorktreeOwnership where worktreePath is a valid linked worktree but was created from another clone of the same project (e.g. a clone at a different path, a bare repo, or another machine's checkout mounted here).

Common situations: Moving or renaming the main clone so registered paths no longer match; having two clones of the same repo and pointing a codebase registration at one while the worktree belongs to the other; restoring backups of a worktree without its parent clone.

Related errors

AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/2889371fb843624b. Report an issue: GitHub.