{"version":"2.1.265","anchor":"fast-resume-worktree-reset-now-logs-why-it-was-skipped-and","canonical_anchor":"fast-resume-worktree-reset-now-logs-why-it-was-skipped-and","heading":"Fast-resume worktree reset now logs why it was skipped, and picks filter-driver-aware git args","tier":"internal","area":"Worktrees","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/fast-resume-worktree-reset-now-logs-why-it-was-skipped-and","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Fast-resume worktree reset now logs why it was skipped, and picks filter-driver-aware git args\n\nFast-resume worktree checks now log a specific reason when they bail out instead of failing silently\n\n**What**\n\nWhen Claude Code tries to quickly resume an existing git worktree, it first checks the repository's status. If that status check fails or shows uncommitted changes, it now logs a specific diagnostic message, such as `status failed (code N)` or `tree read dirty under filter-driver-off pins`, instead of just quietly giving up. The path also now accounts for filter-driver arguments (git settings that affect how file content is transformed on checkout) when deciding how to proceed.\n\n**Why**\n\nHaving a specific logged reason makes it much easier to figure out why a worktree resume was skipped, rather than it just silently falling back to a slower path.\n\n- Area: Worktrees\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}