Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.234 ·

Rename retry no longer treats an existing destination as fatal

Rename retries treat an existing destination as fatal only if it is unwritable, but the path is unreachable.

Under the hood Nothing to try yet In Development
JSON All of v2.1.234
Under the hoodTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
ElsewhereArea: what it touches
In DevelopmentKind: in v2.1.234,
In DevelopmentSection of the release

The relaxed rename check exists but the retry loop never reaches it.

What

The file-rename helpers used to stop retrying whenever the destination file already existed; they now stop only when it exists and is not writable by its owner. The retry loop that decides whether to reach this check always answers no, so nothing changes in practice.

Details
  • Applies to both the async and synchronous rename paths; the synchronous loop previously lacked the check entirely.
  • The existence test switched to one that does not follow symlinks and tests the owner-write permission bit.
Evidence

renameSync

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

See this entry in the whole of v2.1.234 →

Feedback