Codex review: needs maintainer review before merge. Reviewed July 8, 2026, 8:02 AM ET / 12:02 UTC.

Summary
The branch removes Claude live active-tool timer heartbeats, adds evidence-stale stale_run refusal and stuck-recovery attribution paths with a quiet-tool floor, and updates agent/reply/diagnostic regression tests.

PR surface: Source +87, Tests +395. Total +482 across 14 files.

Reproducibility: yes. Current main source still emits synthetic cli_live:tool_running progress from an active-tool interval, while the PR head removes that timer and the PR discussion provides live output for stale refusal, takeover, and recovery attribution.

Review metrics: 1 noteworthy metric.

• Queue failure reasons: 1 added (stale_run). The new closed queue outcome affects whether active-run handoffs are steered, retried through admission, or delivered directly before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #96168
Summary: This PR is a strong candidate fix for the canonical Claude CLI fake-liveness issue and a partial Track B implementation for the broader run-lifecycle reliability cluster.

Members:

• canonical: claude-cli backend: active-tool heartbeat masks wedged subprocesses, defeats stuck-session detection #96168 - The issue reports active-tool heartbeat masking wedged Claude CLI subprocesses, and this PR deletes that heartbeat path.
• partial_overlap: Stuck-session recovery aborts long-but-active agent runs at warnMs×3 (~6min) with misleading "Reply operation aborted by user" reason #88870 - The PR addresses watchdog attribution and quiet-tool false-positive pieces, but that issue also includes broader active-run recovery and message-loss symptoms.
• partial_overlap: Stuck-session liveness monitor misclassifies healthy processing runs as stale during event-loop stalls #101670 - The delayed heartbeat recovery guard addresses the event-loop-stall liveness path, while the issue remains broader and still needs maintainer review.
• partial_overlap: Design: run lifecycle reliability — bounded liveness, abort⇒release, crash resume, completion drive #101863 - The umbrella issue tracks all run-lifecycle reliability work; this PR implements Track B subparts only.
• adjacent_distinct: fix(auto-reply): bound terminal reply-run settle and reclaim stale lanes #101910 - This PR is stacked on the Track A reply-run terminal-release work and depends on its primitives, but covers a distinct liveness slice.
• 2 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Resolve or land fix(auto-reply): bound terminal reply-run settle and reclaim stale lanes #101910 before any direct Track B merge.
• Re-review the exact fix(agents): run-lifecycle reliability — bounded release, evidence-based liveness, watchdog semantics #102160 merge candidate if this work lands through the atomic integration path.

Risk before merge

• [P1] This PR is a protected draft stacked on fix(auto-reply): bound terminal reply-run settle and reclaim stale lanes #101910 and should not merge independently of the Track A base or the planned integration path.
• [P1] The branch intentionally changes default stale-run capture and recovery behavior, so existing long-running sessions may be refused or reclaimed after evidence staleness instead of remaining attached indefinitely.
• [P1] stale_run is a new queue failure reason; every message-delivery caller must continue treating it as fall-through, retry, or direct delivery so handoffs are not dropped.
• [P1] The currently proposed atomic landing path, fix(agents): run-lifecycle reliability — bounded release, evidence-based liveness, watchdog semantics #102160, is open draft work and still needs its own blocker resolution and exact-head review before this per-track PR can close as superseded or merged.

Maintainer options:

1. Fix And Land Through The Integration Stack (recommended)
   Resolve the open integration blockers, re-review the exact fix(agents): run-lifecycle reliability — bounded release, evidence-based liveness, watchdog semantics #102160 head, and let that atomic PR land this Track B work with its coupled dependencies.
2. Accept Direct Track B Runtime Risk
   Maintainers can land this branch directly after Track A if they explicitly accept the standalone stale-run and quiet-tool-floor behavior change.
3. Keep As Review Record Only
   Pause this PR as a per-track record and close it only after the integration branch lands or maintainers reject the runtime policy.

Next step before merge

• [P2] Human maintainer review is required because this protected draft changes session-state and message-delivery defaults and is now planned to land through the open integration PR, not because of a narrow repairable defect on this branch.

Maintainer decision needed

• Question: Should this Track B liveness branch remain a review-record branch to be landed only through fix(agents): run-lifecycle reliability — bounded release, evidence-based liveness, watchdog semantics #102160, or should maintainers consider a direct Track B landing after fix(auto-reply): bound terminal reply-run settle and reclaim stale lanes #101910?
• Rationale: The code and proof support the Track B bug fix, but the PR changes protected session-state and message-delivery defaults and is now tied to an open draft integration stack.
• Likely owner: obviyus — They own this branch, the Track A dependency, and the open integration stack that now proposes the landing route.
• Options:
  • Use The Integration PR (recommended): Fix and re-review fix(agents): run-lifecycle reliability — bounded release, evidence-based liveness, watchdog semantics #102160, then let that atomic branch close this PR while preserving it as review context.
  • Direct Track B After Track A: Land fix(auto-reply): bound terminal reply-run settle and reclaim stale lanes #101910 first, then rebase and re-review this branch as a standalone runtime default change.
  • Pause For Policy Redesign: Keep this draft open while maintainers decide whether stale-run refusal and quiet-tool floors need a different rollout shape.

