{"version":"2.1.275","anchor":"worktree-copy-now-tries-an-atomic-rename-before-falling-back","canonical_anchor":"worktree-copy-now-tries-an-atomic-rename-before-falling-back","heading":"Worktree copy now tries an atomic rename before falling back to exclusive create, behind a gate","tier":"soon","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275\/e\/worktree-copy-now-tries-an-atomic-rename-before-falling-back","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275","markdown":"### Worktree copy now tries an atomic rename before falling back to exclusive create, behind a gate\n\nWorktree file copying can now try a fast atomic rename before falling back to the old method, behind a gate\n\n**What**\n\nWhen Claude Code copies files for a git worktree, it now has a new path that stages the copy and then attempts an atomic rename directly onto the destination (with a retry for a Windows-specific file-exists error). Only if that rename fails does it fall back to the previous method of exclusively creating the destination file. This new rename-first behavior is controlled by a gate called `tengu_squishy_spring`.\n\n**Why**\n\nAn atomic rename is typically faster and safer than the older copy method, so when enabled this should make worktree setup quicker without changing the end result.\n\n- Flag `tengu_squishy_spring`: Not enough to say (read for one account on one subscription tier against v2.1.275; this account: no value returned, anonymous baseline: no value returned, compiled default: on) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Elsewhere\n- Tier: Nothing to try yet\n- Useful: 1\/5\n- Signal: 2\/5\n- Present in the build but not switched on"}