Summary

When exec approval follow-up tasks fail (e.g. network error during LLM call), the task runs remain in running status indefinitely. They are not reconciled by the task maintenance sweeper because hasBackingSession always returns true for cli runtime tasks whose childSessionKey points to a persistent session (e.g. agent:main:main).

This is the same bug pattern as #75307 (cron tasks stuck in running), but the fix for that issue only covered the cron code path. The cli runtime path in hasBackingSession still has the defect.

Repro

1. Trigger exec approvals that generate exec-approval-followup tasks (e.g. batch approve exec commands)
2. Let the follow-up embedded runs fail (network error, LLM timeout, etc.)
3. After the runs fail, check tasks/runs.json — tasks remain in running status
4. Restart the gateway — tasks are reloaded from disk, still running
5. Channel reload is permanently deferred: channel reload still deferred after Xms with 60 task run(s) active
6. Event loop saturates, all API calls timeout, gateway gets kill/restarted by launchd in a loop

Observed in production

• OpenClaw 2026.4.29 (a448042)
• 65 exec-approval-followup tasks stuck in running since 2026-03-30 (33 days)
• 2 cron email-watcher tasks also stuck
• Channel reload deferred for 33,911,115ms (~9.4 hours)
• Gateway forked 202 times by launchd due to health check failures
• All API calls (Telegram, Feishu, QQ Bot) timing out due to event loop blockage

Root cause

In src/tasks/task-registry.maintenance.ts, the hasBackingSession function:

function hasBackingSession(task) {
  if (task.runtime === cron) { ... } // Fixed in #75307
  if (task.runtime === cli && hasActiveCliRun(task)) return true;
  const childSessionKey = task.childSessionKey?.trim();
  if (!childSessionKey) return true;
  // ...
  if (task.runtime === subagent || task.runtime === cli) {
    // For cli: checks findTaskSessionEntry which returns true
    // if the session key exists in the store.
    // agent:main:main is a persistent session — it always exists.
    return Boolean(entry);
  }
}

For exec-approval-followup tasks:

• runtime = cli
• childSessionKey = agent:main:main (the main session)
• hasActiveCliRun returns false (the embedded run has ended)
• findTaskSessionEntry returns true (main session always exists in store)
• hasBackingSession → true
• shouldMarkLost → false
• Task is never reconciled

Expected behavior

After the exec-approval-followup embedded run completes (success or failure), the task run should be marked as succeeded or failed within a reasonable time (e.g. the existing 5-minute grace period). It should not remain running forever just because the parent session still exists.

Suggested fix

The cli runtime path in hasBackingSession should not consider a task as backed merely because its childSessionKey session exists. A session existing does not mean the specific run is still active. Possible approaches:

1. After hasActiveCliRun returns false for a cli task, return false immediately instead of falling through to the session existence check
2. Or: track the specific sessionId (not just sessionKey) when creating the follow-up task, and check if that specific session instance is still active
3. Or: add a max age for running tasks, after which they are automatically marked lost regardless of session state

Impact

• 67 zombie tasks blocking the entire task queue
• Channel reload permanently deferred
• Event loop saturated (P99 delay > 40s)
• All messaging channels (Telegram, Feishu, QQ Bot) non-functional
• Gateway crash loop (202 restarts)
• Requires manual intervention to clean up tasks/runs.json

Related

• #75307 — same bug for cron runtime (fixed in v2026.4.29)
• #59349 — exec follow-up leaking into new session after /new
• #72143 — exec follow-up fallback retry/prefix issues