Claude Code v2.1.223 ·
Daemon lock can now live in the v5 storage backend
The background daemon's lock can live in a storage backend instead of a file on disk.
Nothing to try yetTier: how much it should matter to you
2Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
DaemonArea: what it touches
In DevelopmentKind: in v2.1.223,
What probably matters to youSection of the release
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.
See this entry in the whole of v2.1.223 →
