When the supervisor can't signal a process referenced by daemon.lock for a reason other than ESRCH, it now checks via a new helper whether the PID is recycled or predates the current boot. If so, it writes a supervisor log line explaining that the lock is being replaced as stale, distinguishing predates_boot from a recycled PID belonging to another process.
Names in the bundledaemon.lock
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Confirmed since
Anthropic's documentation has since written up daemon.lock, on Manage multiple agents with agent view.
| v2.1.257 | Starting the [background service](#the-supervisor-process) recovers from two failure causes. On a macOS npm installation, a start during a self-update [waits for the install](/docs/en/errors#eacces-when-starting-a-background-s…agent-view see the edit
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up daemon.lock, on Manage multiple agents with agent view.