{"version":"2.1.290","anchor":"worktree-cleanup-and-registration-recovery-for-byoc-runner","canonical_anchor":"worktree-cleanup-and-registration-recovery-for-byoc-runner","heading":"BYOC runner recovers from stale worktree records and cleans up more safely","tier":"notice","area":"Elsewhere","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290\/e\/worktree-cleanup-and-registration-recovery-for-byoc-runner","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290","markdown":"### BYOC runner recovers from stale worktree records and cleans up more safely\n\nThe BYOC runner now clears git's stale record of a missing worktree and retries, and deletes worktrees through a helper limited to a trusted folder\n\n**Unclear.** Whether any of this applies outside the BYOC runner is not settled.\n\n**What**\n\nA worktree is a second working copy of a git repository, kept in its own folder so work can happen there without touching your main checkout. The BYOC runner changes how it handles worktrees in two ways:\n\n- Creating a worktree: if git refuses because the worktree \"is a missing but already registered worktree\", meaning git still has a record of it but the folder is gone, Claude Code now drops that old record and tries again.\n\n- Removing a worktree: Claude Code now uses a helper that only deletes inside a trusted root folder. It no longer deletes the folder with `rm -rf` and then runs `git worktree remove --force`.\n\n**Why**\n\nRuns could get stuck when worktrees lived on network file systems (NFS) or storage mounted into containers (CSI mounts). Clearing the stale record and changing how removal works lets those runs continue.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: org\n- Heads-up: no"}