Worktree at ${worktreePath} was reported removed but is stil

Error message

Worktree at ${worktreePath} was reported removed but is still registered in git

What it means

A post-removal verification warning recorded in destroy()'s result.warnings in packages/isolation/src/providers/worktree.ts. After git worktree remove reported success, destroy re-checks via isWorktreeRegistered; if git still lists the worktree (e.g. stale .git/worktrees metadata), worktreeRemoved is reset to false and this warning is appended.

Source

Thrown at packages/isolation/src/providers/worktree.ts:316

        result.directoryClean = true;
      }
    }

    // Prune stale worktree references — runs even when path is already gone,
    // because git may still have a stale ref for a manually-deleted worktree
    try {
      await execFileAsync('git', ['-C', repoPath, 'worktree', 'prune'], { timeout: 15000 });
    } catch (_error) {
      // Best-effort — pruning failure is not critical
      getLog().debug({ repoPath }, 'worktree_prune_failed');
    }

    // Post-removal verification: confirm worktree is actually gone from git
    if (result.worktreeRemoved) {
      const stillRegistered = await this.isWorktreeRegistered(repoPath, worktreePath);
      if (stillRegistered) {
        result.worktreeRemoved = false;
        const warning = `Worktree at ${worktreePath} was reported removed but is still registered in git`;
        getLog().warn({ worktreePath, repoPath }, 'worktree_removal_verification_failed');
        result.warnings.push(warning);
      }
    }

    // Delete associated branch if provided (best-effort cleanup)
    if (options?.branchName) {
      result.branchDeleted = await this.deleteBranchTracked(repoPath, options.branchName, result);

      // Delete remote branch if requested (e.g., after PR merge)
      if (options.deleteRemoteBranch) {
        result.remoteBranchDeleted = await this.deleteRemoteBranchTracked(
          repoPath,
          options.branchName,
          result,
          options.remote
        );
      }

View on GitHub (pinned to 0773b97458)

Solutions

Run git worktree prune in the canonical repo to drop stale registration metadata, then verify with git worktree list
Check for a lock file (git worktree remove --force, or remove .git/worktrees/<name>/locked in the main checkout)
Inspect .git/worktrees/<name> in the main checkout and delete the stale directory manually if git prune does not clear it
After pruning, delete the branch if still desired, since destroy treated the worktree as unremoved

Example fix

// before
await provider.destroy({ worktreePath }); // warns: still registered in git
// after
git -C /repos/main worktree prune
git -C /repos/main worktree list // confirm gone
await provider.destroy({ worktreePath }); // or treat as already removed

Defensive patterns

Strategy: validation

Validate before calling

import { execFile } from 'node:child_process';
const { stdout } = await promisify(execFile)('git', ['-C', repoPath, 'worktree', 'list', '--porcelain']);
if (stdout.includes(`worktree ${worktreePath}`)) {
  await promisify(execFile)('git', ['-C', repoPath, 'worktree', 'prune']);
}

Type guard

function hasStaleRegistrationWarning(result: DestroyResult): boolean {
  return result.warnings.some(w => w.includes('still registered in git'));
}

Try / catch

const result = await provider.destroy({ worktreePath, canonicalRepoPath: repoPath });
if (hasStaleRegistrationWarning(result)) {
  await execFile('git', ['-C', repoPath, 'worktree', 'prune']);
  getLog().warn({ worktreePath }, 'pruned stale worktree registration after destroy');
}

Prevention

Schedule or run git worktree prune after abnormal terminations and crashes
Never remove worktree directories with rm -rf alone; use git worktree remove
Check for lock files under .git/worktrees/<name>/ when removals stall
Inspect result.warnings after destroy instead of assuming success from absence of throws

When it happens

Trigger: destroy() runs, worktreeRemoved is initially true, but isWorktreeRegistered(repoPath, worktreePath) still finds the path in 'git worktree list' / .git/worktrees metadata afterwards.

Common situations: Interrupted prior removals leaving stale .git/worktrees entries; removal of a locked worktree partially succeeding; git metadata corruption after a crash; network filesystems where metadata deletion lags.

Related errors

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