Prevent duplicate live harness ownership for resumed sessions

[cbusillo]

Summary

A restarted/resumed Every Code harness can coexist with an older live code resume <session> process for the same resume id. The older harness can keep its background Auto Review child running after the user believes the harness was restarted.

Evidence

Observed on 2026-06-02 while dogfooding Auto Review:

• Old harness process: PID 13896, command code resume 8e18be4f-ff91-4264-a402-d89aa6741cbc.
• Old background review child: PID 5454, command code exec ... /review ..., snapshot 9cc60a61.
• New/current harness after restart: PID 66065, also command code resume 8e18be4f-ff91-4264-a402-d89aa6741cbc.
• The old review kept running for ~27 minutes after the restart path and reached about 1.69M total tokens in rollout token events before being killed manually.
• The old review was reviewing already-merged/obsolete work, so this was not useful restart recovery; it was duplicate live harness ownership.

Why This Matters

Users expect a harness restart/resume to leave one live supervisor for a session. If two harnesses own the same session id, Auto Review and other background tasks can continue under the old supervisor, burn tokens, surface late results, or interfere with lifecycle state.

Desired Invariant

When code resume <session-id> starts, Every Code should detect an existing live harness for the same session id and choose one safe behavior:

• attach to the existing live harness,
• refuse with a clear message,
• or cleanly retire the older harness and its background children before taking ownership.

For Auto Review specifically, old background review children should be cancelled, adopted, or marked lost/superseded through durable lifecycle policy rather than silently continuing under a stale supervisor.

Acceptance Criteria

• Starting/resuming the same session cannot leave two active harness supervisors for the same session id without an explicit user-visible decision.
• Background Auto Review processes from retired harnesses are cancelled/adopted/reconciled durably.
• The active process/session identity is visible enough to diagnose ownership during dogfooding.
• Regression coverage simulates duplicate code resume <session-id> ownership or restart handoff where feasible.

Related

Related Auto Review durability/proof work: #324, #330, #50.

[shiny-code-bot]

Additional dogfood evidence from the 2026-06-02 rollout-memory session reinforces the same invariant here.

While resuming after compaction/restart, old background agent/review activity could still finish later and surface findings after the main branch had moved on. In the local case it was recoverable, but the product risk is the same as the original report: a stale supervisor or child process can keep doing work that the user no longer considers current.

This issue should cover not only duplicate code resume <session-id> harnesses, but also the lifecycle policy for stale background children that outlive their owning supervisor:

• cancelled when the older supervisor is retired,
• adopted by the active supervisor with explicit current/superseded state,
• or reconciled durably as lost/superseded so late results do not look authoritative.

This overlaps with Auto Review freshness/supersede policy, but the core invariant belongs here: one active owner for the resumed session and a clear ownership state for any background children.