Source Intelligence
Follow Discord

DisclaimerUnofficial, and not affiliated with Anthropic. Nearly all of this is read straight out of what ships: npm bundles, captured prompts, published docs. Anthropic's own notes go in verbatim, marked as theirs. The rest is my reading, and every entry carries the strings behind it. If one looks wrong, vote it down and say why.

← All of v2.1.223 Home All releases ←olderv2.1.222 v2.1.224newer→
Claude Code v2.1.223

Daemon lock can now live in the v5 storage backend

Not switched on
Useful2 Signal3
Daemon Notable

The background daemon's lock can live in a storage backend instead of a file on disk.

Read, acquire, delete and status all accept a v5 storage backend for the daemon lock; it only applies if a caller supplies one.

What

The daemon lock can be read, acquired and deleted through the v5 storage backend rather than a file, when a backend handle is passed in.

Details
  • the read, acquire and delete helpers and the status query all take an optional storage backend argument
  • the lock is a daemon-lock state entry written with an ifAbsent precondition, with dedicated error messages and a size cap that clears a too-large lock
  • read failures with ENXIO, EFBIG, ELOOP or ENAMETOOLONG delete the lock rather than throwing
  • the status command and the version-mismatch check now pass the handle through; whether a backend is actually supplied depends on the caller
  • none of the v5 lock strings exist in the previous build
Evidence

[DaemonLock] v5 lock read failed

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

Related

Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.

See this entry in the whole of v2.1.223 →