Worktree file copying can now try a fast atomic rename before falling back to the old method, behind a gate
When 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.
An 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.
tengu_squishy_spring Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.275: 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.
Read once, for one account on one subscription tier, against v2.1.275. It isn't a statement about your account. What a flag value here can and cannot tell you
New in this build: tengu_squishy_spring