[macOS] Prime Agent 0.7.2 loses supervisor ownership after registry file pruning

[ss800803]

Summary

Fresh reproduction on macOS with Prime Agent 0.7.2 of the supervisor_generation_stale / ownership-loss failure described in #1148 and #1235. In this reproduction, the daemon had been running for about five days. The failure also left stale process and lock state that prevented a clean restart.

Environment

• Prime Agent 0.7.2, installed via Homebrew
• macOS on Apple Silicon
• Node.js v26.0.0
• Default background daemon

Symptoms

The TUI reported:

Error: Daemon supervisor generation 849461ff-dc80-461e-a328-7f63226b5861 no longer owns its registry entry

Local inspection showed:

• The supervisor generation directory under the macOS temporary daemon registry still existed, but it contained no valid owner.json.
• The old supervisor and its session worker were still alive and holding their Unix sockets.
• prime-agent status --json and prime-agent doctor --json reported the daemon as unreachable while also reporting tracked workers.
• prime-agent shutdown --force removed the stale socket but could not safely stop the old worker.
• The next resume attempt failed with:

Lock file is already being held

After terminating the verified orphaned supervisor and worker processes and waiting for the stale lock to clear, a new supervisor generation and worker started successfully and the saved session resumed. No session transcript, private prompt, API key, or token is included here.

Suspected trigger

The supervisor had been running for about five days, and the ownership directory was left behind without its files. This strongly suggests the same macOS temporary-directory pruning mechanism described in #1148: the registry files are stored below $TMPDIR, but the live supervisor does not refresh them often enough.

I have not confirmed a timezone change for this reproduction, so this appears more consistent with the file-pruning path than the timezone-specific trigger in #879/#1472.

Expected behavior

When the supervisor loses its durable ownership record, Prime Agent should:

1. refresh or persist the ownership record so a live daemon is not invalidated by macOS cleanup;
2. self-fence and exit when ownership is lost, allowing a replacement to take over; or
3. automatically force-reap the verified stale supervisor and restart, preserving the saved session.

shutdown --force and --resume should not require manual PID termination for this recoverable state. The status command should also agree with the actual daemon/socket state.

Related reports

• Changing macOS timezone invalidates the running daemon #879 — timezone-related supervisor identity mismatch
• Daemon supervisor permanently fails with supervisor_generation_stale after the OS prunes its registry entry from the temp directory #1148 — macOS prunes the daemon supervisor registry entry
• Wedged daemon supervisor keeps serving after ownership loss; --resume crashes with supervisor_generation_stale #1235 — wedged daemon supervisor after ownership loss
• Changing macOS timezone invalidates the running daemon (supervisor_generation_stale) #1472 — current macOS supervisor_generation_stale Bug Report Discussion
• Follow-up: macOS 0.7.2 daemon loses supervisor ownership and leaves stale lock #1491 — fresh Issue report for this reproduction, automatically closed by the issue intake policy

This is a fresh 0.7.2 reproduction with additional evidence about the empty owner directory, stale worker, and stale lock. Please consolidate it with the appropriate existing report if needed.

[snimu]

Fixed in 0.7.3