`releaseStartupRegistryLock` is only invoked from three places: the listen-callback's try/finally, `handleStartupServerError`, and the outer catch. The signal handlers (`SIGTERM`/`SIGINT` → `shutdown(0)`) are registered at lines 507-508, but `shutdown()` does not release the startup registry lock. If a signal is delivered between `server.listen(...)` being scheduled and its callback firing, `shutdown()` will run, `process.exit` will occur via the cleanup pipeline, and the filesystem-based registry mutation lock will only be reclaimed via lease expiry (DAEMON_REGISTRY_LOCK_LEASE_MS = 30s). This can transiently block another daemon's startup for the same workspace.

`releaseStartupRegistryLock` is only invoked from three places: the listen-callback's try/finally, `handleStartupServerError`, and the outer catch. The signal handlers (`SIGTERM`/`SIGINT` → `shutdown(0)`) are registered at lines 507-508, but `shutdown()` does not release the startup registry lock. If a signal is delivered between `server.listen(...)` being scheduled and its callback firing, `shutdown()` will run, `process.exit` will occur via the cleanup pipeline, and the filesystem-based registry mutation lock will only be reclaimed via lease expiry (DAEMON_REGISTRY_LOCK_LEASE_MS = 30s). This can transiently block another daemon's startup for the same workspace.

When `allowLiveOwner` is true and the caller's pid matches the live entry's pid, removal still requires `entry.instanceId !== undefined && options.instanceId === entry.instanceId`. Older entries written before instanceId was introduced (the field is optional in the interface and validator) will have `entry.instanceId === undefined`, making them permanently un-removable by their own owning process even when pid matches. This can leave stale registry files that legitimately belong to the current live process and block subsequent daemon lifecycle operations that depend on cleanup.

When `allowLiveOwner` is true and the caller's pid matches the live entry's pid, removal still requires `entry.instanceId !== undefined && options.instanceId === entry.instanceId`. Older entries written before instanceId was introduced (the field is optional in the interface and validator) will have `entry.instanceId === undefined`, making them permanently un-removable by their own owning process even when pid matches. This can leave stale registry files that legitimately belong to the current live process and block subsequent daemon lifecycle operations that depend on cleanup.

In tryRecoverExpiredLockDir, when shouldRecoverLockDir returns recovery.owner === null (the lock dir existed but had no owner.json and was older than the lease), the function quarantines the directory and immediately removes it without re-reading the quarantined contents. Between the initial owner read and the rename, another process could have completed createLock (mkdir succeeded earlier, then writeFile of owner.json finished), making the directory a valid live lock. We then rename it away and rm it, silently destroying that process's lock and letting two holders believe they own the same resource. The owner!=null branch guards against this with fsLockOwnersEqual, but the null branch does not.

In tryRecoverExpiredLockDir, when shouldRecoverLockDir returns recovery.owner === null (the lock dir existed but had no owner.json and was older than the lease), the function quarantines the directory and immediately removes it without re-reading the quarantined contents. Between the initial owner read and the rename, another process could have completed createLock (mkdir succeeded earlier, then writeFile of owner.json finished), making the directory a valid live lock. We then rename it away and rm it, silently destroying that process's lock and letting two holders believe they own the same resource. The owner!=null branch guards against this with fsLockOwnersEqual, but the null branch does not.

`scheduleWorkspaceFilesystemLifecycleSweep` only updates `lastScheduledAtByScope` and `lastScheduledAtByPreKey` after the sweep completes (in `.then`). Between scheduling and completion, the `runningScheduledSweeps` set guards against same-scope re-entry, but the pre-key cooldown check uses `lastScheduledAtByPreKey` which has not yet been written. Two callers using different `preKey` values (e.g. one passing `workspaceKey`, another passing `logDir` that resolves to the same scope) can both pass cooldown gates and one will then early-return at the `runningScheduledSweeps.has` check — but a caller using only a `logDir` override that maps to a different scheduleKey could schedule a redundant concurrent sweep targeting overlapping paths. The cooldown is best-effort, but the asymmetry between pre-key and scope keys means rapid bursts of artifact-created events trigger more sweeps than intended.