Summary

• Problem: After a gateway crash (or openclaw update-time kill) mid-ACP-turn, the gateway can refuse to restart indefinitely. The reported symptom is a managed gateway "blocked from restart/update" with a stuck ACP run, surfacing after long uptimes (the reporter saw it at ~27 days).
• Root Cause: The gateway blocks restart while any task record is still status=running with no endedAt (getInspectableActiveTaskRestartBlockers). Reconciliation reclaims such records once their backing session is gone, via hasBackingSession, which gates every runtime through a real liveness probe — cron through isCronJobActive, cli through an active run context — except ACP, which returned Boolean(acpEntry.entry). A persistent ACP session keeps a durable session-store entry for its entire lifetime, and that entry survives a gateway crash. So a crashed ACP turn leaves a running record that hasBackingSession treats as "backed" forever: it is never reclaimed, never times out of the restart-blocker set, and wedges restart until the operator clears state manually.
• Fix (two parts, both behind the existing injected maintenance-runtime seam):
  • Liveness gate: gate ACP backing on the in-process live-turn registry instead of entry existence. AcpSessionManager already tracks an authoritative per-session live-turn map (set when a prompt turn starts, deleted in the turn's finally; it is even used internally as the idle-eviction guard). This adds a small public probe AcpSessionManager.hasActiveTurn(sessionKey) and routes the ACP branch of hasBackingSession through it. The per-turn invariant makes this exact: ACP task records are created when a prompt turn begins and marked terminal inside the same turn, before the live-turn entry is deleted — so status=running with no live turn is only a crash mid-turn, or the brief create→register startup window that the unchanged 5-minute reconcile grace already covers.
  • Authoritative-process gate: the live-turn map is process-local — only the gateway process owns it. The openclaw tasks maintenance CLI runs the same runTaskRegistryMaintenance in a separate process with an empty live-turn map, so a naive liveness probe there would read every genuinely-live gateway-owned ACP turn as dead and mark it lost. This reuses the existing cron pattern: the cron branch already gates its process-local isCronJobActive probe behind an authoritative-runtime flag set true only by the gateway at startup. The flag/function are generalized from cron-only (isCronRuntimeAuthoritative → isRuntimeAuthoritative, cronRuntimeAuthoritative → runtimeAuthoritative) and the same gate is applied to the ACP branch: a non-authoritative process stays conservative and never reclaims.
  • This is the generic liveness gate the issue asks for; it deliberately does not add the reporter's suggested max-runtime TTL, heartbeat-timeout, or --force-restart config knobs.
• What changed:
  • src/acp/control-plane/manager.core.ts — add public hasActiveTurn(sessionKey) reading the existing in-process live-turn map.
  • src/tasks/task-registry.maintenance.ts — add hasActiveAcpTurn to the injected maintenance runtime (default delegates to getAcpSessionManager().hasActiveTurn); the ACP branch of hasBackingSession now returns it behind an authoritative-process gate. Generalize the cron-only authoritative flag/function to cover both process-local probes (cron job map + ACP turn map); the diagnostics retain-reason becomes runtime_not_authoritative.
  • src/gateway/server-startup-early.ts — the gateway's single configureTaskRegistryMaintenance call sets runtimeAuthoritative: true (renamed from cronRuntimeAuthoritative), marking the gateway the authoritative owner of both process-local probes.
  • src/tasks/task-registry.maintenance.issue-60299.test.ts — real-component regression tests (see below).
  • src/tasks/task-registry.test.ts — adopt the generalized flag name in the maintenance-runtime test helper and model the gateway as authoritative in the two real-runtime orphan-reconcile tests.
• What did NOT change (scope boundary):
  • Config surface unchanged (no schema, defaults, doctor migrations, or docs/reference/config edits).
  • Plugin surface unchanged (no plugin SDK, manifest, extensions/api.ts / runtime-api.ts, registry, or loader edits).
  • Terminal-ACP-session cleanup (shouldCloseTerminalAcpSession) still reads the session-store entry; that path is untouched.
  • The 5-minute reconcile grace and all non-ACP backing probes (cli, subagent) are unchanged. The cron probe keeps identical semantics — only the flag/function name is generalized.
  • No dependency / lockfile changes.

Reproduction

1. A persistent ACP session is running a prompt turn; a running task record exists for that turn, and the durable session-store entry exists.
2. The gateway crashes (or is killed by openclaw update) mid-turn. The in-process live-turn registry is gone, but the persisted session-store entry survives on disk.
3. Before this PR: on restart, the running task record has no endedAt; hasBackingSession sees the surviving entry (Boolean(acpEntry.entry) === true) and treats it as backed forever. The record never reconciles to lost, stays in getInspectableActiveTaskRestartBlockers(), and blocks restart/update until the operator clears state by hand.
4. After this PR: in the gateway (authoritative) process, hasBackingSession consults hasActiveAcpTurn, which is false after a crash. Once the existing 5-minute reconcile grace expires, the record is marked lost, drops out of the restart-blocker set, and restart proceeds. A turn that is genuinely mid-flight keeps hasActiveTurn true and is never reclaimed. A non-authoritative openclaw tasks maintenance CLI process never reclaims any ACP record.

Real behavior proof

Behavior addressed (#88205): a grace-expired status=running ACP task whose session-store entry survives a crash but whose prompt turn is no longer live is reclaimed (lost) and leaves the restart-blocker set; a running ACP task with a live in-flight turn is never reclaimed; and a non-authoritative maintenance process (empty live-turn map) never reclaims a gateway-owned ACP task.

Real environment tested (Linux, Node 22, real-component vitest harness driving production runTaskRegistryMaintenance + previewTaskRegistryMaintenance + getInspectableActiveTaskRestartBlockers + hasBackingSession): the harness builds real TaskRecords and exercises the actual reconcile / restart-blocker code paths; only the leaf liveness probes (hasActiveAcpTurn, readAcpSessionEntry, isCronJobActive, getAgentRunContext) and the authoritative flag are injected through the same taskRegistryMaintenanceRuntime seam production uses to wire getAcpSessionManager().hasActiveTurn and the gateway's runtimeAuthoritative: true.

Exact steps or command run after this patch:

1. node scripts/run-vitest.mjs src/tasks/task-registry.maintenance.issue-60299.test.ts --reporter=verbose (AFTER fix)
2. Temporarily revert the ACP branch of hasBackingSession to the shipped entry-existence check (return Boolean(acpEntry.entry)), rerun the same file (BEFORE — liveness gate), then restore
3. Temporarily drop the authoritative-process gate from the ACP branch, rerun the same file (BEFORE — authoritative gate), then restore
4. node scripts/run-vitest.mjs src/tasks/task-registry.test.ts
5. node scripts/run-vitest.mjs src/acp/control-plane/manager.test.ts
6. pnpm exec oxfmt --check --threads=1 src/acp/control-plane/manager.core.ts src/tasks/task-registry.maintenance.ts src/tasks/task-registry.maintenance.issue-60299.test.ts src/tasks/task-registry.test.ts src/gateway/server-startup-early.ts

Evidence after fix (verbatim vitest BEFORE/AFTER on the regression tests):

--- AFTER FIX (both gates in place) ---
 ✓ reclaims a stale running ACP task with no live turn even though its session-store entry survives
 ✓ keeps a running ACP task live while a prompt turn is still in flight
 ✓ does not reclaim a running ACP task from a non-authoritative process even with an empty live-turn map
 Test Files  1 passed (1)
      Tests  19 passed (19)

--- BEFORE (liveness gate reverted to entry-existence Boolean(acpEntry.entry)) ---
 × reclaims a stale running ACP task with no live turn even though its session-store entry survives
   → expected +0 to be 1   (surviving entry treated as backed → zombie never reclaimed)
 ✓ keeps a running ACP task live while a prompt turn is still in flight
 ✓ does not reclaim a running ACP task from a non-authoritative process even with an empty live-turn map
 Test Files  1 failed (1)
      Tests  1 failed | 18 passed (19)

--- BEFORE (authoritative-process gate removed from ACP branch) ---
 ✓ reclaims a stale running ACP task with no live turn even though its session-store entry survives
 ✓ keeps a running ACP task live while a prompt turn is still in flight
 × does not reclaim a running ACP task from a non-authoritative process even with an empty live-turn map
   → expected 1 to be +0   (CLI process with empty live-turn map wrongly reclaims a live gateway-owned turn)
 Test Files  1 failed (1)
      Tests  1 failed | 18 passed (19)

Companion suites green after fix: src/tasks/task-registry.test.ts 72/72, src/acp/control-plane/manager.test.ts 86/86; oxfmt --check clean on all five touched files.

Observed result after fix:

• The crashed-run zombie reconciles (reconciled: 1, status lost) and getInspectableActiveTaskRestartBlockers() becomes empty → restart unblocked.
• A running ACP task with hasActiveAcpTurn === true is never reclaimed (reconciled: 0, stays running, still a blocker).
• A non-authoritative maintenance process (runtimeAuthoritative: false, empty live-turn map) retains the gateway-owned running task (reconciled: 0, diagnostics reason runtime_not_authoritative, still a blocker) — no false lost.
• Reverting only the liveness gate flips the zombie-reclaim test red (expected +0 to be 1); removing only the authoritative gate flips the non-authoritative test red (expected 1 to be +0) — each gate is independently pinned.

What was not tested:

• End-to-end: a real opencode/codex ACP child crashing mid-turn on a managed gateway over a multi-day uptime, then a real openclaw gateway restart / openclaw update, and a real openclaw tasks maintenance --apply running while the gateway holds a live turn. The deterministic harness reproduces the necessary conditions (running record + surviving entry + no live turn; authoritative vs non-authoritative process) without a real backend or 27-day uptime.
• Full pnpm check / full pnpm test broad gates — deferred to CI on this memory-constrained box.

Regression tests:

• reclaims a stale running ACP task with no live turn even though its session-store entry survives (ACP zombie runs block gateway restart/update after 27 days #88205) — fails on the shipped entry-existence behavior, passes with the live-turn gate.
• keeps a running ACP task live while a prompt turn is still in flight — passes before and after, guarding against the inverse regression (never over-reclaim a healthy in-flight turn).
• does not reclaim a running ACP task from a non-authoritative process even with an empty live-turn map — fails if the authoritative-process gate is dropped, guarding the standalone-CLI false-lost case.

Risk / Mitigation

• Risk: over-reclaiming a live ACP session. Mitigation: the per-turn invariant — a running ACP record always coincides with a live turn during normal operation, and there is no running record between turns of a persistent session — plus hasActiveTurn staying true for any in-flight turn (including a hung-but-alive one) means only the crashed-run set is affected.
• Risk: a non-gateway process (e.g. the openclaw tasks maintenance CLI) observing an empty live-turn map and falsely marking live gateway-owned turns lost. Mitigation: the authoritative-process gate — process-local probes (cron job map + ACP turn map) only reclaim in the process that owns the map (the gateway, which sets runtimeAuthoritative: true at startup); every other process stays conservative and returns "backed".
• Risk: the brief window between task-record creation and live-turn registration during backend resolution could look like "no live turn". Mitigation: that window is covered by the unchanged 5-minute reconcile grace keyed off the task's own timestamps; nothing reclaims a record younger than the grace.
• Risk: generalizing the cron authoritative flag could alter cron behavior. Mitigation: the cron branch keeps identical gate semantics — only the flag/function identifiers are renamed; the gateway still sets the flag true, and cron behavior tests are unchanged.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration (task-registry restart blockers / reconciliation)
• ACP agent runtime (AcpSessionManager live-turn liveness)

Linked Issue/PR

Fixes #88205