fix(coding-agent): self-heal stale worker registrations on resume

[snimu]

Problem

If a dead worker's registration did get left behind (stop timed out, the process died later, and the supervisor restarted before cleaning up), you could never reopen that session. Resume kept matching the dead registration and failing with "Session worker is not connected".

Fix

When you open or resume a session and the matching worker turns out to be marked for stop, disconnected, and dead, the supervisor now finishes the old cleanup, drops the stale registration, and starts a fresh worker for the same saved transcript.

What this does not change

Healthy workers are never touched. Neither are workers that are still shutting down or in the middle of recovery.

Validation

• 3 unit tests: stale registration gets cleaned up; a still-running or healthy worker is left alone.
• An end-to-end test that replays the original incident: stop fails, process dies, and resume just works — same session, new worker, attach succeeds.
• npm run check passed.

---

Part 3 of 3, on top of #851.

---

Note

Medium Risk
Changes daemon supervisor worker lifecycle and session resume paths; mistakes could strand sessions or signal wrong PIDs, but identity checks and bounded waits limit blast radius.

Overview
Fixes a case where a stopped worker’s registration could outlive the process (stop timeout, late death, supervisor restart) and block reopening the saved transcript on resume.

On create/resume, when a session path matches a worker that is tombstoned and disconnected, the supervisor now calls reclaimStaleWorkerRegistration: it only proceeds if process identity is gone or replaced, then drives the existing stop finalizer (bounded STALE_RECLAIM_WAIT_MS wait) instead of treating the slot as still active. Healthy, connected, or still-stopping workers are unchanged.

During supervisor adoption of a stop-pending worker with no processStartId, it connects to the live worker socket, captures and persists the start id when verification succeeds, so stopWorker and background finalization can signal the right process instead of waiting on a possibly recycled pid.

Validation adds unit coverage for reclaim, adoption identity capture, and concurrent reclaims, plus an E2E path: failed stop, process dies, resume succeeds with a new worker.

^{Reviewed by Cursor Bugbot for commit 0517f98. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix stale worker registrations blocking session resume in coding agent daemon

• When resuming a saved session, the daemon supervisor now checks if a previously stopped worker's process is dead or recycled. If so, it reclaims the stale registration immediately rather than blocking the resume.
• stopWorker is now identity-aware: it captures the entry PID/start-ID and avoids signaling recycled or unknown PIDs. On timeout, it leaves a tombstone and schedules background finalization via finalizeTimedOutWorkerStop.
• reclaimStaleWorkerRegistration probes process identity (current/replaced/gone/unknown) and either reclaims the slot or raises a retryable error if cleanup is still in progress.
• Supervisor shutdown no longer blocks on workers that exceed stop deadlines; those workers are tombstoned and finalized asynchronously.
• New process-probing utilities (processIdExists, isZombieProcess, isProcessAlive) in child-process.ts replace ad-hoc liveness checks and exclude zombie processes from alive counts.

Changes since #852 opened

• Added self-healing logic for legacy worker descriptors during supervisor adoption [0517f98]
• Added test coverage for legacy worker descriptor adoption scenarios [0517f98]

^{Macroscope summarized 52a604d.}

[snimu]

Fixed in 610e038. Reclaim now verifies process identity via processStartId (same pattern as recoverWorker): a recycled pid counts as gone, so the stale registration is still reclaimed, and the identity-aware stop path never signals the pid's new owner. Added a regression test with a live pid whose processStartId no longer matches.

[snimu]

Addressed both findings in 019058c:

• Duplicate stop: reclaim now awaits an in-flight stopFinalization instead of starting a second stopWorker, so archive and cron-lock cleanup can never run twice. New unit test covers the deferral.
• E2E race: kept intentionally — whichever cleanup wins (background finalizer or resume-time reclaim), the user-visible guarantee under test is that resume succeeds; both individual paths are covered deterministically by unit tests. Documented this in the test.

[snimu]

Both addressed in 8ed4aa6 by collapsing reclaim onto the existing finalizer instead of adding coordination:

• Never-settling wait: reclaim now fails fast — it checks for a confirmed-dead process first and returns immediately for live/unknown identities; the wait on the finalizer is bounded (10s), so a resume request always returns promptly.
• Duplicate cleanup: reclaim no longer calls stopWorker itself. It delegates to scheduleWorkerStopFinalization, which is single-flighted per worker, so concurrent resumes share one stop and archival/cron-lock cleanup cannot run twice. New regression test races two concurrent reclaims and asserts a single stop.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8ed4aa6. Configure here.}

[snimu]

Fixed in c641a1e. When the process is confirmed dead but the finalizer outlasts the bounded wait, reclaim now throws a retryable error ("still being cleaned up; retry shortly") instead of returning false — so the resume path can never fall through to reuseWorkerForCreate with a dead registration. Regression test covers the slow-cleanup timeout.

[snimu]

Valid finding — fixed in 0517f98.

For a pre-identity descriptor (no processStartId) with a live pid and an intentional-stop tombstone, stopWorker resolved identity as unknown and (correctly) refused to SIGTERM/SIGKILL by pid alone, and the finalizer's stoppedCanSignal stayed false for the same reason — so the live worker ran forever and the registration could never be finalized.

The fix captures identity the same way the adopt and recovery paths already do: authenticate on the worker's socket (proof the pid is our worker, not a recycled process), then persist the processStartId observed while it was alive, before calling stopWorker. The connected client also gives the stop its graceful IPC shutdown path. If the handshake fails, the identity stays untrusted and the stop keeps its conservative wait-only behavior — we never signal a pid whose identity the handshake did not confirm.

Tests: identity captured+persisted before the stop runs (order asserted), and a failed connect leaves processStartId unset with no persist.