Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.
One of my agent runs failed before replying, but its timer still looks active. openclaw tasks audit shows one TaskFlow and one task stuck in running for nearly eight days, plus older terminal warnings.
The audit confirms stale ledger state, not useful model work. Use full IDs, cancel only genuinely running items, then preview reconciliation:
openclaw tasks list --status running --json
openclaw tasks show <full-task-id> --json
openclaw tasks maintenance --json
If the preview targets the stale records, apply it and audit again. Terminal timed_out or lost history does not need cancellation.
I cancelled the TaskFlow. The remaining running task says its subagent cannot be found, including when I try to cancel it in the UI.
That means the task record remains while its child runtime is gone. Run maintenance first. If it identifies one orphaned child session, use the supported session lifecycle command with a dry run before applying it. Do not edit the task or session database directly.
Preview deletion of the exact orphaned session first. If the dry run targets only that child, apply it, run task maintenance, and audit again. Do not delete unrelated sessions or edit the database directly.
The session deletion dry run showed exactly the orphaned child, so I applied it. The next task audit reports zero errors. The formerly running task is now terminal lost, and only historical warnings remain.
The timer is fixed, but new runs still fail before replying. A fresh log later shows the OpenRouter model returning a rate-limit error.
That is a separate provider problem. The stale-task cleanup succeeded; the new failures need a provider with available quota or a fallback route. Keeping those diagnoses separate prevents unnecessary session deletion when the actual error is an HTTP 429.