Security
Cleared: The diff changes runtime liveness logic and tests only; no dependency, workflow, secret, install, package, or supply-chain surface change was found.

P1 fixed in f880b20: stale_run steer refusals from the active-wake path now report the requester as not-active, so non-completion announce dispatch falls through to direct delivery instead of dropping the handoff (subagent-announce-delivery.ts, with a regression test asserting the steer-primary → direct-primary phase sequence for a stale-but-registered requester).

Live behavior proof is running now on this exact branch (same harness as the #101910 and #101986 E2E comments): wedged run → 10-min stale window → channel msg refused by steer capture (reason=stale_run) → admission takeover → new turn; plus a default-config stuck-recovery abort asserting run_stalled attribution with no aborted_by_user. Evidence will be posted here and the PR body updated when it completes (~40 min).

On sequencing: agreed and stated in the PR body — this is stacked on #101910 (its base branch) and must not merge independently.

Live behavior proof (requested by review) — and one more bug it caught, now fixed

Same harness as the #101910 / #101986 E2E comments: local gateway from this branch's dist, black-hole model endpoint holding a genuine wedge open (explicit provider timeoutSeconds: 36000), qa-channel synthetic transport for real channel-inbound turns.

Artifact check — fake heartbeat gone

grep -r 'cli_live:tool_running' dist | wc -l → 0.

Proof 1 — stale steer refusal + takeover: PASS (flips the exact failure from the #101910 E2E)

• Steer refusal: on a 16-minute-stale lane, an injected message was refused by steer capture — queue message failed: ... reason=stale_run + rejected steering injection: queue_message_failed reason=stale_run. On main this exact probe is steer-accepted unconditionally (the "wedged run swallows its own rescue message" hole).
• Takeover: a channel DM injected 10m35s into the wedge produced reply run stale takeover: forced release sessionKey=agent:main:qa-channel:... reason=no_activity 34 ms after injection; the wedged fetch aborted (elapsedMs=635096) and the rescue message's turn started ~2.4s later with a fresh model request.
• Surface note: channel visible turns reclaim at admission, before the steer layer runs, so refusal and takeover appear on different probe surfaces rather than one chain — both behaviors independently proven.
• Harness correction worth recording: qa-channel serializes inbound per account, which is what actually parked msg2 in the fix(auto-reply): bound terminal reply-run settle and reclaim stale lanes #101910 E2E's "Test B2" — the steer-capture interpretation there was partially the harness, not only the runtime. The refusal path is now proven directly regardless.

Proof 2 — recovery attribution: FAILED live, root-caused, fixed

Default stuck recovery aborted the wedge at 374s and freed the lane, but the operation still terminated as aborted_by_user, not run_stalled. Two-part root cause, both fixed:

1. Expire ordering race (Track A code): expireStaleReplyOperation cancelled the backend before setting its result; the cancel synchronously re-enters the run loop's abort handler → abortByUser() stamps aborted_by_user → expire's if (!result) skips run_stalled. Fixed on the base branch (fix(auto-reply): bound terminal reply-run settle and reclaim stale lanes #101910, 1ca9288cf2f): result is stamped before backend cancel, with a reentrancy regression test (backend whose cancel calls abortByUser() must still end run_stalled).
2. Live-handle recovery leg (this branch): abortAndDrainEmbeddedAgentRun only routed through the expiry when no embedded handle existed — the handle-present case (the common field shape) went down the plain abort path. Fixed in 1eb76b6c090: stuck recovery expires the reply operation first regardless of handle state, then aborts/drains the handle; new test covers the live-handle case with a re-entering abort handler.

Also in this push: the review's P1 (stale_run → subagent announce dropped) fixed with a phase-sequence regression test — a stale requester now falls through to direct delivery.

Validation after fixes: registry/admission/runs/recovery/announce suites green, tsgo core + core-test lanes exit 0, branch rebased onto the updated #101910 base. Full timestamped evidence in the harness report (request ledger, log lines); happy to attach the raw report if wanted.

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Landing plan update: this track lands atomically with its siblings via the integration PR #102160 (all commits preserved, rebase merge) — sequential landing would put untested intermediate states on main (e.g. the stale takeover without the quiet-tool floor). This PR stays open as the per-track review record and closes when #102160 lands.