fix(server): don't treat a recycled PID as a running daemon

[chosen1hyj]

Closes #1304.

Problem

The PID lock's liveness check is identity-blind: isPidRunning() (used by both acquirePidLock() and isLocked() in packages/server/src/server/pid-lock.ts) only does process.kill(pid, 0), which tells you a process with that PID exists — not that it's still the daemon. After an unclean shutdown the stale ~/.paseo/paseo.pid survives; once the OS recycles that PID to an unrelated process, the daemon refuses to start (Another Paseo daemon is already running), exits 1, never binds 6767, and every client hangs on "connecting". Full evidence in #1304.

Fix

Verify process identity before trusting the lock: compare the live process's start time (ps -o lstart, the portable keyword on both macOS and Linux; LC_ALL=C for a parseable timestamp) against the lock's startedAt. If they diverge beyond a 60s tolerance, the PID was reused → clear the stale lock and start.

lstart is second-granularity and the lock is written a beat after the daemon starts, so a genuine daemon's two timestamps sit within a few seconds, while a recycled PID differs by the daemon's whole lifetime. When the start time can't be determined (e.g. ps unavailable on Windows), it falls back to the previous conservative behaviour, so there's no regression there.

Testing

• Added two cases in pid-lock.test.ts: one reproduces the recycled-PID bug (fails on main, passes with the fix), one confirms a genuinely-live daemon is still rejected (guards against over-correcting).
• oxfmt, oxlint, and tsgo typecheck across the whole workspace all pass (via the repo's lefthook pre-commit hook).

No protocol/schema changes.

I actually hit this myself — both the desktop app and the CLI were stuck on "connecting" indefinitely. Digging into the logs, the daemon had exited uncleanly the night before and left ~/.paseo/paseo.pid behind, and the OS had since recycled that PID to an unrelated printtool process, so the lock check thought a daemon was still running. Deleting ~/.paseo/paseo.pid and relaunching fixed it immediately, which confirmed the root cause. I tested this change locally: the new test reproduces the recycled-PID case (fails on main, passes with the fix), the guard test confirms a genuinely-live daemon is still rejected, and typecheck/lint/format all pass via the pre-commit hook. Happy to adjust the approach (tolerance value, or verifying identity a different way) if you'd prefer.

[greptile-apps]

Greptile Summary

This PR fixes a daemon-startup failure caused by stale PID locks: after an unclean shutdown, if the OS recycled the dead daemon's PID to an unrelated process, isPidRunning returned true and the new daemon refused to start. The fix adds a process-identity check by comparing each live PID's OS start time (ps -o lstart=) against the startedAt field recorded in the lock, treating any divergence beyond 60 seconds as evidence of PID reuse.

• getProcessStartTimeMs and isLockProcessAlive are added to pid-lock.ts; acquirePidLock and isLocked now call the new identity check instead of bare isPidRunning.
• Two new tests cover the recycled-PID path (stale 2020 timestamp forces clearance) and the genuine-daemon path (real OS start time from an independent ps call still blocks a second acquirer).
• On platforms where ps is unavailable (Windows), getProcessStartTimeMs returns null and the code falls back to the original conservative "assume alive" behavior.

Confidence Score: 4/5

Safe to merge. The recycled-PID fix is correct and well-tested; the one observation is a tightening opportunity rather than a defect in normal operation.

The logic restructure in acquirePidLock is correct across all combinations of owner-pid, running, and recycled states. The startedAt field records lock-write time rather than process-start time, so the 60-second tolerance window is doing real work to bridge the gap — a daemon with an unusually slow startup (>60s to first lock acquisition) would be falsely identified as recycled by a racing second instance. This is an edge case in practice, and the tests clearly verify both the stale and live paths.

packages/server/src/server/pid-lock.ts — specifically the startedAt field written in acquirePidLock and the 60-second tolerance constant.

Important Files Changed

Filename	Overview
packages/server/src/server/pid-lock.ts	Adds getProcessStartTimeMs (via ps -o lstart) and isLockProcessAlive to distinguish a recycled PID from the original daemon. Logic restructure in acquirePidLock and isLocked is correct; minor semantic mismatch: startedAt records lock-write time rather than actual process-start time, making the 60s tolerance the load-bearing safety net.
packages/server/src/server/pid-lock.test.ts	Adds two targeted staleness tests: one reproducing the recycled-PID bug with a year-2020 startedAt, one confirming a live daemon is still rejected using an independently-derived OS start time. Both test through the public module interface.

Comments Outside Diff (1)

1. packages/server/src/server/pid-lock.ts, line 142-144 (link)

   The lock's startedAt is set to new Date().toISOString() — the moment the lock is written — but isLockProcessAlive compares it against the process's actual OS start time from ps lstart. These are different timestamps: the OS start time is always earlier, by however long it took the daemon to reach acquirePidLock. The 60-second tolerance window exists entirely to cover this gap. A daemon whose startup exceeds 60 seconds (loading plugins, cold disk, etc.) would have |liveStartMs - lockStartMs| > 60_000, causing isLockProcessAlive to return false and allowing a second instance to steal the lock. Recording the actual OS start time of the locking process eliminates the gap and lets the tolerance shrink to just a few seconds for lstart's second-granularity rounding.

_{Reviews (1): Last reviewed commit: "fix(server): don't treat a recycled PID ..." | Re-trigger Greptile}