Summary
Workspace cleanup is reporting hundreds of active_no_signal worktrees as if they are still in progress. On this machine the report showed 408 active/no-signal rows, which is not a credible real active workload count.
Evidence
- Command:
studio wp datamachine-code workspace worktree active-no-signal-report --limit=25 --offset=0 --until-budget=60s --format=json
- Observed summary:
total_active_no_signal: 408
- Sample rows had stale lifecycle metadata, e.g.
liveness_reason=heartbeat_stale, last_seen_at days old, no session ids, and often no PR/task metadata.
- Many rows are dirty or have unpushed commits, so deletion must remain guarded, but they should not remain classified as active/in-progress indefinitely.
Expected behavior
Stale heartbeat worktrees should transition out of generic active lifecycle or into a distinct review/remediation bucket after a bounded TTL. Cleanup/hygiene should surface them as abandoned/stale-review candidates, not count them as active in-progress work forever.
Actual behavior
Rows with lifecycle_state=active and stale heartbeats remain active_no_signal indefinitely. This makes cleanup output misleading and hides a lifecycle accounting bug behind safety blockers.
Impact
- Cleanup reports imply hundreds of active local tasks.
- Disk cleanup cannot make progress without manual interpretation.
- Operators may be tempted to force-remove dirty worktrees because the lifecycle state is not trustworthy.
Suggested fix
Add a lifecycle reconciliation path for stale heartbeat active worktrees:
- Detect
lifecycle_state=active plus liveness_reason=heartbeat_stale beyond a TTL.
- Move them to a non-active review state such as
abandoned_review, stale_active, or an explicit cleanup triage bucket.
- Preserve dirty/unpushed safety gates for deletion.
- Update cleanup summaries so stale-active rows are counted separately from truly live active work.
AI assistance
- AI assistance: Yes
- Tool(s): openai/gpt-5.5 via OpenCode
- Used for: Investigation summary and issue drafting.
Summary
Workspace cleanup is reporting hundreds of
active_no_signalworktrees as if they are still in progress. On this machine the report showed 408 active/no-signal rows, which is not a credible real active workload count.Evidence
studio wp datamachine-code workspace worktree active-no-signal-report --limit=25 --offset=0 --until-budget=60s --format=jsontotal_active_no_signal: 408liveness_reason=heartbeat_stale,last_seen_atdays old, no session ids, and often no PR/task metadata.Expected behavior
Stale heartbeat worktrees should transition out of generic
activelifecycle or into a distinct review/remediation bucket after a bounded TTL. Cleanup/hygiene should surface them as abandoned/stale-review candidates, not count them as active in-progress work forever.Actual behavior
Rows with
lifecycle_state=activeand stale heartbeats remainactive_no_signalindefinitely. This makes cleanup output misleading and hides a lifecycle accounting bug behind safety blockers.Impact
Suggested fix
Add a lifecycle reconciliation path for stale heartbeat active worktrees:
lifecycle_state=activeplusliveness_reason=heartbeat_stalebeyond a TTL.abandoned_review,stale_active, or an explicit cleanup triage bucket.AI assistance