[Bug] Stale supervisor pid across a reboot force-kills whatever process now holds that number

[technicalpickles]

Rebooted my Mac this week (pitchfork 2.14.0, macOS 25.6), and pitchfork never came back. Every Claude Code session I had open started failing with:

Failed to connect to supervisor: failed to connect to supervisor after 5 attempts

launchctl print gui/501/pitchfork showed state = not running, so the supervisor really was dead. But every attempt to start a new one hit:

Pitchfork supervisor is already running with pid 1207. Use `--force` to replace it.

Pid 1207 was not pitchfork. It was AMPDeviceDiscoveryAgent, an unrelated Apple LaunchAgent, which had grabbed that pid fresh on boot because low pids get handed out to early system daemons.

Here's the chain:

1. state.toml never gets rewritten when the machine reboots, so it still had the pre-reboot supervisor recorded with its old pid and status = "running".
2. After reboot, that pid number happened to get reassigned to AMPDeviceDiscoveryAgent.
3. is_running() (src/procs.rs) is a bare kill(pid, 0), no check that the pid is actually pitchfork:

pub fn is_running(&self, pid: u32) -> bool {
    unsafe {
        if libc::kill(pid as i32, 0) == 0 {
            return true;
        }
        std::io::Error::last_os_error().raw_os_error() != Some(libc::ESRCH)
    }
}

4. So every start attempt saw "yes, alive" and bailed, forever, since nothing ever actually killed pid 1207.

I tried the obvious fix, pitchfork supervisor stop, expecting it to notice the pid didn't belong to pitchfork and just clear the stale entry. Instead:

pitchfork Stopped pitchfork daemon with pid 1207

It force-killed AMPDeviceDiscoveryAgent. Looking at stop.rs, resolve_existing_supervisor(true) always passes force: true, and kill_or_stop() only checks PROCS.is_running(existing_pid), never whether that pid is actually pitchfork. So it sent a real kill signal to whatever process now owns that number.

In my case the collateral damage was a LaunchAgent that respawns on its own trigger, so no lasting harm. But this is a process-identity bug, not a pid-liveness bug, and a differently recycled pid could belong to something you really don't want to send SIGTERM to.

Repro: reboot with pitchfork having a recorded pid in state.toml, wait for that pid to get reused by literally anything else post-boot (easy on a busy machine, low pids especially), then try to start pitchfork again.

Suggested fix: store something more than the bare pid in state.toml, like the process start time (or the full /proc/<pid>/stat starttime on Linux, KERN_PROC on macOS), and compare both before treating a pid as "the supervisor." Right now any pid match counts, forever, across reboots.

Workaround if you hit this: don't run supervisor stop or run --force. Just confirm launchctl print gui/$(id -u)/pitchfork shows not running, then launchctl kickstart -k gui/$(id -u)/pitchfork. That starts a fresh supervisor through launchd without touching the stale pid at all.

[github-actions[bot]]

Implemented in #878: fix(supervisor): stop trusting a stale supervisor pid after reboot or pid reuse